Thanks for the response, answers inline.
On Mon, Jul 11, 2011 at 5:37 AM, Simon Marlow
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. Thanks Greg -- nest.cx is Gmail hosted, use PGP for anything private. Key: http://tinyurl.com/ho8qg Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0