This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Cc: John David Anglin <dave dot anglin at bell dot net>, Matthias Klose <doko at ubuntu dot com>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, gcc Development <gcc at gcc dot gnu dot org>, Ramana Radhakrishnan <ramana dot radhakrishnan at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Aurelien Jarno <aurel32 at debian dot org>
- Date: Fri, 4 Jul 2014 00:08:55 -0400 (EDT)
- Subject: Re: missing symbols in libstdc++.so.6 built from the 4.9 branch
- Authentication-results: sourceware.org; auth=none
- References: <53B273E6 dot 8040402 at ubuntu dot com> <CAH6eHdRQt13=pQesbAOwOVVYuuQQw=rD-cWC0+Ugv7ndDBJ+3w at mail dot gmail dot com> <BLU436-SMTP48F2A40D90438F0564A7BC97070 at phx dot gbl> <CAH6eHdRCvz+fyz6qcgzQhY9_-R-o7wW6FhvzAczUqCyGDRe38A at mail dot gmail dot com>
On Tue, 1 Jul 2014, Jonathan Wakely wrote:
> On 1 July 2014 20:58, John David Anglin wrote:
> > On 1-Jul-14, at 5:32 AM, Jonathan Wakely wrote:
> >
> >> On 1 July 2014 09:40, Matthias Klose wrote:
> >>>
> >>> - HPPA (build log [2]), is missing all the future_base symbols and
> >>> exception_ptr13exception symbols, current_exception and
> >>> rethrow_exception.
Apparently the cheat mentioned below didn't fully work. :)
> >> This implies ATOMIC_INT_LOCK_FREE <= 1 for that target. Our future and
> >> exception_ptr implementations rely on usable atomics.
> >
> >
> > ARM and HPPA use kernel assisted libraries for atomic support. Not exactly
> > lock free, but possibly good enough...
> >
> > Currently, c-cppbuiltin.c doesn't provide proper defines for this support.
> > We
> > currently define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, etc, in
> > pa-linux.h.
I thought that was cheating! 1/2 :)
> I'll experiment with defining ATOMIC_INT_LOCK_FREE there.
>
> It should already be defined,
Yes, if the proper insn patterns are in place, those macros are
automatically defined. They aren't if library functions are
called, regardless of lock-freelessness of those functions.
brgds, H-P