On 07/07/2011 07:32, Greg Steuck wrote:

Hello,

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?

Now, I try to compile a simple TH based program. GHC fails pretty quickly:

<command line>: user specified .o/.so/.DLL could not be loaded (libm.so: cannot open shared object file: No such file or directory) Whilst trying to load: (dynamic) m Additional directories searched: (none)

After some head scratching I add -L$(dirname $lib.so) to my GHC command line. Life is good?

Not quite, the next blow is harder, if I try to compile a slightly more complicated project which requires run time loading of unix package, I get:

Loading package unix-2.4.2.0 ... <command line>: can't load .so/.DLL for: pthread (libpthread.so: cannot open shared object file: No such file or directory)

The unix package config file lists: extra-libraries: rt util dl pthread

This seems to be the logical consequence of "we agreed that all extra-libraries should be found either on the search path or on the package's library-dirs." (http://hackage.haskell.org/trac/ghc/ticket/3930). Unfortunately my environment does not satisfy the preconditions. I will also be hard pressed to pinpoint the compile environment location ahead of time. Sticking the path into the package .conf is hard. All the compiler paths are set up with -pgm flags when I invoke GHC.

So, I resort to making this patch

diff --git a/ghc/compiler/ghci/Linker.lhs b/ghc/compiler/ghci/Linker.lhs index bd0bb35..192d416 100644 --- a/ghc/compiler/ghci/Linker.lhs +++ b/ghc/compiler/ghci/Linker.lhs @@ -1026,7 +1026,7 @@ linkPackages' dflags new_pks pls = do linkPackage :: DynFlags -> PackageConfig -> IO () linkPackage dflags pkg = do - let dirs = Packages.libraryDirs pkg + let dirs = Packages.libraryDirs pkg ++ libraryPaths dflags

let libs = Packages.hsLibraries pkg -- The FFI GHCi import lib isn't needed as

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). Cheers, Simon