Tracking http://gcc.gnu.org/ml/gcc/2009-05/msg00035.html as a bug report. Paolo checked in a patch in rev 147123 on the gcc-4_4-branch to do link tests for the atomic builtins, which works ok on hppa, but fails for arm.
the arm failure is PR40134 now.
To be clear, due to PR40134, the patch mentioned has been reverted for now.
*** Bug 40178 has been marked as a duplicate of this bug. ***
Created attachment 17900 [details] put ARM EABI atomic builtins in both shared and static libgcc I reviewed the original ARM EABI atomic builtins code submission, and there was no indication that making this code static-libgcc only was anything but an accident. The attached patch makes the code available in both the shared and static libgcc. With this patch and r147123 reapplied to my gcc-4.4 tree the libstdc++ build now finds the atomic builtins as it should: checking for atomic builtins for bool... yes checking for atomic builtins for short... yes checking for atomic builtins for int... yes checking for atomic builtins for long long... no
Subject: Re: exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa}-linux On Fri, 22 May 2009, mikpe at it dot uu dot se wrote: > Created an attachment (id=17900) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17900&action=view) > put ARM EABI atomic builtins in both shared and static libgcc > > I reviewed the original ARM EABI atomic builtins code submission, and there was > no indication that making this code static-libgcc only was anything but an > accident. The attached patch makes the code available in both the shared and > static libgcc. With this patch and r147123 reapplied to my gcc-4.4 tree the > libstdc++ build now finds the atomic builtins as it should: This patch is obviously wrong - if you put things in shared libgcc you also need to assign symbol versions to them based on the version in which they were actually added. I'm pretty sure making them static-only was deliberate (following SH which defines all the functions as hidden, which has the same effect as making them static-only, for example); the overhead of PLT calls is going to be significant for such small functions. Since the patch doesn't stop the functions being hidden in linux-atomic.c, I doubt it actually works (the question is not configure finding them, but whether C++ shared libraries that use them link OK with -shared-libgcc). The only use of having these functions in shared libgcc while still hidden is if other functions in libgcc use them. Now, I see that SH has libgcc/config/sh/t-linux which makes libgcc_s.so a linker script rather than a symlink. It's possible this could help for ARM, but on the whole I think it would be better for -shared-libgcc to use the static libgcc as needed after the shared one.
(In reply to comment #6) > This patch is obviously wrong - if you put things in shared libgcc you > also need to assign symbol versions to them based on the version in which > they were actually added. Yeah, I realized that shortly after posting the patch. My bad. > I'm pretty sure making them static-only was > deliberate (following SH which defines all the functions as hidden, which > has the same effect as making them static-only, for example); the overhead > of PLT calls is going to be significant for such small functions. Perhaps that was the motivation, but it's being applied very inconsistently. The ARM EABI backend puts lots of tiny functions, smaller than the __sync__ ones, in both the shared and static libgcc. > ..., but on the whole I think it would be better for -shared-libgcc to use > the static libgcc as needed after the shared one. Like a tweak to LINK_SPEC? I'll see if I can cook something up.
Created attachment 17902 [details] always pass -lgcc to linker The link error reported by Matthias Klose is caused by the following: 1. g++ links shared libraries with -shared-libgcc, which apparently is important whenever exceptions are possible. 2. -shared-libgcc by definition excludes the static libgcc from the link command. 3. Since the __sync__ procedures are only present in the static libgcc, it follows that they cannot be used by -shared-libgcc objects like libstdc++.so. One way around this is to redefine -shared-libgcc to actually link against the static libgcc, contrary to its intention. Both mingw32 and cygwin do this, so it's not unheard of. The attached patch updates ARM EABI to do just that. Passes a bootstrap and light testing here. However, I would strongly prefer to just move the __sync__ procedures to the shared libgcc (with symbol versions of course).
Two general comments: 1- Patches should be in any case posted to the gcc-patches mailing list; 2- I got previous feedbacks from Joseph as meaning that the issue is general, not restricted to the arm config; 3- Being a compiler issue I'm not even sure it should be discussed here - this PR is about the C++ library - probably PR40134 is the proper place.
Subject: Bug 40133 Author: doko Date: Sun Dec 13 23:45:12 2009 New Revision: 155200 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155200 Log: 2009-12-11 Paolo Carlini <paolo.carlini@oracle.com> Matthias Klose <doko@ubuntu.com> PR libstdc++/40133 * acinclude.m4 ([GLIBCXX_ENABLE_ATOMIC_BUILTINS]): On *-*-linux*, *-*-uclinux*, *-*-kfreebsd*-gnu | *-*-gnu* targets do link tests when possible. * configure: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure
fixed on the trunk