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

[Simon Marlow]

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

Cheers,
	Simon