Locating extra-libraries

Simon Marlow marlowsd at gmail.com
Tue Jul 12 09:43:36 CEST 2011


On 11/07/2011 14:55, Greg Steuck wrote:
> Thanks for the response, answers inline.
>
> On Mon, Jul 11, 2011 at 5:37 AM, Simon Marlow<marlowsd at gmail.com>  wrote:
>>> I am integrating ghc-7.0.3 into our build system running on
>>> Linux-amd64. One of the features of said build system is full
>>> isolation from the host system. This means we do not use the default
>>> compilers and library paths. We further have separation between
>>> runtime and compile time paths. This means that libm.so is only
>>> available in the compile environment and is not anywhere in rpath of
>>> the ghc binary.
>>
>> How are programs compiled against libm supposed to find libm at runtime?
>
> The linker records dependencies on libm.so.6 which is present at
> runtime. The problem is the lack of the shortcut symlink then.

Ah, I see.

>>> This effectively extends the extra-libraries search path to also
>>> include any -L paths specified on the command lines.
>>>
>>> Is there a better way to do what I'm doing? Is there any chance such a
>>> patch can be applied?
>>
>> I think this is basically the same issue as
>>
>>   http://hackage.haskell.org/trac/ghc/ticket/5289
>>
>> and the fix proposed there would also fix your situation.  We should be
>> locating the library when the package is installed, and remembering the path
>> (though I'm not sure whether this will have any unintended consequences).
>
> Yes, something along the lines of using gcc -print-file-name should work.

Ok great, I'll look into this.

Cheers,
	Simon




More information about the Glasgow-haskell-users mailing list