Re: build failure

Re: build failure

[Phil Edwards]

> > 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

Re: build failure

[Marc Espie]

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)

Re: build failure

[Lee Iverson]

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

Re: build failure

[Joern Rennecke]

> (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.

Re: Build failure

[Jan Kroken]

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

Re: Build failure

[Alexandre Oliva]

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

re: Build failure

[Jan van Male]

>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

Build failure

[Jan Kroken]

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

Re: build failure

[Rich Churcher]

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.  

Re: build failure

[Gerald Pfeifer]

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!

Re: build failure

[Phil Edwards]

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

Re: build failure

[Gianni Mariani]

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

Re: build failure

[Gerald Pfeifer]

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/

RE: build failure

[Jan Reimers]

> -----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

Re: build failure

[Phil Edwards]

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

Re: build failure

[Mike Stump]

> 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.

Re: build failure

[Gianni Mariani]

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!

Re: build failure

[Phil Edwards]

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

Re: build failure

[Gerald Pfeifer]

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!

Re: build failure

[Phil Edwards]

> 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

build failure

[Jan Reimers]

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