greg at nest.cx
Thu Jul 7 08:32:56 CEST 2011
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.
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-220.127.116.11 ...
<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
(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
@@ -1026,7 +1026,7 @@ linkPackages' dflags new_pks pls = do
linkPackage :: DynFlags -> PackageConfig -> IO ()
linkPackage dflags pkg
- 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?
More information about the Glasgow-haskell-users