------- 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
