[Bug other/33357] collect2: ld terminated with signal 11 [Segmentation fault]
--- Comment #6 from jsm28 at gcc dot gnu dot org 2010-05-22 17:33 --- As discussed, not a GCC bug. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33357
[Bug other/33357] collect2: ld terminated with signal 11 [Segmentation fault]
--- Comment #5 from don-gcc at isis dot cs3-inc dot com 2007-09-17 16:31
---
Subject: Re: collect2: ld terminated with signal 11 [Segmentation fault]
Nick Clifton writes:
> There are several possibilities:
...
I ended up following the recommendation below - worked fine.
I installed the binutils build into my own directory and then added
the -B. In fact I just added that to the input I passed to .configure
and the entire mysql build completed without problem.
--- Comment #3 from schwab at suse dot de 2007-09-09 08:09 ---
Use -B${binutils-bindir}, where ${binutils-bindir} is the directory where the
binutils binaries were installed. `-BPREFIX' This option specifies where
to find the executables, libraries, include files, and data files of the
compiler itself. The compiler driver program runs one or more of the
subprograms `cpp', `cc1', `as' and `ld'. It tries PREFIX as a prefix for
each program it tries to run, both with and without `MACHINE/VERSION/'
(*note Target Options::).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33357
[Bug other/33357] collect2: ld terminated with signal 11 [Segmentation fault]
--- 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
[Bug other/33357] collect2: ld terminated with signal 11 [Segmentation fault]
--- Comment #3 from schwab at suse dot de 2007-09-09 08:09 ---
Use -B${binutils-bindir}, where ${binutils-bindir} is the directory where the
binutils binaries were installed. `-BPREFIX' This option specifies where
to find the executables, libraries, include files, and data files of the
compiler itself. The compiler driver program runs one or more of the
subprograms `cpp', `cc1', `as' and `ld'. It tries PREFIX as a prefix for
each program it tries to run, both with and without `MACHINE/VERSION/'
(*note Target Options::).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33357
[Bug other/33357] collect2: ld terminated with signal 11 [Segmentation fault]
--- Comment #2 from don-gcc at isis dot cs3-inc dot com 2007-09-09 03:43 --- Subject: collect2: ld terminated with signal 11 [Segmentation fault] pinskia at gcc dot gnu dot org writes: > This is ld crashing and ld is part of the binutils project. Mike Frysinger writes: > you should start with what version of binutils you're actually using ... run > `ld --version` > if that version != 2.18, then you should first upgrade 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? 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? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33357
[Bug other/33357] collect2: ld terminated with signal 11 [Segmentation fault]
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-08 19:29 --- This is ld crashing and ld is part of the binutils project. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33357
