Patch for shared libraries support on FreeBSD

[Maxime Henrion]

On Wed, 2009-12-30 at 14:20 +0000, Duncan Coutts wrote:
> 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.

Thanks to both of you: that was it! I just had to handle a couple more
'#ifdef linux_TARGET_OS' statements around the code implementing this
-rpath feature.

> >  - 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.

Thanks for the explanation.

I'm attaching an updated patch that defines the 'elf_TARGET_OS' macro
when a target OS is known to support ELF-like shared libraries, and have
used it wherever Linux & FreeBSD were matched previously. Now that I
think about it, elf_TARGET_OS isn't such a great name since it's in the
wrong namespace and would conflict with an OS named ELF. Quite unlikely,
but still not pretty - something like elf_TARGET_LIBS is probably
better.

I should do something similar for the runtime tests.

I have added the 'amd64-unknown-freebsd' platform to the list of
platforms where we support shared libraries, since it should work just
fine (testers would be great).

The -rpath feature (see above) now works properly on FreeBSD too.

The sed-related hack is also gone, thanks to an upstream change
correcting the problem.

Any suggestions or comments about this patch would be greatly
appreciated.

A happy new year to all the GHC users and developers!

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freebsd-shared.diff
Type: text/x-patch
Size: 6396 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/cvs-ghc/attachments/20100101/1f8685b3/freebsd-shared.bin