HEAD doesn't build (was Re: patch applied (ghc): Add
option and make it default for inplace invocations)
rl at cse.unsw.edu.au
Wed Aug 1 17:44:08 EDT 2007
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
- ghc-9.9 is installed in /somewhere, with libghc-9.9 living in
- LD_LIBRARY_PATH is set to /somewhere/lib
- 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.
More information about the Cvs-ghc