Locating extra-libraries

Greg Steuck greg at nest.cx
Mon Jul 11 15:55:37 CEST 2011

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.

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

nest.cx is Gmail hosted, use PGP for anything private. Key:
Fingerprint: 5E2B 2D0E 1E03 2046 BEC3  4D50 0B15 42BD 8DF5 A1B0

More information about the Glasgow-haskell-users mailing list