• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 683
  • Last Modified:

Problems building gcc-3.4.3 on x86_64 (64-bit AMD) Linux

Greetings.

I need to build a gcc-3.4.3 package that will run on an AMD Athlon 64-bit Linux box, and will generate 64-bit executables.  For reference, the gnu platform triple generated by "configure" for this machine is "x86_64-unknown-linux-gnu".  The problem I'm having is that the build process dies with "architecture incompatible" warnings, like this:

-----
stage1/xgcc -Bstage1/ -B/proj/ppctools/scratch2/_TOOLS_/dist/gnu-gcc-3.4.3-binutils-2.15/x86_64-pc-linux2.4/x86_64-unknown-linux-gnu/bin/ -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wold-style-definition     -DHAVE_CONFIG_H -DGENERATOR_FILE    -I. -I. -I/temp/gccbuild/gcc-3.4.3/gcc -I/temp/gccbuild/gcc-3.4.3/gcc/. -I/temp/gccbuild/gcc-3.4.3/gcc/../include  /temp/gccbuild/gcc-3.4.3/gcc/errors.c -o errors.o
stage1/xgcc -Bstage1/ -B/proj/ppctools/scratch2/_TOOLS_/dist/gnu-gcc-3.4.3-binutils-2.15/x86_64-pc-linux2.4/x86_64-unknown-linux-gnu/bin/   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wold-style-definition     -DHAVE_CONFIG_H -DGENERATOR_FILE  -o genmodes \
 genmodes.o errors.o ../libiberty/libiberty.a
/proj/ppctools/scratch2/_TOOLS_/dist/gnu-gcc-3.4.3-binutils-2.15/x86_64-pc-linux2.4/bin/ld: warning: i386 architecture of input file `../libiberty/libiberty.a(hashtab.o)' is incompatible with i386:x86-64 output
/proj/ppctools/scratch2/_TOOLS_/dist/gnu-gcc-3.4.3-binutils-2.15/x86_64-pc-linux2.4/bin/ld: warning: i386 architecture of input file `../libiberty/libiberty.a(xmalloc.o)' is incompatible with i386:x86-64 output
/proj/ppctools/scratch2/_TOOLS_/dist/gnu-gcc-3.4.3-binutils-2.15/x86_64-pc-linux2.4/bin/ld: warning: i386 architecture of input file `../libiberty/libiberty.a(xstrdup.o)' is incompatible with i386:x86-64 output
/proj/ppctools/scratch2/_TOOLS_/dist/gnu-gcc-3.4.3-binutils-2.15/x86_64-pc-linux2.4/bin/ld: warning: i386 architecture of input file `../libiberty/libiberty.a(xexit.o)' is incompatible with i386:x86-64 output
./genmodes -h > tmp-modes.h
Memory fault
make[2]: *** [s-modes] Error 139
make[2]: Leaving directory `/temp/gccbuild/gcc-3.4.3/_build/gcc'
make[1]: *** [stage2_build] Error 2
make[1]: Leaving directory `/temp/gccbuild/gcc-3.4.3/_build/gcc'
make: *** [bootstrap] Error 2
-----

I need some expert help getting this booger to build successfully!  Help!!  :o)

Some additional info:
* I am not "root", nor can I become "root".  I'm working in a corporate network environment that has been very oddly configured, and in order to install and use this compiler across the network, I *must* build it from scratch and install it in a very weird location.  So, sadly, I cannot use a pre-built binary package--not even as a bootstrap compiler.
* For a bootstrap compiler on this Athlon machine, I'm using a gcc-2.95.2 package I built for 32-bit Linux (I built this gcc-2.95.2 package for this bizzarre environment in much the same way I'm trying to build this new one.)  I have several other versions of gcc built and installed for 32-bit Linux at my disposal, should 2.95.2 turn out to be a poor choice for bootstrapping...
* I have a script that I use to do the build process-- I can post a simplified version of that script if it would be helpful.

Chris
0
tauchris
Asked:
tauchris
  • 11
  • 8
1 Solution
 
_corey_Commented:
How are you configuring binutils and gcc?

0
 
tauchrisAuthor Commented:
Hi!  I'll post the configuration shortly.  Sorry I couldn't attend to that right away.
0
 
tauchrisAuthor Commented:
Sorry -- lots of network problems today!  (Storms in central texas...)

Here's the essentials of my build script.  Note that I changed from using gcc-2.95.2 as a bootstrap compiler to using gcc-3.2.2.  The result is basically the same, but I no longer get the "Memory fault".  Also, I now get a more specific failure: ld gives an internal error with a line number.

(INSTALL_PREFIX is the goofy-bizzarro location where our corporate standards force me to install the compiler.  This always starts out as an empty directory.)

