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

["nickc at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #4 from nickc at redhat dot com  2007-09-17 12:08 -------
Subject: Re:  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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33357