public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: libstdc++/2568
@ 2001-05-25 14:46 Rainer Orth
0 siblings, 0 replies; 9+ messages in thread
From: Rainer Orth @ 2001-05-25 14:46 UTC (permalink / raw)
To: bkoz; +Cc: gcc-prs
The following reply was made to PR libstdc++/2568; it has been noted by GNATS.
From: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
To: Brad Lucier <lucier@math.purdue.edu>
Cc: bkoz@gcc.gnu.org, gcc-gnats@gcc.gnu.org, David.Billinghurst@riotinto.com,
neil@gcc.gnu.org, amacleod@cygnus.com (Andrew Macleod)
Subject: Re: libstdc++/2568
Date: Fri, 25 May 2001 23:43:02 +0200 (MEST)
Brad Lucier writes:
> When configured with
>
> env CC='cc -xarch=v9 -xildoff' ../configure --prefix=/pkgs/gcc-2.96 sparcv9-sun-solaris2.8
>
> the bootstrap for today's 3.0 sources fails after a good compare with
I don't see any of this.
> while there is a c++configs.h in
>
> sparcv9-sun-solaris2.8/sparcv7/libstdc++-v3/include/bits/c++config.h
>
> relative to my build directory.
In a vanilla sparc-sun-solaris2.8 bootstrap for 3.0 (only
configure --prefix=/vol/gcc --local-prefix=/vol/gcc
with gcc 2.95 as bootstrap compiler), I have
sparc-sun-solaris2.8/libstdc++-v3/include/bits/c++config.h
Similarly for sparcv9-sun-solaris2.8, bootstrapped with
CC='cc -xarch=v9' \
configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc \
sparcv9-sun-solaris2.8
sparcv9-sun-solaris2.8/libstdc++-v3/include/bits/c++config.h
sparcv9-sun-solaris2.8/sparcv7/libstdc++-v3/include/bits/c++config.h
> This appears to be a configure problem; I already reported this problem in
>
> http://gcc.gnu.org/ml/gcc-patches/2001-05/msg01430.html
This report seems to indicate that you have Alexandre's patch to re-enable
32x64 bi-arch support in your tree? I'm just now running the bootstrap
with this, but it's not there yet.
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
Email: ro@TechFak.Uni-Bielefeld.DE
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libstdc++/2568
@ 2001-05-25 14:26 Brad Lucier
0 siblings, 0 replies; 9+ messages in thread
From: Brad Lucier @ 2001-05-25 14:26 UTC (permalink / raw)
To: bkoz; +Cc: gcc-prs
The following reply was made to PR libstdc++/2568; it has been noted by GNATS.
From: Brad Lucier <lucier@math.purdue.edu>
To: ro@TechFak.Uni-Bielefeld.DE (Rainer Orth)
Cc: lucier@math.purdue.edu (Brad Lucier), bkoz@gcc.gnu.org,
gcc-gnats@gcc.gnu.org, David.Billinghurst@riotinto.com, neil@gcc.gnu.org,
amacleod@cygnus.com (Andrew Macleod)
Subject: Re: libstdc++/2568
Date: Fri, 25 May 2001 16:19:53 -0500 (EST)
When configured with
env CC='cc -xarch=v9 -xildoff' ../configure --prefix=/pkgs/gcc-2.96 sparcv9-sun-solaris2.8
the bootstrap for today's 3.0 sources fails after a good compare with
/bin/sh ../libtool --mode=compile /export/home/lucier/gcc/gcc-3.0/objdir/gcc/xgcc -B/export/home/lucier/gcc/gcc-3.0/objdir/gcc/ -B/pkgs/gcc-2.96/sparcv9-sun-solaris2.8/bin/ -B/pkgs/gcc-2.96/sparcv9-sun-solaris2.8/lib/ -isystem /pkgs/gcc-2.96/sparcv9-sun-solaris2.8/include -DHAVE_CONFIG_H -I. -I../../../../libstdc++-v3/libmath -I.. -I../../../../libstdc++-v3/include -I../include -g -c ../../../../libstdc++-v3/libmath/signbit.c
mkdir .libs
/export/home/lucier/gcc/gcc-3.0/objdir/gcc/xgcc -B/export/home/lucier/gcc/gcc-3.0/objdir/gcc/ -B/pkgs/gcc-2.96/sparcv9-sun-solaris2.8/bin/ -B/pkgs/gcc-2.96/sparcv9-sun-solaris2.8/lib/ -isystem /pkgs/gcc-2.96/sparcv9-sun-solaris2.8/include -DHAVE_CONFIG_H -I. -I../../../../libstdc++-v3/libmath -I.. -I../../../../libstdc++-v3/include -I../include -g -c ../../../../libstdc++-v3/libmath/signbit.c -fPIC -DPIC -o .libs/signbit.o
In file included from ../../../../libstdc++-v3/libmath/signbit.c:32:
../../../../libstdc++-v3/libmath/mathconf.h:31:28: bits/c++config.h: No such file or directory
while there is a c++configs.h in
sparcv9-sun-solaris2.8/sparcv7/libstdc++-v3/include/bits/c++config.h
relative to my build directory.
This appears to be a configure problem; I already reported this problem in
http://gcc.gnu.org/ml/gcc-patches/2001-05/msg01430.html
Brad
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libstdc++/2568
@ 2001-05-25 12:46 Brad Lucier
0 siblings, 0 replies; 9+ messages in thread
From: Brad Lucier @ 2001-05-25 12:46 UTC (permalink / raw)
To: bkoz; +Cc: gcc-prs
The following reply was made to PR libstdc++/2568; it has been noted by GNATS.
From: Brad Lucier <lucier@math.purdue.edu>
To: ro@TechFak.Uni-Bielefeld.DE (Rainer Orth)
Cc: lucier@math.purdue.edu (Brad Lucier), bkoz@gcc.gnu.org,
gcc-gnats@gcc.gnu.org, David.Billinghurst@riotinto.com, neil@gcc.gnu.org,
amacleod@cygnus.com (Andrew Macleod)
Subject: Re: libstdc++/2568
Date: Fri, 25 May 2001 14:32:40 -0500 (EST)
Rainer Orth wrote:
> I'm not sure what I'll find, but I will compare make check results of
>
> * a sparc-sun-solaris2.8 configuration (sparcv7),
I just did one of these today, and I started a sparcv9-sun-solaris2.8
with (I believe) multilib support that should finish in a few
hours. (The bootstrap is fairly fast, it's the make check
that kills me.)
Brad
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libstdc++/2568
@ 2001-05-25 12:46 Rainer Orth
0 siblings, 0 replies; 9+ messages in thread
From: Rainer Orth @ 2001-05-25 12:46 UTC (permalink / raw)
To: bkoz; +Cc: gcc-prs
The following reply was made to PR libstdc++/2568; it has been noted by GNATS.
From: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
To: Brad Lucier <lucier@math.purdue.edu>
Cc: bkoz@gcc.gnu.org, gcc-gnats@gcc.gnu.org, David.Billinghurst@riotinto.com,
neil@gcc.gnu.org, amacleod@cygnus.com (Andrew Macleod)
Subject: Re: libstdc++/2568
Date: Fri, 25 May 2001 21:42:44 +0200 (MEST)
Brad Lucier writes:
> > * a sparc-sun-solaris2.8 configuration (sparcv7),
>
> I just did one of these today, and I started a sparcv9-sun-solaris2.8
> with (I believe) multilib support that should finish in a few
sparc-sun-solaris2.8 is bootstrap and check are finished,
sparcv9-sun-solaris2.8 bootstrap is done, check is well along, I'm waiting
for this to finish before I start the -m32 check.
> hours. (The bootstrap is fairly fast, it's the make check
> that kills me.)
Bootstrap is generally ok on an 2 x 400 MHz E250, although the bootstrap
takes considerably longer for sparcv9 (even up to the make compare), It's
obvious that building all libraries twice takes longer :-)
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
Email: ro@TechFak.Uni-Bielefeld.DE
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libstdc++/2568
@ 2001-05-25 12:36 Rainer Orth
0 siblings, 0 replies; 9+ messages in thread
From: Rainer Orth @ 2001-05-25 12:36 UTC (permalink / raw)
To: bkoz; +Cc: gcc-prs
The following reply was made to PR libstdc++/2568; it has been noted by GNATS.
From: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
To: Brad Lucier <lucier@math.purdue.edu>
Cc: bkoz@gcc.gnu.org, gcc-gnats@gcc.gnu.org, David.Billinghurst@riotinto.com,
neil@gcc.gnu.org, amacleod@cygnus.com (Andrew Macleod)
Subject: Re: libstdc++/2568
Date: Fri, 25 May 2001 21:28:14 +0200 (MEST)
Brad Lucier writes:
> Is this on the 3.0 branch or on the trunk (3.1)? I don't care if 3.0
The 3.0 branch. I don't start working on the trunk until the 3.0 release
is out of the door; I'd like to make sure as many problems as possible are
fixed once GCC 3.0 goes out.
> bootstraps on sparcv9 because I don't believe that 64-bit support
> works on the branch because Jakub's subreg-byte patches have not been applied
> there, and I can't find any code that looks like this in c-lex.c on the
> trunk at all, i.e., I couldn't even apply this patch manually to the trunk.
I'm not sure what I'll find, but I will compare make check results of
* a sparc-sun-solaris2.8 configuration (sparcv7),
* sparcv9-sun-solaris2.8 without multilib options (i.e. -m64) (sparcv9)
* sparcv9-sun-solaris2.8 with -m32 (sparcv7)
and maybe, time permitting, though this is by far the most interesting to
me
* bi-arch sparc-sun-solaris2.8 (default -m32) (sparcv7)
* bi-arch sparc-sun-solaris2.8 -m64 (sparcv9)
once I've re-enabled bi-arch/multilibbing for this configuration).
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
Email: ro@TechFak.Uni-Bielefeld.DE
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libstdc++/2568
@ 2001-05-25 12:26 Brad Lucier
0 siblings, 0 replies; 9+ messages in thread
From: Brad Lucier @ 2001-05-25 12:26 UTC (permalink / raw)
To: bkoz; +Cc: gcc-prs
The following reply was made to PR libstdc++/2568; it has been noted by GNATS.
From: Brad Lucier <lucier@math.purdue.edu>
To: ro@TechFak.Uni-Bielefeld.DE (Rainer Orth)
Cc: bkoz@gcc.gnu.org, gcc-gnats@gcc.gnu.org, lucier@math.purdue.edu,
David.Billinghurst@riotinto.com, neil@gcc.gnu.org,
amacleod@cygnus.com (Andrew Macleod)
Subject: Re: libstdc++/2568
Date: Fri, 25 May 2001 14:16:25 -0500 (EST)
Rainer Orth wrote:
> Applying Andrew's patch
>
> http://gcc.gnu.org/ml/gcc-patches/2001-04/msg01155.html
>
> allowed the bootstrap to complete, and the make check is now on it's way.
Is this on the 3.0 branch or on the trunk (3.1)? I don't care if 3.0
bootstraps on sparcv9 because I don't believe that 64-bit support
works on the branch because Jakub's subreg-byte patches have not been applied
there, and I can't find any code that looks like this in c-lex.c on the
trunk at all, i.e., I couldn't even apply this patch manually to the trunk.
Brad
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libstdc++/2568
@ 2001-05-25 12:06 Rainer Orth
0 siblings, 0 replies; 9+ messages in thread
From: Rainer Orth @ 2001-05-25 12:06 UTC (permalink / raw)
To: bkoz; +Cc: gcc-prs
The following reply was made to PR libstdc++/2568; it has been noted by GNATS.
From: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
To: bkoz@gcc.gnu.org, gcc-gnats@gcc.gnu.org, lucier@math.purdue.edu,
David.Billinghurst@riotinto.com, neil@gcc.gnu.org,
Andrew Macleod <amacleod@cygnus.com>
Cc:
Subject: Re: libstdc++/2568
Date: Fri, 25 May 2001 21:04:25 +0200 (MEST)
I've just run into the same problem bootstrapping for
sparcv9-sun-solaris2.8:
/vol/gcc/obj/gcc-3.0-20010523/8-sparcv9-cc.new/gcc/xgcc -B/vol/gcc/obj/gcc-3.0-20010523/8-sparcv9-cc.new/gcc/ -nostdinc++ -L/vol/gcc/obj/gcc-3.0-20010523/8-sparcv9-cc.new/sparcv9-sun-solaris2.8/libstdc++-v3/src -L/vol/gcc/obj/gcc-3.0-20010523/8-sparcv9-cc.new/sparcv9-sun-solaris2.8/libstdc++-v3/src/.libs -B/vol/gcc/sparcv9-sun-solaris2.8/bin/ -B/vol/gcc/sparcv9-sun-solaris2.8/lib/ -isystem /vol/gcc/sparcv9-sun-solaris2.8/include -nostdinc++ -I/vol/gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/include -I/vol /gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/include/std -I/vol/gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/include/c_std -I../include -I/vol/gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/libsupc++ -I../libio -I/vol/gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/libio -I/vol/gnu/src/gcc/gcc-3.0-branch-dist/libstdc++-v3/libmath -g -O2 -fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings -Winline -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -!
c c++locale.cc -fPIC -DPIC -o .libs/c++locale.o
c++locale.cc: In member function `void
std::numpunct<_CharT>::_M_initialize_numpunct(int*) [with _CharT =
wchar_t]':
c++locale.cc:66: character constant too long
c++locale.cc:67: character constant too long
c++locale.cc: In member function `void std::moneypunct<_CharT,
_Intl>::_M_initialize_moneypunct(int*) [with _CharT = wchar_t, bool _Intl =
false]':
c++locale.cc:96: character constant too long
c++locale.cc:97: character constant too long
make[4]: *** [c++locale.lo] Error 1
make[4]: Leaving directory `/vol/gcc/obj/gcc-3.0-20010523/8-sparcv9-cc.new/sparcv9-sun-solaris2.8/libstdc++-v3/src'
Applying Andrew's patch
http://gcc.gnu.org/ml/gcc-patches/2001-04/msg01155.html
allowed the bootstrap to complete, and the make check is now on it's way.
This is most likely the same problem as c/1739, so I'm Cc'ing David and
Neil on this as well. A make check on IRIX 6.2 with -mabi=64 is just on
it's way (without the c-lex.c fix above applied), and I'll probably
re-bootstrap when I'm done with that one. Unfortunately, the machine (an 2
CPU R8000 Power Challenge/L) is terribly slow, so this will most likely
take a considerable amount of time.
Regards.
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
Email: ro@TechFak.Uni-Bielefeld.DE
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libstdc++/2568
@ 2001-05-09 0:46 Brad Lucier
0 siblings, 0 replies; 9+ messages in thread
From: Brad Lucier @ 2001-05-09 0:46 UTC (permalink / raw)
To: bkoz; +Cc: gcc-prs
The following reply was made to PR libstdc++/2568; it has been noted by GNATS.
From: Brad Lucier <lucier@math.purdue.edu>
To: bkoz@gcc.gnu.org
Cc: gcc-gnats@gcc.gnu.org, lucier@math.purdue.edu, nobody@gcc.gnu.org
Subject: Re: libstdc++/2568
Date: Wed, 9 May 2001 02:39:58 -0500 (EST)
The problem is still there as of today's CVS sources.
Brad
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libstdc++/2568
@ 2001-05-08 23:56 bkoz
0 siblings, 0 replies; 9+ messages in thread
From: bkoz @ 2001-05-08 23:56 UTC (permalink / raw)
To: bkoz; +Cc: gcc-prs
The following reply was made to PR libstdc++/2568; it has been noted by GNATS.
From: bkoz@gcc.gnu.org
To: bkoz@gcc.gnu.org, gcc-gnats@gcc.gnu.org, lucier@math.purdue.edu,
nobody@gcc.gnu.org
Cc:
Subject: Re: libstdc++/2568
Date: 9 May 2001 06:52:11 -0000
Synopsis: libstdc++ build failure on sparcv9: "character constant too long"
Responsible-Changed-From-To: unassigned->bkoz
Responsible-Changed-By: bkoz
Responsible-Changed-When: Tue May 8 23:52:11 2001
Responsible-Changed-Why:
Responsible.
State-Changed-From-To: open->analyzed
State-Changed-By: bkoz
State-Changed-When: Tue May 8 23:52:11 2001
State-Changed-Why:
Brad what is current status on this?
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2568&database=gcc
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2001-05-25 14:46 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-05-25 14:46 libstdc++/2568 Rainer Orth
-- strict thread matches above, loose matches on Subject: below --
2001-05-25 14:26 libstdc++/2568 Brad Lucier
2001-05-25 12:46 libstdc++/2568 Rainer Orth
2001-05-25 12:46 libstdc++/2568 Brad Lucier
2001-05-25 12:36 libstdc++/2568 Rainer Orth
2001-05-25 12:26 libstdc++/2568 Brad Lucier
2001-05-25 12:06 libstdc++/2568 Rainer Orth
2001-05-09 0:46 libstdc++/2568 Brad Lucier
2001-05-08 23:56 libstdc++/2568 bkoz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).