Binutils is built like this (paraphrased):
> ROOT=`pwd`
> tar xvzf binutils-2.15.tgz
> cd binutils-2.15
> ./configure --prefix=${INSTALL_PREFIX} --disable-nls --enable-64-bit-bfd
> make && make install
> cd ${ROOT}

GCC is then built like this:
> #Using gcc-3.2.2 as bootstrap compiler, so set PATH to find gcc-3.2.2 first
> tar xvzf gcc-3.4.3.tgz
> cd gcc-3.4.3
> mkdir _build; cd _build
> ${ROOT}/gcc-3.4.3/configure --prefix=${INSTALL_PREFIX}  --enable-threads --enable-shared --with-ld=${INSTALL_PREFIX}/bin/ld --with-as=${INSTALL_PREFIX}/bin/as --with-nm=${INSTALL_PREFIX}/bin/nm --enable-languages=c,c++ --disable-nls
> make CFLAGS='-g -O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap
> make install

Then GCC-3.4.3 is rebuilt with exactly the same flags, but using the gcc-3.4.3 that was just finished in the previous step as the bootstrap compiler.

----

The build process fails in the same place--during the first build of GCC, at the "make bootstrap" step.  The results are:

stage1/xgcc -Bstage1/ -B/proj/ppctools/scratch2/_TOOLS_/dist/gnu-gcc-3.4.3-binutils-2.15/x86_64-pc-linux2.4/x86_64-unknown-linux-gnu/bin/   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wold-style-definition     -DHAVE_CONFIG_H -DGENERATOR_FILE  -o genmodes \
 genmodes.o errors.o ../libiberty/libiberty.a
/proj/ppctools/scratch2/_TOOLS_/dist/gnu-gcc-3.4.3-binutils-2.15/x86_64-pc-linux2.4/bin/ld: warning: i386 architecture of input file `../libiberty/libiberty.a(hashtab.o)' is incompatible
with i386:x86-64 output
/proj/ppctools/scratch2/_TOOLS_/dist/gnu-gcc-3.4.3-binutils-2.15/x86_64-pc-linux2.4/bin/ld: warning: i386 architecture of input file `../libiberty/libiberty.a(xmalloc.o)' is incompatible
with i386:x86-64 output
/proj/ppctools/scratch2/_TOOLS_/dist/gnu-gcc-3.4.3-binutils-2.15/x86_64-pc-linux2.4/bin/ld: warning: i386 architecture of input file `../libiberty/libiberty.a(xstrdup.o)' is incompatible
with i386:x86-64 output
/proj/ppctools/scratch2/_TOOLS_/dist/gnu-gcc-3.4.3-binutils-2.15/x86_64-pc-linux2.4/bin/ld: warning: i386 architecture of input file `../libiberty/libiberty.a(xexit.o)' is incompatible with i386:x86-64 output
/proj/ppctools/scratch2/_TOOLS_/dist/gnu-gcc-3.4.3-binutils-2.15/x86_64-pc-linux2.4/bin/ld: BFD 2.15 internal error, aborting at reloc.c line 4274 in bfd_generic_get_relocated_section_contents
 
/proj/ppctools/scratch2/_TOOLS_/dist/gnu-gcc-3.4.3-binutils-2.15/x86_64-pc-linux2.4/bin/ld: Please report this bug.
 
collect2: ld returned 1 exit status
make[2]: *** [genmodes] Error 1
make[2]: Leaving directory `/proj/.ppc_38/da/cham/ppcinfr/gcc-3.4.3/ld0022-tx32/gcc-3.4.3/_build/gcc'
make[1]: *** [stage2_build] Error 2
make[1]: Leaving directory `/proj/.ppc_38/da/cham/ppcinfr/gcc-3.4.3/ld0022-tx32/gcc-3.4.3/_build/gcc'
make: *** [bootstrap] Error 2
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
_corey_Commented:
Well tauchris,

  If you're building for the system you're using, then the scripts *seem* ok.  I thought perhaps it was a bug to report, but then I found this:

https://bugzilla.redhat.com/beta/show_bug.cgi?id=139476

  Did you install all the proper development libraries, specifically the one noted in the response?  The ld exit status is much more acceptible than a crash and gcc 3 is  definately a better idea for your bootstrap.

corey
0
 
tauchrisAuthor Commented:
I had seen that bug report, too.  I  wasn't really sure whether it might apply to my situation, since that bug has to do with a failure in a pre-built compiler for the x86_64 platform, rather than with bootstrapping a new compiler.  I still have some questions about whether the compiler I'm using to bootstrap my gcc-3.4.3 build should even be expected to *run* on this platform, since it was originally built for a 32-bit linux platform...

