top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

trouble building gcc 4.7.2 w/binutils 2.23.1

+1 vote
502 views

I'm trying to build GCC 4.7.2 with binutils 2.23.1 and am getting a compile error:

dwarf.o: In function get_TAG_name': /w/umoszkow/gcc/x86_64/binutils/../../gcc-4.7.2/binutils/dwarf.c:662: undefined reference toget_DW_TAG_name'
dwarf.o: In function get_FORM_name': /w/umoszkow/gcc/x86_64/binutils/../../gcc-4.7.2/binutils/dwarf.c:678: undefined reference toget_DW_FORM_name' dwarf.o: In function get_AT_name': /w/umoszkow/gcc/x86_64/binutils/../../gcc-4.7.2/binutils/dwarf.c:1867: undefined reference toget_DW_AT_name'
collect2: error: ld returned 1 exit status

Any idea how to get around this build problem? My arch is x86_64 and my OS is RHEL4u8WS.

posted Jun 12, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote

Where you found that the gcc-4.7.2 and binutils-2.23.1 sources are in sync so that they can be combined and be built together?

A quick googling with this subject told in :

http://stackoverflow.com/questions/1726042/recipe-for-compiling-binutils-gcc-together

the following :

"Doing this with gcc 4.7.2, with binutils-2.22 and contrib/download_prerequisites for gmp, mpc,mpfr; recipe works, but gcc fails to build with -flto, resulting in:
collect2: fatal error: cannot find 'ld'. To rectify that, make a symbolic link ld -> ld-new in your ...prefix/bin directory."

I don't know what the "contrib/download_prerequisites" says about the binutils version for gcc-4.7.2 if even anything but a simple sanity check with the release dates of the 1st src releases :

gcc-4.7.0 - 22.3.2012
binutils-2.23 - 22.10.2012

tells that the latter wasn't available when the former was released!

answer Jun 13, 2013 by anonymous
Similar Questions
+2 votes
PIC 4.7 & 4.8 gcc libraries for arm

I would like to build position-independent 4.7 and 4.8 gcc libraries for host: mac target: arm-none-eabi.

Do anyone has instructions for achieving this?

0 votes
Trouble building AR

I'm having trouble building GCC. I've decompressed GCC 4.7.2 source into a directory and binutils 2.21.1 into a directory in parallel with symbolic links to all subdirectories. I ran the contrib script to get all other dependencies and then ran GCC's configure in a parallel directory, following all installation instructions. It builds just fine but when I install it AR seems to be missing. Any idea what happened to it and how to get it?

Looks like it's supposed to be built with binutils and I'm getting other tools from it like LD just not that one. There is a program called gcc-ar that seems to exist but not sure if it's the same tool? It may appear if I build binutils by itself but I'm trying to build them together so that I can get -flto optimization to work, as apparently GCC balks at using the linker plugin if they weren't built together.

+1 vote
Building GCC on Ubuntu Failing?

My system is ubuntu 14.04 LTS 64 bit and I've installed build-essential. Also tried purge and reinstall libc6-dev. Doesn't work.

from /home/xxx/gcc-4.8.2-build/../gcc-4.8.2/libgcc/libgcov.c:27:
/usr/include/features.h:374:25: fatal error: sys/cdefs.h: No such file or directory

+2 votes
gcc v4.7 build errors on Android Jellybean

we are trying to compile Android Jellybean (JB43) and It uses Toolchain GCC 4.7 with this toolchain we are seeing this error:

Error: selected processor does not support requested special purpose register -- `mrs r5,FPEXC

Is there a way to fix this. I use arm v7-a

+1 vote
gcc 4.8++ neglect my terminfo

With the apparition of colorification of gcc diag message, it sounds like the color are hard coded to who knows terminals.

I Know that I can use option/env to remove color, yet when non prepared for it, it crash my terminal ( that is not vt100 or whatever xterm is).

My TERM var is properly setup up though. Is that expected behavior?

I know that colorisation is a rampant disease with ls, grep etc, with default color barely readable imposing painful customization time at moment you would like to spend your time to other duties :)

Would'nt be possible to have color only if some ENV are already set, i.e gcc could detect in the env that the user is a *COLOR* officionado and colorify then, instead of imposing regression in both terminal non xterm, and regression on diag parser that discover with horror this new escape sequence in the output :)

...