[GHC] #7819: FreeBSD without system libffi: Shared object "libffi.so.6" not found

[GHC]

#7819: FreeBSD without system libffi: Shared object "libffi.so.6" not found
---------------------------------+------------------------------------------
    Reporter:  igloo             |       Owner:  pgj         
        Type:  bug               |      Status:  new         
    Priority:  high              |   Milestone:  7.8.1       
   Component:  Build System      |     Version:  7.6.2       
    Keywords:                    |          Os:  FreeBSD     
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown
  Difficulty:  Unknown           |    Testcase:              
   Blockedby:                    |    Blocking:              
     Related:                    |  
---------------------------------+------------------------------------------

Comment(by pgj):

 Well, regarding `libffi` I believe the following patch could solve the
 situation for you (please test):

 {{{
 diff --git a/rts/ghc.mk b/rts/ghc.mk
 index b7651b0..a1e771e 100644
 --- a/rts/ghc.mk
 +++ b/rts/ghc.mk
 @@ -186,7 +186,7 @@ else
  ifneq "$$(UseSystemLibFFI)" "YES"
  LIBFFI_LIBS = -Lrts/dist/build -lffi
  ifeq "$$(TargetElf)" "YES"
 -LIBFFI_LIBS += -optl-Wl,-rpath -optl-Wl,'$$$$ORIGIN'
 +LIBFFI_LIBS += -optl-Wl,-rpath -optl-Wl,'$$$$ORIGIN' -optl-Wl,-zorigin
  endif
 }}}

 On FreeBSD, one needs to invoke `ld(1)` with `-z origin` in order to
 enable resolution of `$ORIGIN` in `RPATH`.

 However, I guess we shall also have to face a more generic problem here:
 dynamic library paths are not linked as relative on FreeBSD, because `ghc-
 pkg` is not linked with other dependent dynamic libraries in its `RPATH`.
 I tried to use the Linux approach, i.e. enabled linking with relative
 paths in `rules/distdir-way-opts.mk` by applying the following (trivial)
 patch:

 {{{
 diff --git a/rules/distdir-way-opts.mk b/rules/distdir-way-opts.mk
 index 872e527..fd9f5e5 100644
 --- a/rules/distdir-way-opts.mk
 +++ b/rules/distdir-way-opts.mk
 @@ -129,6 +129,11 @@ ifeq "$$(TargetOS_CPP)" "linux"
  $1_$2_$3_GHC_LD_OPTS += \
      -fno-use-rpaths \
      $$(foreach d,$$($1_$2_TRANSITIVE_DEPS),-optl-Wl$$(comma)-rpath -optl-
 Wl$$(comma)'$$$$ORIGIN/../$$d')
 +else ifeq "$$(TargetOS_CPP)" "freebsd"
 +$1_$2_$3_GHC_LD_OPTS += \
 +    -fno-use-rpaths \
 +    $$(foreach d,$$($1_$2_TRANSITIVE_DEPS),-optl-Wl$$(comma)-rpath -optl-
 Wl$$(comma)'$$$$ORIGIN/../$$d') \
 +    -optl-Wl,-zorigin
  else ifeq "$$(TargetOS_CPP)" "darwin"
  $1_$2_$3_GHC_LD_OPTS += -optl-Wl,-headerpad_max_install_names
  endif
 }}}

 Unfortunately the chances are high that there is `rtld(1)` bug in handling
 `$ORIGIN` substitutions and can only work with path sizes lesser than
 1024.  When I modified `rtld(1)` to work with larger path sizes, it
 worked, but I am now waiting for an official fix.

 The builder clients work because they have the absolute paths embedded
 inside and installing them to a different location does not make any
 difference in that case.  But when somebody tries to install the vanilla
 binary tarball they generate it will fail in a similar way.

 Ian, do you have any recommendations how to work this problem around?

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