Anyway, the direct answer to your question is "no"-- I have not installed those libs.  Since I'm not root, that's gonna take some fanagling.  Do you know how I can determine whether those development libs are installed (without being root)?  Might save a lot of coordination...

I'll start pursuing that first thing in the morning.
0
 
tauchrisAuthor Commented:
Okay -- turns out I *do* have that package installed.  Cut-n-paste from my terminal window:

[GAIN x86_64-pc-linux2.4.21-glibc2.3.2 (ld0022-tx32)]$ rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' gcc glibc glibc-headers glibc-devel cpp gcc-c++
gcc-3.2.3-42.x86_64
glibc-2.3.2-95.27.i686
glibc-2.3.2-95.27.x86_64
glibc-headers-2.3.2-95.27.x86_64
glibc-devel-2.3.2-95.27.i386
glibc-devel-2.3.2-95.27.x86_64
cpp-3.2.3-42.x86_64
gcc-c++-3.2.3-42.x86_64
[GAIN x86_64-pc-linux2.4.21-glibc2.3.2 (ld0022-tx32)]$

Not sure what to try next.  I read in the installation notes that the bootstrap compiler must be "link-compatible" with the compiler I'm trying to build.  I'm not sure exactly what that implies.   I was able to build gcc-3.4.3 on my *32-bit* linux platform, so I just reran my build script on the 64-bit Athlon machine, using the gcc-3.4.3 I just built as a bootstrap.   I figured gcc-3.4.3 must be "link-compatible" with itself.   But, that build attempt failed in the same place.  With this attempt, I'm back to getting "Memory fault" just after the "incompatible architecture" complaints.  Do you think "link-compatible" means something more along the lines of "hardware-compatible"?   (If that's the case, my next option would be to try to convince the rootly powers to reinstall the pre-built compiler back in /usr/local/bin--just long enough for me to try using it as the bootstrap...  What do you think?)
0
 
tauchrisAuthor Commented:
Oh-- I just realized that the rpm output I just posted shows I have gcc-3.2.3 installed in /usr/bin!   That just **HAS** to be link-compatible.  I'll rerun my script with that gcc as the bootstrap and see if I can get past the problem.
0
 
_corey_Commented:
Are you building on a 64-bit machine?

corey
0
 
tauchrisAuthor Commented:
<frustrated sigh>

My build attempt using the pre-installed gcc-3.2.3 as the bootstrap compiler failed, too.  It got MUCH further, and this time, it failed without the "incompatible architecture" message.  This time, I just got the memory fault!

Last bit of output:...

/_TOOLS_/arch/ibin/ksh ../libtool --tag CXX --mode=link /home/cham/workspace/ppcinfr/gcc-3.4.3/ld0022-tx32/gcc-3.4.3/_build/gcc/xgcc -shared-libgcc -B/home/cham/workspace/ppcinfr/gcc-3.4.3/ld0022-tx32/gcc-3.4.3/_build/gcc/ -nostdinc++ -L/home/cham/workspace/ppcinfr/gcc-3.4.3/ld0022-tx32/gcc-3.4.3/_build/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/home/cham/workspace/ppcinfr/gcc-3.4.3/ld0022-tx32/gcc-3.4.3/_build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/proj/ppctools/scratch2/_TOOLS_/dist/gnu-gcc-3.4.3-binutils-2.15/x86_64-pc-linux2.4/x86_64-unknown-linux-gnu/bin/ -B/proj/ppctools/scratch2/_TOOLS_/dist/gnu-gcc-3.4.3-binutils-2.15/x86_64-pc-linux2.4/x86_64-unknown-linux-gnu/lib/ -isystem /proj/ppctools/scratch2/_TOOLS_/dist/gnu-gcc-3.4.3-binutils-2.15/x86_64-pc-linux2.4/x86_64-unknown-linux-gnu/include -isystem /proj/ppctools/scratch2/_TOOLS_/dist/gnu-gcc-3.4.3-binutils-2.15/x86_64-pc-linux2.4/x86_64-unknown-linux-gnu/sys-include -Wl,-O1   -fno-implicit-templates -Wall -W -Wwrite-strings -Wcast-qual  -fdiagnostics-show-location=once  -ffunction-sections -fdata-sections   -o libstdc++.la -rpath /proj/ppctools/scratch2/_TOOLS_/dist/gnu-gcc-3.4.3-binutils-2.15/x86_64-pc-linux2.4/lib/../lib64 -version-info 6:3:0 -Wl,--version-script=libstdc++-symbol.ver -lm  allocator.lo codecvt.lo complex_io.lo ctype.lo debug.lo debug_list.lo functexcept.lo globals_locale.lo globals_io.lo ios.lo ios_failure.lo ios_init.lo ios_locale.lo limits.lo list.lo locale.lo locale_init.lo locale_facets.lo localename.lo stdexcept.lo strstream.lo tree.lo allocator-inst.lo concept-inst.lo fstream-inst.lo ext-inst.lo io-inst.lo istream-inst.lo locale-inst.lo locale-misc-inst.lo misc-inst.lo ostream-inst.lo sstream-inst.lo streambuf-inst.lo string-inst.lo valarray-inst.lo wlocale-inst.lo wstring-inst.lo atomicity.lo codecvt_members.lo collate_members.lo ctype_members.lo messages_members.lo monetary_members.lo numeric_members.lo time_members.lo basic_file.lo c++locale.lo ../libmath/libmath.la ../libsupc++/libsupc++convenience.la -lm
Memory fault
make[4]: *** [libstdc++.la] Error 139
make[4]: Leaving directory `/proj/.ppc_38/da/cham/ppcinfr/gcc-3.4.3/ld0022-tx32/gcc-3.4.3/_build/x86_64-unknown-linux-gnu/libstdc++-v3/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/proj/.ppc_38/da/cham/ppcinfr/gcc-3.4.3/ld0022-tx32/gcc-3.4.3/_build/x86_64-unknown-linux-gnu/libstdc++-v3'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/proj/.ppc_38/da/cham/ppcinfr/gcc-3.4.3/ld0022-tx32/gcc-3.4.3/_build/x86_64-unknown-linux-gnu/libstdc++-v3'
make[1]: *** [all-target-libstdc++-v3] Error 2
make[1]: Leaving directory `/proj/.ppc_38/da/cham/ppcinfr/gcc-3.4.3/ld0022-tx32/gcc-3.4.3/_build'
make: *** [bootstrap] Error 2


