
#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