[GHC] #648: Problem resolving library paths (missing path in package.conf?)

[GHC]

#648: Problem resolving library paths (missing path in package.conf?)
----------------------------------+-----------------------------------------
  Reporter:  gwright at antiope.com  |          Owner:         
      Type:  bug                  |         Status:  new    
  Priority:  normal               |      Milestone:         
 Component:  Compiler             |        Version:  6.4.1  
  Severity:  normal               |     Resolution:         
  Keywords:                       |             Os:  MacOS X
Difficulty:  Easy (1 hr)          |   Architecture:  powerpc
----------------------------------+-----------------------------------------
Comment (by gwright at antiope.com):

 Hi Volker,

 Sorry I misunderstood.  On DP, I get the same effect as ldOptions by using
 a
 custom build.mk, and editing the scripts that invoke ghc and ghci before
 they are installed in their final location.  This is all needed on DP
 because
 we support putting the DP tree anywhere in the file system, to allow non-
 root
 installs.

 On FreeBSD 6, ghci -package readline finds readline without any problem,
 but in this case libreadline is available on the default library path.

 To answer your specific question, on FreeBSD 6,

 {{{
 ivy-mike> ldd /usr/local/lib/ghc-6.4.1/ghc-6.4.1
 /usr/local/lib/ghc-6.4.1/ghc-6.4.1:
         libreadline.so.6 => /lib/libreadline.so.6 (0x28909000)
         libncurses.so.6 => /lib/libncurses.so.6 (0x28936000)
         libm.so.4 => /lib/libm.so.4 (0x28975000)
         libc.so.6 => /lib/libc.so.6 (0x2898b000)
 }}}

 while on OS X,

 {{{
 crossroads-able> otool -L /opt/local/lib/ghc-6.4.1/ghc-6.4.1
 /opt/local/lib/ghc-6.4.1/ghc-6.4.1:
         /opt/local/lib/libreadline.5.0.dylib (compatibility version 5.0.0,
 current version 5.0.0)
         /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0,
 current version 5.4.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
 version 88.1.2)
         /opt/local/lib/libgmp.3.dylib (compatibility version 7.0.0,
 current version 7.3.0)
 }}}


 If one sets LD_LIBRARY_PATH, you get the expected behavior on OS X:

 {{{
 crossroads-able> LD_LIBRARY_PATH=/opt/local/lib ghci -package readline
    ___         ___ _
   / _ \ /\  /\/ __(_)
  / /_\// /_/ / /  | |      GHC Interactive, version 6.4.1, for Haskell 98.
 / /_\\/ __  / /___| |      http://www.haskell.org/ghc/
 \____/\/ /_/\____/|_|      Type :? for help.

 Loading package base-1.0 ... linking ... done.
 Loading package readline-1.0 ... linking ... done.
 Prelude>
 }}}

 But the user should never have to set LD_LIBRARY_PATH for properly
 packaged software.

 It looks like this is just a buglet that comes from assuming that
 ghc and it dependencies will alway be installed into /usr/local,
 or somewhere else that is on the default library search path. As I noted,
 I can fix this by automatically editing package.conf.  But it really is a
 bug,
 since by setting --prefix= to someplace off the default search path,
 you can break part of ghci.

 -Greg

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/648>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler