Ian Lance Taylor wrote: > "Kevin P. Fleming" <kpfleming@xxxxxxxxxx> writes: > >> I can build gcc-4.4.2 (with latest gmp and mpfr) in combined build tree >> mode without a problem; adding binutils-2.20 to the build tree results >> in the following build failure in gcc: >> >>> gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../combined/gcc -I../../combined/gcc/build -I../../combined/gcc/../include -I../../combined/gcc/../libcpp/include -I/root/work/build/./gmp -I/root/work/combined/gmp -I/root/work/build/./mpfr -I/root/work/combined/mpfr -I../../combined/gcc/../libdecnumber -I../../combined/gcc/../libdecnumber/bid -I../libdecnumber -o build/gengtype-parse.o ../../combined/gcc/gengtype-parse.c >>> gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/gengtype \ >>> build/gengtype.o build/gengtype-lex.o build/gengtype-parse.o build/errors.o ../build-i686-pc-linux-gnu/libiberty/libiberty.a >>> /bin/sh ../../combined/gcc/../move-if-change tmp-gi.list gtyp-input.list >>> echo timestamp > s-gtyp-input >>> build/gengtype ../../combined/gcc gtyp-input.list >>> ../../combined/gcc/../include/hashtab.h:111: stray GTY marker >>> ../../combined/gcc/../include/hashtab.h:135: stray GTY marker > > It looks like you've overridden gcc's copy of the include directory > with binutils's copy. Don't do that. The instructions on gcc.gnu.org say to unpack the binutils distribution in the same directory as the gcc distribution. This is what I've been doing: $ mkdir combined $ cd combined $ tar xjvf ../gcc-4.4.2.tar.bz2 --strip-components=1 $ tar xjvf ../binutils-2.20.tar.bz2 --strip-components=1 If I save away a copy of the 'include' directory before unpacking binutils, and compare it after unpacking binutils, there are many differences. So, I tried creating a directory called binutils *inside* combined, and unpacking the binutils distribution there instead. The top-level configure script then reports 'just compiled' for all the gcc tools and binutils tools *except* 'as' and 'ld', which are clearly there (as binutils/gas and binutils/ld). Since my primary reason for doing a combined build was to make sure I'd have versions of gas and ld that are as up to date as possible, this doesn't seem like it will serve my purpose. Thanks for your help; it appears that what I'm trying to do isn't commonly done, at least based on the ages of most of the hits that Google returns :-) -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpfleming@xxxxxxxxxx Check us out at www.digium.com & www.asterisk.org
