Repository navigation
Conversation
The ld-options of X11.buildinfo end up in the registered package and are used whenever something links against X11, including the temporary shared objects GHC links to run Template Haskell. Including the LDFLAGS used to build X11 there leaks the build environment of X11 to all its reverse dependencies. On Ubuntu, where the default LDFLAGS include -Wl,-Bsymbolic-functions, that option is appended after the -Wl,-Bsymbolic GHC uses to link shared objects and overrides it. Data symbols (closures) then become preemptible and the R_X86_64_PC32 relocations emitted by the native code generator fail to link, e.g. when building taffybar: relocation R_X86_64_PC32 against symbol `..._closure' can not be used when making a shared object; recompile with -fPIC The X library search path found by configure is still recorded via X_LIBS and extra-lib-dirs. Link flags meant for building X11 itself can be passed through the usual Cabal options (e.g. --ld-option or --ghc-options=-optl...), which is what distribution tooling such as Debian's haskell-devscripts already does.
liskin
left a comment
liskin
left a comment
There was a problem hiding this comment.
Makes sense, although I admit I definitely don't have enough context to foresee all the implications. Seems to me this will ignore LDFLAGS for building the X11 library itself as well, but maybe that's okay?
Looking through GitHub and Google, there are a few other Haskell packages that still include LDFLAGS in their buildinfo, but there are also many that don't and presumably they're fine.
| @@ -3,6 +3,6 @@ | |||
| -- | |||
| buildable: @BUILD_PACKAGE_BOOL@ | |||
| cc-options: @X_CFLAGS@ @CPPFLAGS@ | |||
There was a problem hiding this comment.
Shall we perhaps drop these as well?
There was a problem hiding this comment.
Thanks! Yes, LDFLAGS no longer apply to linking X11 itself, but Cabal doesn't otherwise use LDFLAGS for GHC links, so this line was the only route. The useful bit, the X library search path found by configure, is still recorded through X_LIBS/extra-lib-dirs. Anyone who needs an extra -L for a non-X library can use --extra-lib-dirs, which is the usual Cabal way.
Good point on CPPFLAGS, same leak, so I pushed a commit dropping it too. The X include path is kept: configure.ac only adds X_CFLAGS/-I$x_includes to CPPFLAGS for its own checks, and AC_PATH_XTRA already puts -I$x_includes in X_CFLAGS.
Same as for LDFLAGS: cc-options are also applied to packages depending on X11, so recording the CPPFLAGS used at configure time leaks them to the reverse dependencies. The X include path is not lost: configure.ac only appends X_CFLAGS and -I$x_includes to CPPFLAGS for its own checks, and AC_PATH_XTRA already includes -I$x_includes in X_CFLAGS, which is still recorded.
2 participants
The ld-options of X11.buildinfo end up in the registered package and are used whenever something links against X11, including the temporary shared objects GHC links to run Template Haskell. Including the LDFLAGS used to build X11 there leaks the build environment of X11 to all its reverse dependencies.
On Ubuntu, where the default LDFLAGS include -Wl,-Bsymbolic-functions, that option is appended after the -Wl,-Bsymbolic GHC uses to link shared objects and overrides it. Data symbols (closures) then become preemptible and the R_X86_64_PC32 relocations emitted by the native code generator fail to link, e.g. when building taffybar:
relocation R_X86_64_PC32 against symbol `..._closure' can not be used
when making a shared object; recompile with -fPIC
The X library search path found by configure is still recorded via X_LIBS and extra-lib-dirs. Link flags meant for building X11 itself can be passed through the usual Cabal options (e.g. --ld-option or --ghc-options=-optl...), which is what distribution tooling such as Debian's haskell-devscripts already does.