I'm stumped.   What should I look at next?
0
 
_corey_Commented:
I'm going to suggest you post to the gcc-help list specifically.

http://gcc.gnu.org/lists.html 

You don't have to join this list as most reply-all and include your email address but it's better.

You'll get a much more complete answer there.

corey
0
 
tauchrisAuthor Commented:
Corey-- thanks for the suggestions.  I actually already posted this question to the gcc-help list.   There's been no response at all.   Maybe what I need is advice on how to ask a better question....  <sigh>

0
 
_corey_Commented:
Post the machine you are building with right now (32-bit, 64-bit, gcc version).

Post the machine you want to cross-compile to and what you want on that compiler.  (host, target, etc).

Then list the step you were on as you did here.  It crashes compiling the cross-compile with both a fresh-compiled bootstrap and a compiler on the build machine .

Ask them what configurations are neccessary for this build machine to compile a cross-compiler for your target/host.

corey
0
 
tauchrisAuthor Commented:
Thanks, Corey.  I've posted another plea for help--hopefully better-focused than the first.

Just to be clear--- this is not a cross-compiler I'm trying to build.  If I said something earlier that confused the issue, I'm sorry.
0
 
_corey_Commented:
No, I understand that now.  Some of the issues made me start saying that but I assumed from the beginning that you were building for the host/build machine you were on.  

I haven't seen the question post yet, so we'll see what happens.

corey
0
 
tauchrisAuthor Commented:
Problem turned out to be an issue with a shell behavior caused by the whacko network configuration we're stuck with here.  Ultimately, my build script worked, but to get around the shell problem, I had to run the script, let it fail, edit the script to skip around all the steps that had completed successfully and restart the script so that it would reattempt the failed step.  Everything completely flawlessly after that.

Thanks corey, for suggesting gcc-help.  The advice we got there (look for physical memory defects, examine the shell behavior) is what led me to the solution.  

So, I suppose it's appropriate to award you the points, right?
0
 
_corey_Commented:
It's up to you of course.

I did nudge him to re-look at your post :)

corey
0
 
tauchrisAuthor Commented:
Well, you are the only expert that even tried to help me, so you should definitely get the points.  I don't want to be insulting, but since this is my first question posted on EE, I'm not entirely sure of the customs here.  Would you say this is a "B"-grade answer or an "A"?

Chris
0
 
_corey_Commented:
Well, as there was nothing I could find wrong with your configuration....there was really nothing I could fix specifically other than point you to a better list.

B won't hurt my feelings if you're disappointed that I didn't point out a specific shell configuration issue.

corey
0
 
tauchrisAuthor Commented:
Okay.   And thanks again!
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 11
  • 8
Tackle projects and never again get stuck behind a technical roadblock.
Join Now