On Fri, 20 Dec 2024, Prathamesh Kulkarni wrote:
> Hi,
> The previous patch (now reverted) had two different issues both stemming from
> the rule added in libatomic/Makefile.am:
> (1) As mentioned above, it broke multilib builds because it incorrectly
> copies libatomic.a in $(gcc_objdir). The attached patch fixes it by
> instead copying libatomic.a over to $(gcc_objdir)$(MULTISUBDIR)/, and can
> confirm that 64-bit libatomic.a is copied to $build/gcc/ and 32-bit
> libatomic.a is copied to $build/gcc/32/.
>
> (2) libatomic_convenience.la was not getting generated for some reason, which
> resulted in build failure while building libdruntime.
> The patch adds libatomic_convenience.la as a dependency, and I can see it now
> getting generated, which seems to fix the build issue with libdruntime.
>
> Patch passes bootstrap+test with multilib enabled for --enable-languages=all
> on x86_64-linux-gnu, and for --enable-languages=c,c++,fortran on
> aarch64-linux-gnu.
> Does this version look OK ?
This is OK.
To answer Jakub's question about passing -fno-link-libatomic when building
target libraries, I think it's reasonable for target libraries to use
atomic interfaces that may, on some targets, need libatomic.
(I'm not asserting that this patch by itself will make target libraries
using atomic interfaces work in cases that are currently broken.
Empirically, some such cases are broken already in ways that this patch
wouldn't fix. Bug 118280 reports libstdc++ for microblaze using
__atomic_test_and_set, which is not defined in libatomic - libatomic for
microblaze-linux-gnu has an undefined reference to that symbol itself,
only defining __atomic_test_and_set_{1,2,4,8,16}. And I'm not sure
there's currently a bug open for it, but for m68k-linux-gnu built for
ColdFire, libstdc++ has undefined references to hidden __sync_* symbols
defined in libgcc.a, which also prevents linking with libstdc++, but I
expect the fix for that would be to use t-slibgcc-libgcc in
libgcc/config.host for those targets, nothing to do with libatomic since
the symbols aren't in libatomic. In both cases, we could also take the
breakage as evidence that those targets are no longer being used outside
of bots building many different targets and so might be ripe for
obsolescence.)
--
Joseph S. Myers
josmy...@redhat.com
