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:
>> Roman Leshchinskiy wrote:
>>> Simon Marlow wrote:
>>>> Roman Leshchinskiy wrote:
>>>>> Simon Marlow wrote:
>>>>>>
>>>>>> We had a discussion on glasgow-haskell-users recently about 
>>>>>> whether to use libtool, and the general concensus was not:
>>>>>
>>>>> Hmm, I missed that one completely. It's probably too late for me to 
>>>>> jump in but I just don't see how the approach you outlined in
>>>>>
>>>>> http://www.haskell.org/pipermail/glasgow-haskell-users/2007-June/012740.html 
>>>>>
>>>>>
>>>>> deals with systems which don't *have* an rpath and with users who 
>>>>> manually set LD_LIBRARY_PATH. To be entirely honest, I suspect that 
>>>>> what you are trying to achieve can't be done portably and reliably.
>>>>
>>>> I don't expect it to be portable.  So on MacOS X, is it the case 
>>>> that the only way to build a binary that links to a particular 
>>>> shared library outside the system location is to use LD_LIBRARY_PATH?
>>>
>>> IIUC yes, except that it's called DYLD_LIBRARY_PATH. From man dyld:
>>>
>>>   For  each  library that a program uses, the dynamic linker looks
>>>   for it in each directory in DYLD_LIBRARY_PATH  in  turn.  If  it
>>>   still  can't  find  the  library,  it  then  searches DYLD_FALL-
>>>   BACK_FRAMEWORK_PATH and DYLD_FALLBACK_LIBRARY_PATH in turn.
>>>
>>> But I think on MacOS, the library paths are usually hardcoded in the 
>>> executable.
>>
>> If you can hardcode the library paths in the executable, then that's 
>> exactly what -rpath does isn't it?
> 
> After looking at the documentation I think I sort of understand how the 
> system works. When you build a shared library you can specify its 
> install_name which is the location where it will ultimately be 
> installed. When linking against the library, the linker hardcodes the 
> library's install_name into the executable. When the executable is run, 
> the dynamic loader looks for the library at that location. If it finds 
> the library, it's happy. If not, it will (appently) look in 
> DYLD_LIBRARY_PATH and friends and then in standard locations (/usr/lib 
> etc.) but will ignore DYLD_LIBRARY_PATH for setuid and setgid processes.

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.

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.

Cheers,
	Simon