From ruby.src code: With binutils-2.44-1.fc42 $ cat conftest.c #include <stdio.h> int main(void) { puts(__func__); } $ $ gcc -o conftest -mbranch-protection=standard conftest.c -lz -lcrypt -lgmp >/dev/null ; echo $? /usr/lib/gcc/aarch64-redhat-linux/15/../../../../lib64/libz.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking. /usr/lib/gcc/aarch64-redhat-linux/15/../../../../lib64/libcrypt.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking. /usr/lib/gcc/aarch64-redhat-linux/15/../../../../lib64/libgmp.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking. 0 binutils-2.43.50-12.fc42 does not show such warnings. (Trying with gcc-15.0.1-0.7.fc42.aarch64) Reproducible: Always
Currently $ gcc -o conftest -mbranch-protection=standard conftest.c -lz -lcrypt -lgmp -Wl,-z,gcs-report=none seems a workaround for the above warnings.
This is actually a problem with the shared libraries. When AArch64 binaries are built with the -mbranch-protection=standard option they are labelled as supporting the GTS mechanism. In order for the mechanism to work however all the input binaries (and shared libraries used) need to support GTS, so the linker checks to make sure that this has happened. In this particular case the conftest.c source file has been compiled with GTS support, as have the GCC support libraries and startup files. But the libz, libcrypt and libgmp libraries have not. This is probably a rebuild issue - ie the problem will go away once those libraries are rebuilt with the latest gcc, which should happen in the upcoming mass rebuild.
(In reply to Nick Clifton from comment #2) Thx for the details đ > This is probably a rebuild issue - ie the problem will go away once those > libraries are rebuilt with the latest gcc, which should happen in the > upcoming mass rebuild. We are past F42 mass rebuild, aren't we? Or is there some other GCC related mass rebuild planed? Although GMP for example failed that build: https://koji.fedoraproject.org/koji/buildinfo?buildID=2620795
(In reply to Nick Clifton from comment #2) So your comment means that basically another mass rebuild is needed, with keeping in mind dependency order?
GMP seems to have failed the mass rebuild and logs (AFAICT) garbage collected. The other two seem to have succeeded however and appear to have been compiled with -mbranch-protection=standard, so maybe this needs closer inspection to see if the property notes are indeed missing or if there's some other problem.
*** Bug 2344195 has been marked as a duplicate of this bug. ***
*** Bug 2344330 has been marked as a duplicate of this bug. ***
Proposed as a Blocker for 42-beta by Fedora user ngompa using the blocker tracking app because: This makes it impossible to update certain release-blocking stacks due to failures on ARM (such as KDE Plasma).
Should be fixed by binutils-2.44-2.fc43 and binutils-2.44-2.fc42.
ruby is now okay with binutils-2.44-3.fc42
Neal, can you confirm if your use cases are now OK with current f42 stable packages?
(In reply to Adam Williamson from comment #11) > Neal, can you confirm if your use cases are now OK with current f42 stable > packages? I can confirm that arm64 builds are working fine now on f42/rawhide.
(In reply to Adam Williamson from comment #11) > Neal, can you confirm if your use cases are now OK with current f42 stable > packages? As Steve said, we're good now. Thanks!
ok, so let's close it.