HEAD doesn't build (was Re: patch applied (ghc): Add hardwire-lib-paths option and make it default for inplace invocations)

[Roman Leshchinskiy]

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
     /somewhere/lib
   - 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.

Roman