Updating to the latest binutils - any tips on how to do it easily?
Quoted 4 lines · Jim Wilson
Quoted 1 line
/tmp/ccC11dFe.s:15538: Error: Unknown opcode `data16.ua @ipltYou need a newer binutils if you want to use gcc 3.0.[23] to compile C++ code.
Quoted 8 lines
New IA-64 assembler syntax was introduced last summer, because it was not possible to fully implement the C++ ABI with the original assembler syntax. This new assembler syntax is used starting with gcc 3.0.2, and is not supported by any binutils older that last summer. That unfortunately means that binutils 2.11 is not new enough, you have to use an unreleased binutils from the FSF development source tree.
Jim
Any suggestions on installing a newer binutils? I tried installing a recient version (binutils-2.11.2 or binutils-2.10.1) to /usr/local and had problems with commands compiled with the current compiler, (egcs-2.91.66/(egcs-1.1.2 release)), getting a SEGV when they started; so I backed out the changed binutils installation for now.
Perhaps the compiler and binutils have to be changed together?
The newer binutils seems to be needed for our LKCD lcrash stuff to work corectly for disassembling ia64 code.
-piet
Quoted 5 lines
Any suggestions on installing a newer binutils? I tried installing a recient version (binutils-2.11.2 or binutils-2.10.1) to
/usr/localand had problems with commands compiled with the current compiler, (egcs-2.91.66/(egcs-1.1.2 release)), getting a SEGV when they started; so I backed out the changed binutils installation for now.
There is no IA-64 support in those egcs releases, so you must be talking about something else, like x86. Anyways, regardless of the target, it is never a good idea for the system compiler to use an assembler from /usr/local. If you run the command "gcc --print-file-nameÌ1", then cd to the directory containing cc1, and then create a link called "as" that points to the correct assembler, then that gcc will always use that assembler. You may also need to create a link called "real-ld" that points to the correct linker.
If you install gcc and binutils using the same configure prefix, then that gcc will find that binutils. Putting everything in /usr/local is not necessarily a good idea, since lots of people have /usr/local in their path, and will then run things in /usr/local accidentally. If you use a different prefix for every gcc release you install, you can avoid problems like this. This may be too much trouble for someone who isn't a gcc hacker though.
Quoted 1 line
Perhaps the compiler and binutils have to be changed together?
It is common that a new compiler release requires a new binutils release. Also, it is common that a new gcc requires a new gdb. It is less common, but happens sometimes, that a new gcc requires a new glibc or new kernel because of ABI changes. This is an issue for IA-64 because it is still so new, and compiler work was really finished until last year when 3.0.2 came out. There should be no more major ABI changes after gcc 3.0.2 though.
Jim