Re: collect2 bug in 3.3.2 on Tru64 UNIX 5.1

[Jim Wilson <wilson at specifixinc dot com>]

Albert Chin wrote:
> $ g++ -v -Wl,-v -shared -Wl,-expect_unresolved,'*' \
> -Wl,-soname,libsip.so -o libsip.so moc_sipQt.o ...

You can work around this problem by putting the -soname option near the 
end of the gcc command line.  If there is at least one .o file name 
before the -soname option, then you won't see this problem.

You might be able to work around the problem by installing GNU ld (in 
the binutils package) and configuring --with-gnu-ld --with-gnu-as.  In 
that case, GNU ld should create the constructors, and collect2 won't 
need the second problematic link, and hence I would expect the above 
command to work.

Incidentally, I see that libtool always puts the -soname option near the 
end of the command line, but I don't know if this is done on purpose or 
by accident.

This problem won't occur for any ELF target, because we always link in 
at least one standard object file (e.g. crti.o, crtbeginS.o) when 
creating shared libraries, so the -soname argument can not be the first 
file name.

> I believe this is the culprit. How should I try to fix this? Should I
> check if p == '.so' and *(ld2-2) == '-soname'? Or maybe add o_file to
> *ld2++ when p == '.so' just like when p == '.o' || p == '.obj'?

It looks like o_file is deliberately inserted before any library, which 
makes sense, as we don't want a library file to accidentally override 
any of it.  Note that the same treatment is given to -l options.  So 
putting o_file after a .so does not appear safe.

That leaves us with the option of checking for the -soname option which 
is a bit of a hack, but I don't see any better alternative at the 
moment.  The problem here is that we need a solution that works for all 
targets, but not all targets have a "-soname" linker option.  So there 
is some risk that an explicit check for -soname may fail in some unusual 
cases.  Checking libtool, I see that the -soname option name seems to be 
pretty standard, so this seems reasonably safe.  I see only one system 
that has a --soname option, and I don't see any other names for this option.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com