Bug#1052144: ghc: Needs to link against libatomic on at least m68k

[John Paul Adrian Glaubitz]

Source: ghc
Version: 9.4.6-1
Severity: normal
User: debia...@lists.debian.org
Usertags: m68k
X-Debbugs-Cc: debia...@lists.debian.org

Hello!

On m68k, building ghc fails with:

"inplace/bin/ghc-stage1" -o utils/iserv/stage2_p/build/tmp/ghc-iserv-prof -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -H32m -O -lffi -optl-pthread -Wall -hide-all-packages -package-env - -i -iutils/iserv/src -iutils/iserv/stage2_p/build -Iutils/iserv/stage2_p/build -iutils/iserv/stage2_p/build/iserv/autogen -Iutils/iserv/stage2_p/build/iserv/autogen -Iutils/iserv/. -Iutils/iserv/stage2_p/build/. -optP-include -optPutils/iserv/stage2_p/build/iserv/autogen/cabal_macros.h -package-id array-0.5.4.0 -package-id base-4.17.2.0 -package-id binary-0.8.9.1 -package-id bytestring-0.11.5.1 -package-id containers-0.6.7 -package-id deepseq-1.4.8.0 -package-id ghci-9.4.6 -package-id libiserv-9.4.6 -package-id unix-2.7.3 -no-hs-main -XHaskell2010 -threaded -optl-Wl,--export-dynamic -no-hs-main -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -outputdir utils/iserv/stage2_p/build -split-sections -static -prof -H32m -O -lffi -optl-pthread -Wall -hide-all-packages -package-env - -i -iutils/iserv/src -iutils/iserv/stage2_p/build -Iutils/iserv/stage2_p/build -iutils/iserv/stage2_p/build/iserv/autogen -Iutils/iserv/stage2_p/build/iserv/autogen -Iutils/iserv/. -Iutils/iserv/stage2_p/build/. -optP-include -optPutils/iserv/stage2_p/build/iserv/autogen/cabal_macros.h -package-id array-0.5.4.0 -package-id base-4.17.2.0 -package-id binary-0.8.9.1 -package-id bytestring-0.11.5.1 -package-id containers-0.6.7 -package-id deepseq-1.4.8.0 -package-id ghci-9.4.6 -package-id libiserv-9.4.6 -package-id unix-2.7.3 -no-hs-main -XHaskell2010 -threaded -optl-Wl,--export-dynamic -no-hs-main -no-user-package-db -rtsopts -Wnoncanonical-monad-instances utils/iserv/stage2_p/build/Main.p_o utils/iserv/stage2_p/build/cbits/iservmain.p_o
Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main.
Call hs_init_ghc() from your main() function to set these options.
/usr/bin/ld.bfd: /<<PKGBUILDDIR>>/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.9.1_p.a(atomic.p_o): in function `hs_cmpxchg64':
atomic.c:(.text.hs_cmpxchg64+0x16): undefined reference to `__sync_val_compare_and_swap_8'
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)
make[2]: *** [utils/iserv/ghc.mk:104: utils/iserv/stage2_p/build/tmp/ghc-iserv-prof] Error 1
make[2]: *** Waiting for unfinished jobs....


which indicates that the build needs to link against libatomic.

This issue has also been reported upstream [1].

Thanks,
Adrian

> [1] https://gitlab.haskell.org/ghc/ghc/-/issues/23974

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

[John Paul Adrian Glaubitz]

Control: tags -1 +patch

Hi!

The attached patch fixes the issue for me. The underlying problem is
the use of legacy atomic functions for which no 64-bit variants exist
on some architectures [1]. See also the upstream discussion here [2].

While this patch fixes the original problem, the stage2 build later
fails due to memory exhaustion for which I haven't found a solution
yet.

Thanks,
Adrian

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368
> [2] https://gitlab.haskell.org/ghc/ghc/-/issues/23974

[Ilias Tsitsimpis]

Hi Adrian,

On Fri, Sep 22, 2023 at 09:20AM, John Paul Adrian Glaubitz wrote:
> The attached patch fixes the issue for me. The underlying problem is
> the use of legacy atomic functions for which no 64-bit variants exist
> on some architectures [1]. See also the upstream discussion here [2].

Is this patch enough, or do we have to backport this [1] as well?

[1] https://gitlab.haskell.org/ghc/ghc/-/commit/fc186b0c0ac56d6ff6225d3f6607be37770fcb52

> While this patch fixes the original problem, the stage2 build later
> fails due to memory exhaustion for which I haven't found a solution
> yet.

I faced the same issue on mipsel (see [2]) and never found a solution
for it. Luckily, mipsel got removed from release architectures.

[2] https://lists.debian.org/debian-mips/2023/07/msg00057.html

Best,

--
Ilias

[Ilias Tsitsimpis]

Hi Adrian,

On Sat, Oct 14, 2023 at 11:35AM, John Paul Adrian Glaubitz wrote:
> Attaching an updated version of the patch which applies against the 9.4.7-1
> version of the ghc package. Would be nice if it could be included for the
> next upload.

Thanks for the reminder, I will include this in the next upload.

As a side note, I believe the attached patch is wrong, it changes the
semantics of the functions. Notice that __sync_val_compare_and_swap()
returns the initial value of the variable x, whereas
__atomic_compare_exchange() returns true/false, depending on whether the
operation succeeded. The correct patch is here [1].

Could this be the reason why your cross-compiler for m68k seg-faults?

[1] https://gitlab.haskell.org/ghc/ghc/-/commit/f8fa1d08d7cbfef508bab355bda80f495e928f98

Best,

--
Ilias