Locating extra-libraries

[Simon Marlow]

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