[Bug other/5762] collect2 passes o_file too soon if -soname option is passed early.

tilps@hotmail.com gcc-bugzilla@gcc.gnu.org
Sun May 25 04:52:00 GMT 2003


PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


tilps@hotmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|3.0                         |3.4


------- Additional Comments From tilps@hotmail.com  2003-05-25 04:38 -------
On the machine i used to report this - I now use gcc 3.4 CVS - I still use the
same patch, but I am no longer attempting to compile mozilla with gcc on this
platform.

However, I see no reason for why my patch is no longer needed, despite not
having a test case around to check anymore.

To clarify, if collect2 creates a temporary object for the purposes of
constructors etc - and -soname option is specified on the link line before other
objects - then things will break.
This is because the name after -soname generally ends in .so - and will be
recognised as an object. Also, because first_file will be set until an object is
actually found - the o_file will be inserted into the argument list before the
name associated with -soname.  Therefore ld will think the temporary object file
is the soname - and the soname is an object file needing to be linked.  Ld will
fail to find this object and die.
Basically, unpatched - collect2 knows nothing about -soname options and
correspondingly how to deal with -soname's argument.  My patch simply makes it
auto add the next entry, so as to ensure that the argument is passed togeather
with the -soname option.

If i understood the mechanisms which cause collect2 to create a temporary object
- then creating a testcase should be simple.  However i dont, and dont have time
to right now.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.



More information about the Gcc-bugs mailing list