* Re: build failure
@ 2000-07-27 13:01 Phil Edwards
2000-07-27 21:14 ` Marc Espie
0 siblings, 1 reply; 21+ messages in thread
From: Phil Edwards @ 2000-07-27 13:01 UTC (permalink / raw)
To: pedwards, pfeifer; +Cc: gcc, janr, marianig, mrs
> > Unfortunately CVS has no facilities for inspecting a repository
> > /before/ a checkout, e.g., asking the server, "What branches are
> > available for module <foo>?" and then only checking out that branch.
>
> Using our cvsweb interface (from the CVS web page) this should be
> possible.
Yeah, but that's cvs*web*; the user has to pull the browser into the picture.
I'm wanting that in cvs itself... oh well, something else to consider as
an extension to the cvs protocol.
Phil
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: build failure
2000-07-27 13:01 build failure Phil Edwards
@ 2000-07-27 21:14 ` Marc Espie
2000-07-28 10:15 ` Lee Iverson
2000-07-28 10:32 ` Joern Rennecke
0 siblings, 2 replies; 21+ messages in thread
From: Marc Espie @ 2000-07-27 21:14 UTC (permalink / raw)
To: pedwards; +Cc: gcc
In article < 200007272002.QAA13443@disaster.jaj.com > you write:
>> > Unfortunately CVS has no facilities for inspecting a repository
>> > /before/ a checkout, e.g., asking the server, "What branches are
>> > available for module <foo>?" and then only checking out that branch.
>> Using our cvsweb interface (from the CVS web page) this should be
>> possible.
>Yeah, but that's cvs*web*; the user has to pull the browser into the picture.
>I'm wanting that in cvs itself... oh well, something else to consider as
>an extension to the cvs protocol.
If you ever feel like extending the cvs protocol, wack yourself in the head
until that crazy notion vanishes.
cvs has lots of shortcomings. It would probably much better to rewrite things
from the ground up than trying to beat sense into it...
(not being able to rename files without losing a sense of history comes to
mind. Not being able to use import on anything but the trunk as well)
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: build failure
2000-07-27 21:14 ` Marc Espie
@ 2000-07-28 10:15 ` Lee Iverson
2000-07-28 10:32 ` Joern Rennecke
1 sibling, 0 replies; 21+ messages in thread
From: Lee Iverson @ 2000-07-28 10:15 UTC (permalink / raw)
To: Marc Espie; +Cc: pedwards, gcc
In message < 200007272346.BAA20555@quatramaran.ens.fr >, Marc Espie writes:
>
>If you ever feel like extending the cvs protocol, wack yourself in the head
>until that crazy notion vanishes.
>
>cvs has lots of shortcomings. It would probably much better to rewrite things
>from the ground up than trying to beat sense into it...
You do want to check out Subversion. Currently only a design
document, but a Hello World release is planned for 09/01.
http://subversion.tigris.org/project_docs.html
Still opportunity to influence the design and get on board early.
-------------------------------------------------------------------------------
Lee Iverson SRI International
leei@ai.sri.com 333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/ (650) 859-3307
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: build failure
2000-07-27 21:14 ` Marc Espie
2000-07-28 10:15 ` Lee Iverson
@ 2000-07-28 10:32 ` Joern Rennecke
1 sibling, 0 replies; 21+ messages in thread
From: Joern Rennecke @ 2000-07-28 10:32 UTC (permalink / raw)
To: Marc Espie; +Cc: pedwards, gcc
> (not being able to rename files without losing a sense of history comes to
> mind. Not being able to use import on anything but the trunk as well)
It would also make sense to be able to re-base a branch on a new branchpoint.
That would prevent degradation where a branch continues mostly, but not quite,
merged into the future, and you want to access the newest versions in general.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Build failure
2001-06-12 10:30 Jan Kroken
2001-06-12 20:42 ` Alexandre Oliva
@ 2001-06-13 4:56 ` Jan Kroken
1 sibling, 0 replies; 21+ messages in thread
From: Jan Kroken @ 2001-06-13 4:56 UTC (permalink / raw)
To: gcc
Jan Kroken <jankr@ifi.uio.no> writes:
> I tried to compile the two last prereleases (2001-06-(4|11) on
> my two linux boxes, but I have yet to succeed. Both boxes run
> Linux, and both are pretty upgraded (last release, sometimes
> betas, of most of the software/libraries).
>
> Machine A is
> no recognizable distro (was RedHat 6.0 once)
> linux-2.4.2
> glibc-2.2.2
> CC = gcc-2.95.3
> CFLAGS = -march=pentium -O3 -ffast-math
> Machibe B is
> RedHat 6.1
> linux-2.2.19
> glibc-2.1.2
> CC = gcc-2.95.2
> CFLAGS =
>
> The compile sequence is
>
> ./configure --prefix=/usr/gcc-beta
> make
> make install (yet to be run :( )
Tried with
gcc-build% ../gcc-20010611/configure --prefix=/usr/gcc-beta
gcc-build% make bootstrap
> Currently, it fails with the following on machine A:
On machine A, it now works.
On machine B, it still fails at the same place:
stage1/xgcc -Bstage1/ -B/usr/gcc-beta/i686-pc-linux-gnu/bin/ -c -DIN_GCC -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -I. -Ijava -I../../gcc-20010611/gcc -I../../gcc-20010611/gcc/java -I../../gcc-20010611/gcc/config -I../../gcc-20010611/gcc/../include ../../gcc-20010611/gcc/java/boehm.c -o java/boehm.o
rm -f jc1
stage1/xgcc -Bstage1/ -B/usr/gcc-beta/i686-pc-linux-gnu/bin/ -DIN_GCC -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -o jc1 \
java/parse.o java/class.o java/decl.o java/expr.o java/constants.o java/lang.o java/typeck.o java/except.o java/verify.o java/zextract.o java/jcf-io.o java/jcf-parse.o java/mangle.o java/mangle_name.o java/jcf-write.o java/buffer.o java/check-init.o java/jcf-depend.o java/jcf-path.o java/xref.o java/boehm.o mkdeps.o toplev.o libbackend.a -L../zlib -lz obstack.o ../libiberty/libiberty.a
java/parse.o: In function `java_new_lexer':
/usr/tmp/gcc-build/gcc/../../gcc-20010611/gcc/java/lex.c:233: undefined reference to `libiconv_open'
/usr/tmp/gcc-build/gcc/../../gcc-20010611/gcc/java/lex.c:253: undefined reference to `libiconv_open'
/usr/tmp/gcc-build/gcc/../../gcc-20010611/gcc/java/lex.c:271: undefined reference to `libiconv'
/usr/tmp/gcc-build/gcc/../../gcc-20010611/gcc/java/lex.c:272: undefined reference to `libiconv_close'
java/parse.o: In function `java_destroy_lexer':
/usr/tmp/gcc-build/gcc/../../gcc-20010611/gcc/java/lex.c:308: undefined reference to `libiconv_close'
java/parse.o: In function `java_read_char':
/usr/tmp/gcc-build/gcc/../../gcc-20010611/gcc/java/lex.c:373: undefined reference to `libiconv'
collect2: ld returned 1 exit status
make[2]: *** [jc1] Error 1
make[2]: Leaving directory `/usr/tmp/gcc-build/gcc'
make[1]: *** [stage2_build] Error 2
make[1]: Leaving directory `/usr/tmp/gcc-build/gcc'
make: *** [bootstrap] Error 2
/usr/tmp/gcc-build%
--
-jk
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Build failure
2001-06-12 10:30 Jan Kroken
@ 2001-06-12 20:42 ` Alexandre Oliva
2001-06-13 4:56 ` Jan Kroken
1 sibling, 0 replies; 21+ messages in thread
From: Alexandre Oliva @ 2001-06-12 20:42 UTC (permalink / raw)
To: Jan Kroken; +Cc: gcc
On Jun 12, 2001, Jan Kroken <jankr@ifi.uio.no> wrote:
> ./configure --prefix=/usr/gcc-beta
This contradicts the installation instructions, that recommend the use
of a separate build directory. There's a (pending?) patch that fixes
this particular problem, and that should make it possible for one to
build GCC with srcdir = objdir, but this is not supported as of the
latest snapshot.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me
^ permalink raw reply [flat|nested] 21+ messages in thread
* re: Build failure
@ 2001-06-12 12:21 Jan van Male
0 siblings, 0 replies; 21+ messages in thread
From: Jan van Male @ 2001-06-12 12:21 UTC (permalink / raw)
To: gcc; +Cc: jankr
>The compile sequence is
>
>./configure --prefix=/usr/gcc-beta
>make
>make install (yet to be run :( )
Use 'make bootstrap' instead of 'make'.
Last time I tried, 'make' failed on me too.
jan
^ permalink raw reply [flat|nested] 21+ messages in thread
* Build failure
@ 2001-06-12 10:30 Jan Kroken
2001-06-12 20:42 ` Alexandre Oliva
2001-06-13 4:56 ` Jan Kroken
0 siblings, 2 replies; 21+ messages in thread
From: Jan Kroken @ 2001-06-12 10:30 UTC (permalink / raw)
To: gcc
I tried to compile the two last prereleases (2001-06-(4|11) on
my two linux boxes, but I have yet to succeed. Both boxes run
Linux, and both are pretty upgraded (last release, sometimes
betas, of most of the software/libraries).
Machine A is
no recognizable distro (was RedHat 6.0 once)
linux-2.4.2
glibc-2.2.2
CC = gcc-2.95.3
CFLAGS = -march=pentium -O3 -ffast-math
Machibe B is
RedHat 6.1
linux-2.2.19
glibc-2.1.2
CC = gcc-2.95.2
CFLAGS =
The compile sequence is
./configure --prefix=/usr/gcc-beta
make
make install (yet to be run :( )
Currently, it fails with the following on machine A:
checking for /home_2/jankr/gcc-20010611/i586-pc-linux-gnu/libstdc++-v3/include
updating cache ../config.cache
creating ./config.status
creating Makefile
creating src/Makefile
creating libmath/Makefile
creating libio/Makefile
creating libsupc++/Makefile
creating testsuite/Makefile
creating mkcheck
creating testsuite_flags
creating config.h
linking ./config/os/gnu-linux/bits/os_defines.h to include/bits/os_defines.h
linking ./config/c_io_stdio.h to include/bits/c++io.h
linking ./config/basic_file_stdio.h to include/bits/basic_file_model.h
linking ./config/basic_file_stdio.cc to src/basic_file.cc
linking ./config/c_io_libio_codecvt.c to libio/c_codecvt.c
linking ./config/c_locale_generic.h to include/bits/c++locale.h
linking ./config/c_locale_generic.cc to src/c++locale.cc
linking ./../gcc/gthr.h to include/bits/gthr.h-in
configure: error: ./../gcc/gthr.h: File not found
make: *** [configure-target-libstdc++-v3] Error 1
on machine B:
gcc -c -DIN_GCC -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -I. -Ijava -I. -I./java -I./config -I./../include java/buffer.c -o java/buffer.o
gcc -c -DIN_GCC -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -I. -Ijava -I. -I./java -I./config -I./../include java/check-init.c -o java/check-init.o
gcc -c -DIN_GCC -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -I. -Ijava -I. -I./java -I./config -I./../include java/jcf-depend.c -o java/jcf-depend.o
gcc -c -DIN_GCC -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -I. -Ijava -I. -I./java -I./config -I./../include \
-DLIBGCJ_ZIP_FILE='"/usr/gcc-beta/share/libgcj.jar"' \
./java/jcf-path.c -o java/jcf-path.o
gcc -c -DIN_GCC -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -I. -Ijava -I. -I./java -I./config -I./../include java/xref.c -o java/xref.o
gcc -c -DIN_GCC -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -I. -Ijava -I. -I./java -I./config -I./../include java/boehm.c -o java/boehm.o
rm -f jc1
gcc -DIN_GCC -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -o jc1 \
java/parse.o java/class.o java/decl.o java/expr.o java/constants.o java/lang.o java/typeck.o java/except.o java/verify.o java/zextract.o java/jcf-io.o java/jcf-parse.o java/mangle.o java/mangle_name.o java/jcf-write.o java/buffer.o java/check-init.o java/jcf-depend.o java/jcf-path.o java/xref.o java/boehm.o mkdeps.o toplev.o libbackend.a -L../zlib -lz obstack.o ../libiberty/libiberty.a
java/parse.o: In function `java_new_lexer':
/usr/tmp/gcc-20010611/gcc/java/lex.c:233: undefined reference to `libiconv_open'
/usr/tmp/gcc-20010611/gcc/java/lex.c:253: undefined reference to `libiconv_open'
/usr/tmp/gcc-20010611/gcc/java/lex.c:271: undefined reference to `libiconv'
/usr/tmp/gcc-20010611/gcc/java/lex.c:272: undefined reference to `libiconv_close'
java/parse.o: In function `java_destroy_lexer':
/usr/tmp/gcc-20010611/gcc/java/lex.c:308: undefined reference to `libiconv_close'
java/parse.o: In function `java_read_char':
/usr/tmp/gcc-20010611/gcc/java/lex.c:373: undefined reference to `libiconv'
collect2: ld returned 1 exit status
make[1]: *** [jc1] Error 1
make[1]: Leaving directory `/usr/tmp/gcc-20010611/gcc'
make: *** [all-gcc] Error 2
if you need the entire compile output, or more details about my system, I'll provide it.
--
-jk
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: build failure
2000-07-26 10:40 Jan Reimers
@ 2000-07-27 19:10 ` Rich Churcher
0 siblings, 0 replies; 21+ messages in thread
From: Rich Churcher @ 2000-07-27 19:10 UTC (permalink / raw)
To: Jan Reimers; +Cc: 'Phil Edwards', 'gcc@gcc.gnu.org'
Jan Reimers <janr@molienergy.bc.ca> writes:
> > -----Original Message-----
> > From: Phil Edwards [ mailto:pedwards@disaster.jaj.com ]
[ snip ]
> > Known situation; libstdc++-v3 currently will not build on
> > most platforms.
> > (It's in the middle of a big transition.) You might take a
> > look at the
> > last few days of the libstdc++ mailing list archive.
>
> Perhaps you could give us a heads up when we can try bootstrapping again.
Yes please - that would be much appreciated.
--
Cheers,
Rich.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: build failure
2000-07-27 8:36 build failure Phil Edwards
@ 2000-07-27 9:29 ` Gerald Pfeifer
0 siblings, 0 replies; 21+ messages in thread
From: Gerald Pfeifer @ 2000-07-27 9:29 UTC (permalink / raw)
To: Phil Edwards; +Cc: marianig, gcc, janr, mrs
On Thu, 27 Jul 2000, Phil Edwards wrote:
> I don't know what the Steering Committee's rules are for branches.
> (I just work here, d'ya want fries with that?)
I'm not aware of any specific rules. Rather, I think it usually works
is follows: You post a message to gcc@gcc.gnu.org, ``Hi folks, we are
planning to do xyz which will take some time and carries a high risk
of breaking the tree, so we'd like to do development on a CVS branch.
Unless someone objects, I'm going to create a branch called abc in
about a week.''
> Unfortunately CVS has no facilities for inspecting a repository
> /before/ a checkout, e.g., asking the server, "What branches are
> available for module <foo>?" and then only checking out that branch.
Using our cvsweb interface (from the CVS web page) this should be
possible.
Gerald
--
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
Have a look at http://petition.eurolinux.org -- it's not about Linux, BTW!
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: build failure
@ 2000-07-27 8:36 Phil Edwards
2000-07-27 9:29 ` Gerald Pfeifer
0 siblings, 1 reply; 21+ messages in thread
From: Phil Edwards @ 2000-07-27 8:36 UTC (permalink / raw)
To: marianig; +Cc: gcc, janr, mrs
Gianni Mariani <marianig@orconet.com>:
> I'm probably way out of line here but I've been amazed at how many people
> don't use branches in CVS so at the risk of sounding like an idiot.
>
> Did you think about using CVS branches ?
I can't speak for the rest of the project, but my understanding is that
nobody thought that the change would cause as many problems as it has.
I don't know what the Steering Committee's rules are for branches. (I just
work here, d'ya want fries with that?) I see a lot of tags for snapshots
and "bounded pointer" things. Unfortunately CVS has no facilities for
inspecting a repository /before/ a checkout, e.g., asking the server,
"What branches are available for module <foo>?" and then only checking
out that branch.
Phil
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: build failure
2000-07-26 10:33 Phil Edwards
@ 2000-07-27 8:11 ` Gianni Mariani
0 siblings, 0 replies; 21+ messages in thread
From: Gianni Mariani @ 2000-07-27 8:11 UTC (permalink / raw)
To: Phil Edwards; +Cc: gcc, janr, mrs
I'm probably way out of line here but I've been amazed at how many people
don't use branches in CVS so at the risk of sounding like an idiot.
Did you think about using CVS branches ?
Phil Edwards wrote:
> Mike Stump <mrs@windriver.com>:
> > > From: Phil Edwards <pedwards@disaster.jaj.com>
> >
> > > Known situation; libstdc++-v3 currently will not build on most platforms.
> >
> > This isn't a feature. :-(
>
> No, it isn't. What's your point?
>
> > > (It's in the middle of a big transition.)
> >
> > Poor excuse.
>
> It's not meant to be an excuse. It's simply the current state of things.
> That's the risk of using current CVS, as the original poster is using.
>
> Please, take a look at the last 36 hours or so of messages on the library
> mailing list. Nobody else likes it either, especially the project leads,
> and they're working hard to get it fixed.
>
> Phil
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: build failure
2000-07-25 16:52 ` Gianni Mariani
@ 2000-07-26 13:17 ` Gerald Pfeifer
0 siblings, 0 replies; 21+ messages in thread
From: Gerald Pfeifer @ 2000-07-26 13:17 UTC (permalink / raw)
To: Gianni Mariani; +Cc: Phil Edwards, gcc, janr
On Tue, 25 Jul 2000, Gianni Mariani wrote:
> There are patches to apply ? Am I supposed to take these patches ?
No, I was talking about patches being submitted to the libstdc++ 3 team.
You don't have to worry about these, the libstdc++ 3 team is taking care
of them and, if suitable, applies them to the CVS repository from where
you will get them automatically next time you download GCC.
Gerald
--
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: build failure
@ 2000-07-26 10:40 Jan Reimers
2000-07-27 19:10 ` Rich Churcher
0 siblings, 1 reply; 21+ messages in thread
From: Jan Reimers @ 2000-07-26 10:40 UTC (permalink / raw)
To: 'Phil Edwards'; +Cc: 'gcc@gcc.gnu.org'
> -----Original Message-----
> From: Phil Edwards [ mailto:pedwards@disaster.jaj.com ]
> Sent: Tuesday, July 25, 2000 12:55 PM
> To: gcc@gcc.gnu.org; janr@molienergy.bc.ca
> Subject: Re: build failure
>
>
>
> > CVS checkout (July/21/2000) of the gcc sources fails to build with
> > libstdcxx-v3 enabled. The build failure is in
> libstdc++-v3. Should details
> > be reported here or to the libstdc++ mailing?
>
> Known situation; libstdc++-v3 currently will not build on
> most platforms.
> (It's in the middle of a big transition.) You might take a
> look at the
> last few days of the libstdc++ mailing list archive.
Perhaps you could give us a heads up when we can try bootstrapping again.
>
> The library is part of gcc now; if you get CVS sources for gcc, you've
> got the latest library sources too.
OK Thanks.
JR
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: build failure
@ 2000-07-26 10:33 Phil Edwards
2000-07-27 8:11 ` Gianni Mariani
0 siblings, 1 reply; 21+ messages in thread
From: Phil Edwards @ 2000-07-26 10:33 UTC (permalink / raw)
To: gcc, janr, mrs
Mike Stump <mrs@windriver.com>:
> > From: Phil Edwards <pedwards@disaster.jaj.com>
>
> > Known situation; libstdc++-v3 currently will not build on most platforms.
>
> This isn't a feature. :-(
No, it isn't. What's your point?
> > (It's in the middle of a big transition.)
>
> Poor excuse.
It's not meant to be an excuse. It's simply the current state of things.
That's the risk of using current CVS, as the original poster is using.
Please, take a look at the last 36 hours or so of messages on the library
mailing list. Nobody else likes it either, especially the project leads,
and they're working hard to get it fixed.
Phil
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: build failure
@ 2000-07-25 17:12 Mike Stump
0 siblings, 0 replies; 21+ messages in thread
From: Mike Stump @ 2000-07-25 17:12 UTC (permalink / raw)
To: gcc, janr, pedwards
> Date: Tue, 25 Jul 2000 15:54:35 -0400
> From: Phil Edwards <pedwards@disaster.jaj.com>
> To: gcc@gcc.gnu.org, janr@molienergy.bc.ca
> Known situation; libstdc++-v3 currently will not build on most platforms.
This isn't a feature. :-(
> (It's in the middle of a big transition.)
Poor excuse.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: build failure
2000-07-25 16:01 ` Gerald Pfeifer
@ 2000-07-25 16:52 ` Gianni Mariani
2000-07-26 13:17 ` Gerald Pfeifer
0 siblings, 1 reply; 21+ messages in thread
From: Gianni Mariani @ 2000-07-25 16:52 UTC (permalink / raw)
To: Gerald Pfeifer; +Cc: Phil Edwards, gcc, janr
Gerald,
I didn't understand what you wrote.
There are patches to apply ? Am I supposed to take these patches ?
Gerald Pfeifer wrote:
> On Tue, 25 Jul 2000, Phil Edwards wrote:
> >> [libstdc++ 3]
> > The library is part of gcc now; if you get CVS sources for gcc, you've
> > got the latest library sources too.
>
> Yes, and no. In a sense libstdc++ 3 is included in GCC, but web-wize
> and when it comes to the patches- and other mailing lists, there is no
> integration yet.
>
> Gerald
> --
> Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
> Have a look at http://petition.eurolinux.org -- it's not about Linux, BTW!
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: build failure
@ 2000-07-25 16:31 Phil Edwards
0 siblings, 0 replies; 21+ messages in thread
From: Phil Edwards @ 2000-07-25 16:31 UTC (permalink / raw)
To: pfeifer; +Cc: gcc, janr
Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>:
> > The library is part of gcc now; if you get CVS sources for gcc, you've
> > got the latest library sources too.
>
> Yes, and no. In a sense libstdc++ 3 is included in GCC, but web-wize
> and when it comes to the patches- and other mailing lists, there is no
> integration yet.
This is true. (I'm very skilled at sidestepping this issue. :-)
I think the mailing list should remain separate, but only because there
may be people on the gcc list that aren't interested in that library,
and vice versa. The lib list isn't /nearly/ as high-volume as gcc's.
Phil
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: build failure
2000-07-25 12:53 Phil Edwards
@ 2000-07-25 16:01 ` Gerald Pfeifer
2000-07-25 16:52 ` Gianni Mariani
0 siblings, 1 reply; 21+ messages in thread
From: Gerald Pfeifer @ 2000-07-25 16:01 UTC (permalink / raw)
To: Phil Edwards; +Cc: gcc, janr
On Tue, 25 Jul 2000, Phil Edwards wrote:
>> [libstdc++ 3]
> The library is part of gcc now; if you get CVS sources for gcc, you've
> got the latest library sources too.
Yes, and no. In a sense libstdc++ 3 is included in GCC, but web-wize
and when it comes to the patches- and other mailing lists, there is no
integration yet.
Gerald
--
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
Have a look at http://petition.eurolinux.org -- it's not about Linux, BTW!
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: build failure
@ 2000-07-25 12:53 Phil Edwards
2000-07-25 16:01 ` Gerald Pfeifer
0 siblings, 1 reply; 21+ messages in thread
From: Phil Edwards @ 2000-07-25 12:53 UTC (permalink / raw)
To: gcc, janr
> CVS checkout (July/21/2000) of the gcc sources fails to build with
> libstdcxx-v3 enabled. The build failure is in libstdc++-v3. Should details
> be reported here or to the libstdc++ mailing?
Known situation; libstdc++-v3 currently will not build on most platforms.
(It's in the middle of a big transition.) You might take a look at the
last few days of the libstdc++ mailing list archive.
In general, problems in building should be reported to either gcc-help or
gcc-bugs, depending on the nature of the problem.
> If not here then is the
> version in CVS gcc checkout in synch with latest libstdc++ CVS sources?
The library is part of gcc now; if you get CVS sources for gcc, you've
got the latest library sources too.
Phil
^ permalink raw reply [flat|nested] 21+ messages in thread
* build failure
@ 2000-07-25 12:22 Jan Reimers
0 siblings, 0 replies; 21+ messages in thread
From: Jan Reimers @ 2000-07-25 12:22 UTC (permalink / raw)
To: gcc (E-mail)
CVS checkout (July/21/2000) of the gcc sources fails to build with
libstdcxx-v3 enabled. The build failure is in libstdc++-v3. Should details
be reported here or to the libstdc++ mailing? If not here then is the
version in CVS gcc checkout in synch with latest libstdc++ CVS sources?
Jan N. Reimers (Ph. D.)
Manager, Materials Research
E-One Moli Energy, BC, Canada
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2001-06-13 4:56 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-07-27 13:01 build failure Phil Edwards
2000-07-27 21:14 ` Marc Espie
2000-07-28 10:15 ` Lee Iverson
2000-07-28 10:32 ` Joern Rennecke
-- strict thread matches above, loose matches on Subject: below --
2001-06-12 12:21 Build failure Jan van Male
2001-06-12 10:30 Jan Kroken
2001-06-12 20:42 ` Alexandre Oliva
2001-06-13 4:56 ` Jan Kroken
2000-07-27 8:36 build failure Phil Edwards
2000-07-27 9:29 ` Gerald Pfeifer
2000-07-26 10:40 Jan Reimers
2000-07-27 19:10 ` Rich Churcher
2000-07-26 10:33 Phil Edwards
2000-07-27 8:11 ` Gianni Mariani
2000-07-25 17:12 Mike Stump
2000-07-25 16:31 Phil Edwards
2000-07-25 12:53 Phil Edwards
2000-07-25 16:01 ` Gerald Pfeifer
2000-07-25 16:52 ` Gianni Mariani
2000-07-26 13:17 ` Gerald Pfeifer
2000-07-25 12:22 Jan Reimers
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).