Bug 2430571
| Summary: | [i686] ghc RTS fails to link with binutils-2.45.50-15.fc44 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jens Petersen <petersen> |
| Component: | ghc | Assignee: | Jens Petersen <petersen> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | dmalcolm, fweimer, jakub, jlaw, josmyers, jwakely, mcermak, mpolacek, msebor, nickc, nixuser, petersen, sipoyare |
| Target Milestone: | --- | Keywords: | Regression |
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2026-02-03 18:58:53 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jens Petersen
2026-01-17 06:57:42 UTC
Okay I should have checked all slightly more carefully: I guess so far the gcc16 i686 failures have been observed for ghc9.4 and later. (ie 9.4, 9.6, 9.8, 9.10, 9.12 and 9.12 on i686) ghc9.2 was my fault but 9.0 & 8.10 are failing with gcc16 on x86_64 for instance. But yes ghc9.2 also fails on i686 with gcc16: https://kojipkgs.fedoraproject.org/work/tasks/7563/141197563/build.log How do I convince the ghc build system to actually print the commands it invokes? Tried %global cabal_build_options -v3 but even with that it prints nothing useful. In particular, I'd like to see the command line used to produce _build/stage1/rts/build/c/sm/Compact.thr_dyn_o Thank you for looking. I think a change like this to the spec file: ``` diff --git a/ghc9.14.spec b/ghc9.14.spec index fd93a1e..26086bd 100644 --- a/ghc9.14.spec +++ b/ghc9.14.spec @@ -7,7 +7,7 @@ # https://gitlab.haskell.org/ghc/ghc/-/issues/25536 %bcond releasebuild 0 %else -%bcond releasebuild 1 +%bcond releasebuild 0 %endif %bcond build_hadrian 1 %bcond manual 1 @@ -551,7 +551,7 @@ ln -s ../libraries/Cabal/Cabal Cabal-%{Cabal_ver} %global _smp_ncpus_max 64 # quickest does not build shared libs # --hash-unit-ids should be redundant for 9.14 release flavor -%{hadrian} %{?_smp_mflags} --flavour=%{hadrian_flavour}%{!?with_ghc_prof:+no_profiled_libs}%{?hadrian_llvm}%{?hadrian_debug} %{hadrian_docs} binary-dist-dir --hash-unit-ids +%{hadrian} %{?_smp_mflags} -VV --flavour=%{hadrian_flavour}%{!?with_ghc_prof:+no_profiled_libs}%{?hadrian_llvm}%{?hadrian_debug} %{hadrian_docs} binary-dist-dir --hash-unit-ids %install ``` I will try myself too (but basically passing -VV to hadrian should do it hopefully - ghc doesn't use proper cabal yet to build alas). The first hunk is just to quicken the build: turns off prof and higher optimization: may not make so much difference here since the build doesn't get that far. Yeah I think it is working: https://koji.fedoraproject.org/koji/taskinfo?taskID=141204427 It will be a large build.log ;) I guess it is this: | Run Ghc CompileCWithGhc Stage1: rts/sm/Compact.c => _build/stage1/rts/build/c/sm/Compact.thr_dyn_o _build/stage0/bin/ghc -Wall -hisuf thr_dyn_hi -osuf thr_dyn_o -hcsuf thr_dyn_hc -fPIC -dynamic -DTHREADED_RTS -optc-DTHREADED_RTS -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stage1/inplace/package.conf.d' '-this-unit-id rts-1.0.3' '-this-package-name rts' -i -i/builddir/build/BUILD/ghc9.14-9.14.1-build/ghc-9.14.1/_build/stage1/rts/build -i/builddir/build/BUILD/ghc9.14-9.14.1-build/ghc-9.14.1/_build/stage1/rts/build/autogen -i/builddir/build/BUILD/ghc9.14-9.14.1-build/ghc-9.14.1/rts/ -Irts/include -I_build/stage1/rts/build -I_build/stage1/rts/build/include -Irts/include -optP-include -optP_build/stage1/rts/build/autogen/cabal_macros.h -ghcversion-file=rts/include/ghcversion.h -optc-U__i686 -outputdir _build/stage1/rts/build -package-env=- -this-unit-id rts -XHaskell98 -no-global-package-db -package-db=/builddir/build/BUILD/ghc9.14-9.14.1-build/ghc-9.14.1/_build/stage1/inplace/package.conf.d -ghcversion-file=rts/include/ghcversion.h -ghcversion-file=rts/include/ghcversion.h -optc-U__i686 -optc-Irts/include -optc-I_build/stage1/rts/build -optc-I_build/stage1/rts/build/include -optc-Irts/include -optc-fPIC -optc-DDYNAMIC -Wnoncanonical-monad-instances -optc-Wno-error=inline -c rts/sm/Compact.c -o _build/stage1/rts/build/c/sm/Compact.thr_dyn_o -O0 -H64m -O -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Wundef -optc-fno-strict-aliasing -optc-DTHREADED_RTS -optc-fomit-frame-pointer -optc-O2 -optc-Irts -optc-I_build/stage1/rts/build -optc-DFS_NAMESPACE=rts -optc-DCOMPILING_RTS -optc-fno-PIC -optc-Wno-inline -optc-finline-limit=2500 -Irts -I_build/stage1/rts/build -DTHREADED_RTS -Wno-deprecated-flags -Wcpp-undef If you prefer another ghc I can also run that. That looks like ghc bug to me. I see _build/stage0/bin/ghc -Wall -hisuf thr_dyn_hi -osuf thr_dyn_o -hcsuf thr_dyn_hc -fPIC -dynamic -optc-DTHREADED_RTS -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stage1/inplace/package.conf.d' '-this-unit-id rts-1.0.2' -i -i/builddir/build/BUILD/ghc-9.8.4-build/ghc-9.8.4/_build/stage1/rts/build -i/builddir/build/BUILD/ghc-9.8.4-build/ghc-9.8.4/_build/stage1/rts/build/autogen -i/builddir/build/BUILD/ghc-9.8.4-build/ghc-9.8.4/rts -Irts/include -I_build/stage1/rts/build -I_build/stage1/rts/build/include -Irts/include -optP-include -optP_build/stage1/rts/build/autogen/cabal_macros.h -ghcversion-file=rts/include/ghcversion.h -optc-U__i686 -outputdir _build/stage1/rts/build -this-unit-id rts -XHaskell98 -no-global-package-db -package-db=/builddir/build/BUILD/ghc-9.8.4-build/ghc-9.8.4/_build/stage1/inplace/package.conf.d -ghcversion-file=rts/include/ghcversion.h -ghcversion-file=rts/include/ghcversion.h -optc-U__i686 -optc-Irts/include -optc-I_build/stage1/rts/build -optc-I_build/stage1/rts/build/include -optc-Irts/include -optc-fPIC -optc-DDYNAMIC -Wnoncanonical-monad-instances -optc-Wno-error=inline -c rts/sm/Compact.c -o _build/stage1/rts/build/c/sm/Compact.thr_dyn_o -O -H64m -O2 -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Wundef -optc-fno-strict-aliasing -optc-fomit-frame-pointer -optc-O2 -optc-Irts -optc-I_build/stage1/rts/build -optc-fno-PIC -optc-Wno-inline -optc-finline-limit=2500 -Irts -I_build/stage1/rts/build '-DRtsWay="rts_thr_dyn"' -DFS_NAMESPACE=rts -DCOMPILING_RTS -DTHREADED_RTS -Wno-deprecated-flags -Wcpp-undef and the -optc-fno-PIC in the command line causes /usr/bin/gcc -x c -c rts/sm/Compact.c -o _build/stage1/rts/build/c/sm/Compact.thr_dyn_o.tmp -fPIC -U__PIC__ -D__PIC__ -Wimplicit -O2 -include rts/include/ghcversion.h -Irts/include -I_build/stage1/rts/build -I_build/stage1/rts/build/include -Irts/include -I_build/stage1/rts/build -Irts -I_build/stage1/rts/build -Xpreprocessor -include -Xpreprocessor _build/stage1/rts/build/autogen/cabal_macros.h -Xpreprocessor '-DRtsWay="rts_thr_dyn"' -Xpreprocessor '-DFS_NAMESPACE=rts' -Xpreprocessor -DCOMPILING_RTS -Xpreprocessor -DTHREADED_RTS -U__i686 -DTHREADED_RTS -U__i686 -U__i686 -Irts/include -I_build/stage1/rts/build -I_build/stage1/rts/build/include -Irts/include -fPIC -DDYNAMIC '-Wno-error=inline' -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Winline -Wpointer-arith -Wmissing-noreturn -Wnested-externs -Wredundant-decls -Wundef -fno-strict-aliasing -fomit-frame-pointer -O2 -Irts -I_build/stage1/rts/build -fno-PIC -Wno-inline '-finline-limit=2500' so while -fPIC is used early in the options, it is overridden by -fno-PIC late in the options. And the linking error is when trying to link that -fno-PIC object into the _build/stage1/rts/build/libHSrts-1.0.2_thr-ghc9.8.4.so shared library. Trying gcc 15, with the same command line I get exactly that (.rodata section with .text relocations for a switch). So, if the difference is that when built with gcc 15 it didn't add this bogus -optc-fno-PIC and no it does, the question is where it decides about that and based on what. s/no/now/, sorry. Okay thank I will open an upstream ghc issue then. I opened https://gitlab.haskell.org/ghc/ghc/-/issues/26792 Also running https://koji.fedoraproject.org/koji/taskinfo?taskID=141206721 on F43 Comparing config.status between F43 and F44, I see @@ -711,8 +711,8 @@ S["HaskellTargetArch"]="ArchX86" S["HaskellHostOs"]="OSLinux" S["HaskellHostArch"]="ArchX86" S["ARM_ISA"]="" -S["CXX_STD_LIB_DYN_LIB_DIRS"]="/usr/lib/gcc/i686-redhat-linux/15" -S["CXX_STD_LIB_LIB_DIRS"]="/usr/lib/gcc/i686-redhat-linux/15" +S["CXX_STD_LIB_DYN_LIB_DIRS"]="/usr/lib/gcc/i686-redhat-linux/16" +S["CXX_STD_LIB_LIB_DIRS"]="/usr/lib/gcc/i686-redhat-linux/16" S["CXX_STD_LIB_LIBS"]="stdc++" S["CONF_HC_OPTS_STAGE2"]="" S["CONF_HC_OPTS_STAGE1"]="" @@ -734,7 +734,7 @@ S["LLVMTarget_CPP"]="i686-unknown-linux" S["LdSupportsResponseFiles"]="YES" S["CcLlvmBackend"]="NO" S["NeedLibatomic"]="NO" -S["GccVersion"]="15.2.1" +S["GccVersion"]="16.0.1" S["OptCmd"]="/usr/bin/opt-15" S["ac_ct_OPT"]="" S["OPT"]="/usr/bin/opt-15" @@ -775,7 +775,7 @@ S["CPP"]="/usr/bin/gcc -E" S["ac_ct_CXX"]="" S["CXXFLAGS"]=" -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS "\ "-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m32 -march=i686 -mtune=gener"\ -"ic -msse2 -mfpmath=sse -mstackrealign -fasynchronous-unwind-tables -fstack-clash-protection " +"ic -msse2 -mfpmath=sse -mstackrealign -fasynchronous-unwind-tables -fstack-clash-protection -mtls-dialect=gnu " S["OBJEXT"]="o" S["EXEEXT"]="" S["ac_ct_CC"]="" @@ -783,7 +783,7 @@ S["CPPFLAGS"]="" S["LDFLAGS"]="-Wl,-z,relro -Wl,--as-needed -Wl,-z,pack-relative-relocs -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 " S["CFLAGS"]=" -O2 -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS "\ "-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m32 -march=i686 -mtune=gener"\ -"ic -msse2 -mfpmath=sse -mstackrealign -fasynchronous-unwind-tables -fstack-clash-protection -U__i686" +"ic -msse2 -mfpmath=sse -mstackrealign -fasynchronous-unwind-tables -fstack-clash-protection -mtls-dialect=gnu -U__i686" S["TargetPlatformFull"]="i386-unknown-linux" S["CrossCompilePrefix"]="" S["CrossCompiling"]="NO" So nothing obvious that would affect that, just perhaps if -mtls-dialect=gnu (added by redhat-rpm-config but also gcc 16 in rawhide is configured to default to that) might affect that. Ah, actually, this has nothing to do with gcc. Looking at the f43 build.log, I see /usr/bin/ld: _build/stage1/rts/build/c/sm/Compact.thr_dyn_o: warning: relocation in read-only section `.rodata' /usr/bin/ld: warning: creating DT_TEXTREL in a shared object So, it has been wrong before, just linker accepted that with a warning, now it is an error. That is a binutils change: * Tue Jan 13 2026 Nick Clifton <nickc> - 2.45.50-15 - Disallow the creation of shared object that use text relocations. (#2428281) Ah indeed - I was just looking at that changelog earlier today and wondering if it wasn't related :) Thank you for confirming. For completeness this what I see also with f43 gcc15 fwiw: | Run Ghc CompileCWithGhc Stage1: rts/sm/Compact.c => _build/stage1/rts/build/c/sm/Compact.thr_dyn_o _build/stage0/bin/ghc -Wall -hisuf thr_dyn_hi -osuf thr_dyn_o -hcsuf thr_dyn_hc -fPIC -dynamic -DTHREADED_RTS -optc-DTHREADED_RTS -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stage1/inplace/package.conf.d' '-this-unit-id rts-1.0.3' '-this-package-name rts' -i -i/builddir/build/BUILD/ghc9.14-9.14.1-build/ghc-9.14.1/_build/stage1/rts/build -i/builddir/build/BUILD/ghc9.14-9.14.1-build/ghc-9.14.1/_build/stage1/rts/build/autogen -i/builddir/build/BUILD/ghc9.14-9.14.1-build/ghc-9.14.1/rts/ -Irts/include -I_build/stage1/rts/build -I_build/stage1/rts/build/include -Irts/include -optP-include -optP_build/stage1/rts/build/autogen/cabal_macros.h -ghcversion-file=rts/include/ghcversion.h -optc-U__i686 -outputdir _build/stage1/rts/build -package-env=- -this-unit-id rts -XHaskell98 -no-global-package-db -package-db=/builddir/build/BUILD/ghc9.14-9.14.1-build/ghc-9.14.1/_build/stage1/inplace/package.conf.d -ghcversion-file=rts/include/ghcversion.h -ghcversion-file=rts/include/ghcversion.h -optc-U__i686 -optc-Irts/include -optc-I_build/stage1/rts/build -optc-I_build/stage1/rts/build/include -optc-Irts/include -optc-fPIC -optc-DDYNAMIC -Wnoncanonical-monad-instances -optc-Wno-error=inline -c rts/sm/Compact.c -o _build/stage1/rts/build/c/sm/Compact.thr_dyn_o -O0 -H64m -O -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Wundef -optc-fno-strict-aliasing -optc-DTHREADED_RTS -optc-fomit-frame-pointer -optc-O2 -optc-Irts -optc-I_build/stage1/rts/build -optc-DFS_NAMESPACE=rts -optc-DCOMPILING_RTS -optc-fno-PIC -optc-Wno-inline -optc-finline-limit=2500 -Irts -I_build/stage1/rts/build -DTHREADED_RTS -Wno-deprecated-flags -Wcpp-undef Apparently it is just due to a bad ghc hack to try to speed up linking. There is an MR already to remove it in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/15370 A build with a backport of this patch succeeds on i686. https://koji.fedoraproject.org/koji/taskinfo?taskID=141209242 I heard that change might also have broken fpc. |