Skip to content

Cross-compiling to aarch64-multiplatform-musl fails with CPP #2362

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
thomasjm opened this issue May 17, 2025 · 1 comment
Open

Cross-compiling to aarch64-multiplatform-musl fails with CPP #2362

thomasjm opened this issue May 17, 2025 · 1 comment
Labels
bug Something isn't working

Comments

@thomasjm
Copy link
Contributor

thomasjm commented May 17, 2025

I'm trying to build a static aarch64 binary using pkgsCross.aarch64-multiplatform-musl on an x86_64-linux host, but it fails for packages containing CPP. For example, the pandoc-types package invokes CPP in one of its modules. When I try to build, I get an error like this (full logs below):

iserv-proxy-interpreter: internal error: 0x0 address for _ZZN12_GLOBAL__N_110get_globalEvE6global + 0 of type 562 in tmp/nix/store/n3hqwf99iff5xna2r17rld384j5hyb6c-aarch64-unknown-linux-musl-gcc-13.3.0/aarch64-unknown-linux-musl/lib/libstdc++.a(#40:eh_globals.o) for relocation 0 in section 4 of kind: 0

Steps To Reproduce

I'm using GHC 9.12.2, to avoid #2314. I made a repro which you can try like this:

# Building with aarch64-multiplatform-musl fails
nix build github:thomasjm/aarch64-cpp-repro#aarch64-multiplatform-musl

# Building with all of the following succeed
nix build github:thomasjm/aarch64-cpp-repro#aarch64-multiplatform
nix build github:thomasjm/aarch64-cpp-repro#musl64
nix build github:thomasjm/aarch64-cpp-repro#normal

Additional context

This is similar to #1115, but the build makes more progress than reported there.

Interestingly, the aarch64-multiplatform-musl target does work with the hackage method, like this:

(pkgs.pkgsCross.aarch64-multiplatform-musl.haskell-nix.hackage-package { compiler-nix-name = "ghc9122"; name = "pandoc-types"; }).components.library

which you can test like this:

nix build github:thomasjm/aarch64-cpp-repro#hackage

Logs:

Preprocessing library for pandoc-types-1.23.1..
Building library for pandoc-types-1.23.1..
[1 of 7] Compiling Paths_pandoc_types ( dist/build/autogen/Paths_pandoc_types.hs, dist/build/Paths_pandoc_types.o )
[2 of 7] Compiling Text.Pandoc.Definition ( src/Text/Pandoc/Definition.hs, dist/build/Text/Pandoc/Definition.o )
---> Starting iserv-proxy-interpreter on port 5157
---| iserv-proxy-interpreter should have started on 5157
Listening on port 5157
iserv-proxy-interpreter: internal error: 0x0 address for _ZZN12_GLOBAL__N_110get_globalEvE6global + 0 of type 562 in tmp/nix/store/n3hqwf99iff5xna2r17rld384j5hyb6c-aarch64-unknown-linux-musl-gcc-13.3.0/aarch64-unknown-linux-musl/lib/libstdc++.a(#40:eh_globals.o) for relocation 0 in section 4 of kind: 0

    (GHC version 9.12.2 for aarch64_unknown_linux)
    Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug
qemu: uncaught target signal 6 (Aborted) - core dumped
iserv-proxy: Uncaught exception ghc-internal:GHC.Internal.IO.Exception.IOException:

{handle: <socket: 9>}: GHCi.Message.remoteCall: end of file

HasCallStack backtrace:
  collectBacktraces, called at libraries/ghc-internal/src/GHC/Internal/Exception.hs:169:13 in ghc-internal:GHC.Internal.Exception
  toExceptionWithBacktrace, called at libraries/ghc-internal/src/GHC/Internal/Exception.hs:89:42 in ghc-internal:GHC.Internal.Exception
  throw, called at libraries/ghci/GHCi/Message.hs:673:16 in ghci-9.12.2-inplace:GHCi.Message

/nix/store/94ssjbg3g4lzki51qjrvc9ni3fqaakrx-iserv-wrapper/bin/iserv-wrapper: line 13:   457 Aborted                 /nix/store/xbfjilai721rzd9rf9dhhpv03xza4xp4-qemu-9.1.3/bin/qemu-aarch64 /nix/store/0116qb75b4d4pxwmvq6h6prh4cwhndg1-iserv-proxy-exe-iserv-proxy-interpreter-aarch64-unknown-linux-musl-9.3/bin/iserv-proxy-interpreter tmp $PORT $ISERV_ARGS
<no location info>: error: External interpreter terminated (1)
@thomasjm thomasjm added the bug Something isn't working label May 17, 2025
@angerman
Copy link
Collaborator

Yikes. C++ again. Thanks @thomasjm for the reproducer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants