Dynamic libraries don't work on Mac OS/X

[StephenBlackheath]

GHC doesn't build properly on Mac OS/X when dynamic library support is enabled. And, when GHC is successfully built with dynamic library support (with tweaks), it doesn't build or link dynamic libraries properly.

I've provided a set of patches, broken up with explanations. We need to discuss whether adding an -install-name option to GHC is acceptable to the GHC team.

Note: A separate patch for Cabal uses the new -install-name option. Without this applying this in the ghc tree, the Cabal installed along with ghc will not generate shared libraries on Mac OS/X with the right install name.

[StephenBlackheath]

GHC patches to fix Mac OS/X dynamic libs, v4

[StephenBlackheath]

Test case

[chak]

From what I understand about dylibs on Mac OS, the proposed -install-name option does make sense.

I had a quick lock at the patch and it seems reasonable to me. I haven't validated it, though.

I'm in favour of accepting these changes. I'll be happy to validate this and push if GHC HQ is happy with this. Not sure how you want to handle the Cabal part of this. Duncan?

(There needs to be an additional patch to the GHC docs, though, to document the new option.)

[StephenBlackheath]

If there's general agreement with the approach, I'll write a patch for the docs.

Another thing - this line in the patch...

-install-name $(ghclibdir)/basename "$$@" | sed 's/^libHS//;s/[-]ghc.*//'/basename "$$@"

...is a bit brittle because it second-guesses the behaviour of other makefiles, so some re-factoring is probably desirable here (assuming you decide to go with this approach).

---

Some other Mac OS/X issues:

1. The general wisdom of using absolute paths on Mac OS/X: My take on it is that GHC does things the "Unix way" where it installs into an absolute location. If you want to package your application up Mac OS/X style (where the whole directory is required to be moveable), then the developer needs to make a process for doing that anyway. Perhaps at that point, they would just add the extra step of modifying all the shipped libraries to use relative paths (this can be done using a Mac OS/X system utility).

2. You can't run an app (one that has a library and an executable in it) from the build tree because it wants to use the install location. I don't know the solution to this, but it's only a minor annoyance mostly, and it seems to me that it could be dealt with later as a separate issue.

[simonmar]

The patches are generally fine. I wonder whether -install-name is the best name for the flag: it's a bit generic. Perhaps -dylib-install-name?

The sed stuff is indeed unsightly, but I don't see any easy way to fix it, because the knowledge about where a library is finally installed lives in Cabal at the moment.

I presume this patch subsumes the patch "rejig dylib names on Mac only" sent to the cvs-ghc list by mwotton@gmail.com?

[StephenBlackheath]

-dylib-install-name is better for several reasons, so I'll add that to my to-do list for after everyone's commented. I didn't give the name of the option any thought - it's just a slightly modified version of Apple's name.

I've been doing this in communication with mwotton (a.k.a. blackdog) so yes, this patch replaces anything he sent for Mac dylibs previously.

[mwotton]

yeah, this subsumes my stuff and then some. will have another test in a bit with any luck.

[StephenBlackheath]

GHC patches to fix Mac OS/X dynamic libs, v5

[StephenBlackheath]

Version 5 changes the name of the new option to -dylib-install-name and adds documentation for it to the Users Guide. The corresponding Cabal patch (also needed) it #591 at

 http://hackage.haskell.org/trac/hackage/ticket/591

[igloo]

Too late for 6.12.1, but let's see if this is suitable for a point release in the 6.12 branch.

[mwotton]

Replying to igloo:

Too late for 6.12.1, but let's see if this is suitable for a point release in the 6.12 branch.

Hi Igloo - is there something holding this and and #3550 up? What can I do to help?

[mwotton]

Replying to mwotton:

Replying to igloo:

Too late for 6.12.1, but let's see if this is suitable for a point release in the 6.12 branch.

Hi Igloo - is there something holding this and and #3550 up? What can I do to help?

sorry, meant  http://hackage.haskell.org/trac/hackage/ticket/591

[igloo]

I've applied the patches to the HEAD; thanks!

Would it be possible for you to change the testcase so that it uses a tiny Cabal package - if possible, containing just 1 module containing 1 simple function - so that we can add it to the testsuite, please?

[mwotton]

test case using the 'primes' package

[mwotton]

Yep, I can do that. test-case-2.tar.bz2 is attached - it's using the primes package, which has two visible functions and compiles in less than a second on my machine. let me know if you'd prefer me to upload a dummy cabal package just for testing.

[simonpj]

I'm changing priority to 'high' and owner Ian, not because we yet know we can deliver a fix for 6.12.2, but rather to ask him to figure out whether we can!

Simon

[igloo]

Didn't make it in time for 6.12.2.

[igloo]

In the HEAD, I've enabled dynamic libraries by default on OS X, fixed a couple of build problems, and set DYLD_LIBRARY_PATH so that the dyn tests work.

The patches don't merge cleanly to the 6.12 branch, and this isn't a bug or regression, so I'm closing the ticket. If not having this in 6.12.3 would cause you problems, please reopen the ticket.