[Bug other/28377] unresolved symbols in libstdc++, shared lib link strategy of libgcc.a

["marek dot rouchal at infineon dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #2 from marek dot rouchal at infineon dot com  2006-07-14 09:08 -------
The test case is the build of gcc 4.0.3 on Solaris 8, including the
libstdc++.so build. When done, run

env LD_LIBRARY_PATH=<path-where-libgcc_s.so-is> ldd -r -v .../libstdc++-IFX.so

and you will see __eprintf unresolved.

I will try to put together a test case to build a shared lib from C source code
that contains #include <assert.h> and some assertion to demonstrate the the
resulting libXXX.so has an unresolved reference to __eprintf.


One more comment: The libstdc++ on Solaris does not have the RUNPATH compiled
in to find the libgcc_s.so, so that is why the _umoddi etc. symbols are not
found. So when running 
env LD_LIBRARY_PATH=/opt/gcc_4.0.3/solaris8/lib ldd -r -v
/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so
I only get the __eprintf unresolved symbol. So the difference between Solaris
and Linux is really that on Solaris there is __eprintf unresolved in
libstdc++.so.
And I noticed another difference: On Solaris, my gcc is using the Solaris ld
linker, and the collect2 call contains (gcc -shared) only -lgcc_s,
whereas on Linux (where GNU ld is used) it contains:
-lgcc --as-needed -lgcc_s-IFX --no-as-needed -lc -lgcc --as-needed -lgcc_s-IFX
--no-as-needed
so link first with the static libgcc.a, then with the shared gcc_s.

I failed to figure out where and how the link lib list is constructed within
gcc (i.e., how the collect2 command line is put together), so I do not know how
to compare that between Solaris and Linux.

-Marek


-- 


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