On Wed, 2009-12-30 at 12:09 +0100, Maxime Henrion wrote: > - Is there a plan to deal with the ldconfig cache on UNIX systems? As > things are now, I had to manually add all the package directories > under /usr/local/lib/ghc-6.12.1/ to be able to run the generated > executable. I guess Cabal could produce a list of directories in some > way for the system to do the right thing afterward, or we need some kind > of a hack for setting LD_LIBRARY_PATH prior to starting the executable.
As Andrew says, we use -rpath on Linux for the "-dynload sysdep" mode. This should also work on FreeBSD and other ELF platforms. > - I'm a bit surprised at the naming convention for the shared > libraries. The library name includes both the package and the compiler > versions, preventing any "automatic" upgrading. Yes. They cannot be upgraded. They have no stable ABI. Achieving a somewhat stable ABI may become possible in the future. > If a new version of some package fixes bugs, improves performance, > etc... but otherwise doesn't break the ABI, we are still going to be > forced to rebuild binaries to take advantage of it. Yes. > Similarly if a new compiler version produces better code but doesn't > break the ABI, but I'm less concerned about that one. I suppose an ABI > number could be handled at the Cabal level, and only bumped when > maintainers know it is appropriate, otherwise, we won't be getting one > of the nice advantages of shared libraries. The problem is that at the moment GHC cannot produce libs with a stable ABI. Internal changes in a function can change the function's ABI. Up until recently doing things like adding a non-exported function could change IDs used in linker symbols. Simon Marlow's plan is to do something like let people declare that a package provides a certain ABI and then have the compiler shout at you if you make changes that would change the ABI. That, along with other changes like not exporting any unfoldings by default for stable ABI modules, unless marked INLINE. Duncan _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
