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:
> Roman Leshchinskiy wrote:
>>
>> 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.

Oh, but it's not necessarily set just for ghc's benefit - /somewhere is 
just a place where the user puts stuff he doesn't want to or can't put 
in /usr or /usr/local. In fact, at my previous university I used 
something like that with /somewhere = $(HOME)/apps. It was a big 
Solaris-based network and not having root access, I had to install stuff 
I needed in my home directory. I suspect that this isn't a very uncommon 
situation.

> 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.

IMO there is a big difference between not requiring users to set 
LD_LIBRARY_PATH (a good thing) and requiring them not to set it (less good).

> 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.

Checking LD_LIBRARY_PATH once during the build doesn't seem like a good 
idea to me as it is not a static property of the system.

> If you have a better proposal, please tell us!

My proposal would basically duplicate libtool's functionality. We could 
have two versions of everything, one for running from the build tree and 
one for installing and additionally, we set LD_LIBRARY_PATH when running 
stuff from the build tree. This would catch the most obvious cases and I 
suspect we simply can't protect against the non-obvious ones. But then, 
why not use libtool?

In fact, that's possibly still not quite enough on some Unices (AIX 
and/or HP-UX?). I vaguely recall that there, binaries have to be 
relinked during installation after the shared libraries have been 
installed. I'm not sure if we really care about these platforms, though. 
In any case, IIRC libtool handles all this automatically.

When compiling with ghc-inplace, we can set the runpath by default and 
link against inplace libs. An installed compiler shouldn't set the 
runpath, IMO, even if it's installed in a non-standard location. In this 
case, it's the user's responsibility to make sure the shared libs are 
found. This is what gcc does, cf. http://gcc.gnu.org/faq.html#rpath

Roman