This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: c++/3082
- To: nathan at codesourcery dot com
- Subject: Re: c++/3082
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- Date: Fri, 8 Jun 2001 14:03:48 -0500 (CDT)
- CC: ljrittle at acm dot org, gcc-gnats at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org, nobody at gcc dot gnu dot org
- References: <3B20D206.C5FCA6F3@codesourcery.com>
- Reply-to: rittle at labs dot mot dot com
Hi Nathan,
In article <3B20D206.C5FCA6F3@codesourcery.com>,
Nathan Sidwell <nathan@codesourcery.com> writes:
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3082&database=gcc
> I agreee, this should be high priority.
>> Patch posted to libstdc++-v3, gcc-patches and installed on mainline
> are you refering to http://gcc.gnu.org/ml/gcc-patches/2001-06/msg00325.html
Sorry about not clarifying which patch set exactly. Yes, that patch
along with:
http://gcc.gnu.org/ml/gcc-patches/2001-06/msg00330.html
http://gcc.gnu.org/ml/gcc-patches/2001-06/msg00400.html (if you want
alpha/ELF working as best as possible with the other patches, but it
is not strictly required)
Additional commentary:
http://gcc.gnu.org/ml/gcc-patches/2001-06/msg00327.html
> or something else? Have you booted that patch on a 3.0 prerelease?
> Please provide cluons :-)
From that e-mail:
i386-unknown-freebsd4.2 (many earlier versions on mainline)
i386-unknown-freebsd4.2 (this version on 3.0 branch)
alpha-unknown-freebsd4.2 (this version on 3.0 branch)
i386-*-linux* (very close to this version on 3.0 branch)
hppa-*-hpux10* (very close to this version on 3.0 branch)
hppa-*-hpux11* (very close to this version on 3.0 branch)
sparc-sun-solaris2.7 (this version on 3.0 branch however
I don't usually build this target and every C++ test fails with:
ld.so.1: [...]: fatal: relocation error: R_SPARC_32: file [...]/libstdc++.so.3:
symbol __gxx_personality_v0: offset 0xff31cbe2 is non-aligned ---
This could be because I have an old/bad binutils; I used
--with-gnu-as and --with-gnu-ld or whatever. I have checked at the
source level that things are being setup properly for threads on this
port and I think the failure is independent of this patch but I have
not verified that yet.)