My findings from digging into this:
The native code generation backend for GHC is emitting code that uses
PC-relative relocations for at least some symbols internal to a library
instead of using the GOT. I created a `Repro.hs` file with these
contents, which roughly mimics the package
module Repro where
import Data.List.NonEmpty (NonEmpty)
import qualified Data.List.NonEmpty as NE
repro :: NonEmpty Int -> Int
repro = maximum . NE.toList
Then I inspected the generated assembly, which seems to show that only
the external symbols are using the GOT:
(noble-amd64)root@bit:/scratch/ghc-pic-repro# ghc -O -fPIC -dynamic -ddump-asm
/scratch/ghc-pic-repro/Repro.hs 2>&1 | grep "rip"
leaq Repro.$w$wgo3_closure(%rip),%rbx
leaq .Lblock_c17m_info(%rip),%rbx
leaq .Lblock_c17c_info(%rip),%rax
leaq .Lblock_c17v_info(%rip),%rcx
leaq .Lblock_c17U_info(%rip),%rax
leaq Repro.$wgo3_closure(%rip),%rbx
movq GHC.Types.I#_con_info@gotpcrel(%rip),%rax
jmp *stg_gc_unbx_r1@gotpcrel(%rip)
leaq .Lblock_c18f_info(%rip),%rax
leaq .Lblock_c18l_info(%rip),%rax
leaq .Lblock_c18q_info(%rip),%rax
leaq Repro.repro_closure(%rip),%rbx
Whether this is a bug in GHC or not is unclear to me. It seems like this
might interfere with ELF interposition, but then the linker is invoked
with `-Bsymbolic` which overrides some of the typical behavior around
interposition, which suggests it might be intentional.
Either way, this works on Debian just fine but not on Ubuntu. That's
because the LDFLAGS on Ubuntu differ:
(sid-amd64)root@bit:/root# dpkg-buildflags --get LDFLAGS
-Wl,-z,relro
(noble-amd64)root@bit:/scratch/ghc-pic-repro# dpkg-buildflags --get LDFLAGS
-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -Wl,-z,relro
It seems that the LTO flags are triggering a code path with stricter
checks or one that's somehow rejecting the relocations before
`-Bsymbolic` causes them to be resolved. I tried adjusting various
flags, but it seems that no matter what I set in the package, the vendor
flags we set in dpkg take priority.
Those details are a bit beyond my current undersatnding, so I agree that
using the LLVM backend is a better short-term solution.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2144301
Title:
haskell-x11-xft fails to build with GCH 9.10
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/haskell-x11-xft/+bug/2144301/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
