On Friday December 4, 2009, Duncan Coutts wrote: > On Thu, 2009-12-03 at 08:59 -0800, Howard B. Golden wrote: > > On Thursday December 3, 2009, Duncan Coutts wrote: > > > The point is, technically we probably do not want "ghci -lpcre" > > > to translate directly into a call to dlopen "libpcre.so". There > > > should be another translation stage to give us "libpcre.so.0". > > > Then that name --- corresponding to a fixed ABI --- should be > > > kept in the package config so we keep linking to the same thing > > > even if you install newer versions of the C lib. > > > > I'm not sure this applies to ghci loading from the command line. I > > believe the semantics should be the same as the system linker uses, > > i.e., the current version. > > Right, but if we can resolve -lpcre to libpcre.so.0 then we can > dlopen libpcre.so.0 without having to parse linker scripts.
First, I have uploaded a patch into Trac. It embodies what follows: To reiterate the above point about shared library versions, when we run "ghci -lpcre", we are saying "give me the current version of libpcre.so (whatever that is)." This is exactly the syntax and semantics of the linker command "ld -lpcre". In other words, for ghci _only_ dynamic loading is the same as contemporaneous linking. On the other hand, it is not proper to compile a program with "ghci -lpcre" unless the current specific version of libpcre.so is saved, since the program should have the same semantics whenever it is executed in future. So I agree partly and disagree partly with Flameeyes about this. I don't know whether or not compiled programs contain the specific version number of the shared library they were compiled against. If they don't, this should be fixed. It probably isn't necessary to parsed linker scripts fully. My patch uses a regular expression, not a full parser. If we need to fully comply with the semantics of linker scripts, I believe we should simply invoke the system's linker, not try to reimplement its parser. I still think the goal should be to eliminate the linker code entirely and invoke the system linker and dynamic loader. I will continue to research this. Howard _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
