This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Bug other/33357] collect2: ld terminated with signal 11 [Segmentation fault]


Hi Don,

Thank you both for your replies.  I have now built binutils 2.18.
However I'm not root on this machine and so cannot install it in the
place where the original command (g++ -O3 -DDBUG_OFF ...) will find
it.  Can either of you tell me how to arrange for the g++ command to
use the version of ld I've just built?

There are several possibilities:


1. Build your own local version of g++ as well and install everything in your own local install tree. This might be a good idea if you have other bugs in the compiler or linker that you might want to track down.

2. Compile everything to object files first. Then perform a final link adding "-v" to the gcc command line. This will show you the linker command line that gcc is using. Copy this command line, replacing the name of the linker program with the path to your own, newly built linker.

The problem with this approach is that you are using g++. (If you are not compiling C++ sources then switch to gcc and you will not encounter the following problem). The problem is that g++ does not invoke the linker directly. Instead it uses an intermediary program called collect2 which performs some additional work before invoking the linker. This could still be worked around if it were not for the fact that g++ communicates some critical information to collect2 via environment variables rather than the command line. These variables are not shown in the "g++ -v" output and they include the path to the linker that collect2 invokes. [A big design bug imho]. Try adding "--Wl,-debug" to the g++ command line to see some output from collect2.

The simplest way around this problem is to still use g++ to perform the final link, but to rename your newly built linker executable to "real-ld" and put it in your PATH somewhere. (I normally use the current directory where I am running my tests). Collect2 should look for an executable called "real-ld" first and if it cannot find one, then use "collect-ld" or "ld" or something else which will probably be in the path given to it by the compiler, and not in a path controllable by you.

I see at least two problems here.  First, g++ is not simply calling ld
on the same arguments - when I replace g++ with ld I get an error
about unrecognized option -DDBUG_OFF.

Second, I suspect that the ld I just built is the file
~/binutils-2.18/ld/ld-new - is that correct?

Correct. When the built ld-new executable is installed it is renamed to ld.


Cheers
  Nick



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]