HEAD doesn't build (was Re: patch applied (ghc): Add
option and make it default for inplace invocations)
simonmarhaskell at gmail.com
Thu Aug 2 04:08:31 EDT 2007
Roman Leshchinskiy wrote:
> Simon Marlow wrote:
>> It sounds like the only way to get the effect of -rpath is to create a
>> wrapper script that sets DYLD_LIBRARY_PATH, then. Presumably this is
>> what libtool does.
> I'm still not sure which effect precisely you're after. -rpath helps
> with finding shared libraries but it doesn't (portably) guarantee that
> you'll find the right ones. Consider the following (IMO not entirely
> unreasonable) scenario:
> - ghc-9.9 is installed in /somewhere, with libghc-9.9 living in
> - LD_LIBRARY_PATH is set to /somewhere/lib
We don't expect people to have to set LD_LIBRARY_PATH in order to use GHC.
A standard GHC installation will install its shared libraries in the
appropriate place for the system. The intention is that GHC behaves like a
proper citizen on its host platform, we'll do whatever the local convention is.
> - I download and build my own ghc-9.9 in ~/build
> - I compile myapp with ~/build/compiler/ghc-inplace which sets
> -rpath ~/build/lib (where the new libghc-9.9 lives)
> Now, when I run myapp on Linux, everything will be fine because here,
> rpath takes precedence over LD_LIBRARY_PATH. However, on Solaris and,
> apparently, on FreeBSD myapp will pick up the wrong libghc, namely the
> one in /somewhere/lib because on these systems, LD_LIBRARY_PATH is
> searched first (unless I'm completely mistaken).
>> This is a bit of a pain. We can't support -hardwire-lib-paths on
>> MacOS, and we'll need some jiggery-pokery in the build system to get
>> the same effect - perhaps ghc-inplace sets DYLD_LIBRARY_PATH before
>> invoking the ghc binary.
> IMO it should do that on all systems. But this still doesn't help with
> programs that are compiled with ghc-inplace as it is rather easy for
> them to pick up the wrong libraries. Perhaps this can be mitigated
> somewhat by having ghc-inplace link against libghc-inplace. This would
> avoid a conflict with a libghc installed in LD_LIBRARY_PATH.
> Indeed, this would also help with MacOS since the inplace library can
> have a different install_name than the one which ultimately gets installed.
Clemens believes there's a way to get the effect of -rpath on MacOS, so
we'll see. Then there would be no reason for people to use LD_LIBRARY_PATH
to point to GHC libraries.
So I wasn't aware that LD_LIBRARY_PATH takes precedence over rpath on some
platforms, that does present a slight problem, but maybe it's not a killer.
I don't expect that most people will be using LD_LIBRARY_PATH, and the
build system could always check for it. Perhaps we should have more safety
nets - a runtime check for the right libraries, for example.
If you have a better proposal, please tell us!
More information about the Cvs-ghc