boehm-gc: fix cross build of dependent packages #54402
Conversation
The configure script can't detect whether C11 atomic intrinsics are available when cross-compiling, so it links to libatomic_ops, which has to be propagated to all dependencies. To avoid this, assume that the atomic intrinsics are available.
lopsided98
force-pushed
the
boehm-gc-cross-fix
branch
from
32bca1e
to
30cda18
Compare
|
I got rid of the |
|
FWIW I fixed a related (but in a way entirely unrelated) issue when cross-compiling boehmgc w/musl: #55133 . I think builtin atomic support is reasonable assumption, and libatomic_ops's README.md opens with:
I'm slightly uncertain about how a gc using C11 atomics would interact with C++ atomics or gcc/clang atomic compatibility. I suppose those issues are the same either way, that is unless libatomic_ops does something clever (so the atomics are only used for internal consistency)? Anyway this hopefully is not a concern and one I'm only even considering from reading discussions of similar on llvm/libc++ development (where circumstances are perhaps different). On the "random things I read but aren't likely our situation but just in case" earlier this month glibc So perhaps worth keeping an eye on. All that said I think this is fine, and all those concerns above aren't valid if this only aligns with non-cross behavior which is what it sounds like O:). |
| @@ -35,7 +35,12 @@ stdenv.mkDerivation rec { | |||
| configureFlags = | |||
| [ "--enable-cplusplus" ] | |||
| ++ lib.optional enableLargeConfig "--enable-large-config" | |||
| ++ lib.optional (stdenv.hostPlatform.libc == "musl") "--disable-static"; | |||
| ++ lib.optional (stdenv.hostPlatform.libc == "musl") "--disable-static" | |||
There was a problem hiding this comment.
I wish I could remember why this is here, I'm not sure it's needed anymore but it's not hurting anyone as-is... xD
|
Yes, C11 atomics are already being used in native builds. |
c0bw3b
changed the title
boehm-gctries to detect whether the compiler supports C11 atomic intrinsics, and if not, it links tolibatomic_opsto provide equivalent functionality. This check requires running a program on the host architecture, so it cannot be done when cross-compiling. In that case, the configure script assumes the intrinsics are not available and links tolibatomic_ops. This is not new behavior, but the upgrade to 8.0.2 includes ivmai/bdwgc@02a44ee, which requires that ifboehm-gclinks tolibatomic_ops, all packages that depend onboehm-gcmust also link tolibatomic_ops. This broke cross-compiledguile,nixand probably anything else that depends onboehm-gc.One solution is to make
libatomic_opsapropagatedBuildInput, but this is not really a great solution because most of the timelibatomic_opsis not really needed. Onx86_64-linux,armv6l-linux,armv7l-linuxandaarch64-linux, native builds ofboehm-gcdo not link tolibatomic_opsand therefore it shouldn't be needed when cross-compiling to those platforms. I do not know of any supported architectures that do not have C11 atomic intrinsics, except thatarmv6l-linuxrequireslibatomic(different fromlibatomic_ops) to support certain intrinsics. AFAICT,libatomicis not needed forboehm-gc.Alternatively (and what this PR does), we can just unconditionally disable
libatomic_opswhen cross-compiling. This could possibly "break" (it would already be broken because of the missing dep) a platform I have not tested, but seems cleaner than propagatinglibatomic_ops.Note that this problem is not specific to cross-compiling, any platform that actually needs
libatomic_opswill be broken natively right now because of the missing propagation. We should actually removelibatomic_opsas a build input altogether, since it can't work correctly unless it is propagated. The only reason I didn't do that in this PR is that it would cause a mass rebuild.I also removed the
dontStripline, which I believe is a relic from the past.sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)nix path-info -Sbefore and after)