These are two related problems. The most obvious one is that when building
libstdc++.so (don't mind the renaming, I want to isolate our gcc installation
from other tools that have their own libstdc++.so and set LD_LIBRARY_PATH,
because they are too stupid to use -rpath in their software) and I run
ldd -r -v .../libstdc++.so I get these unresolved symbols:
symbol not found: _Unwind_Resume (/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: __ctzsi2 (/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: __eprintf (/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: __umoddi3 (/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: __udivdi3 (/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: _Unwind_DeleteException
(/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: _Unwind_GetTextRelBase
(/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: _Unwind_GetRegionStart
(/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: _Unwind_GetDataRelBase
(/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: _Unwind_SetGR (/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: _Unwind_SetIP (/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found:
_Unwind_GetLanguageSpecificData(/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: _Unwind_GetIP (/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: _Unwind_RaiseException
(/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
symbol not found: _Unwind_Resume_or_Rethrow
(/opt/gcc_4.0.3/solaris8/lib/libstdc++-IFX.so)
These symbols are obviously not part of libgcc_s.so, but some of them can be
found in:
nm /opt/gcc_4.0.3/solaris8/lib/gcc/sparc-sun-solaris2.8/4.0.3/libgcc.a | ggrep
-E '_Unwind_|__ctzsi2|__eprintf|__umoddi3|__udivdi3'
[12] | 8| 228|FUNC |GLOB |0 |5 |__ctzsi2
[14] | 8| 72|FUNC |GLOB |0 |5 |__eprintf
[13] | 8| 916|FUNC |GLOB |0 |5 |__udivdi3
[13] | 8| 948|FUNC |GLOB |0 |5 |__umoddi3
and the _Unwind in libsupc++.a. So far it is clear - but is this allowed? When
I build a C++ executable, which is linked against -lstdc++, how is this
executable supposed to find the missing symbols? My belief is up to now that a
shared object can only have unresolved symbols agaist other shared libs (which
it depends on) - but not against static ones.
The other (but related) problem is this: when I compile source code with
assert.h, I requently get errors at runtime that __eprintf is not found. This
does not happen when the executable is linked with gcc, since this passes
"-lgcc_s -lgcc" to the linker. But when building shared libraries (gcc
-shared), then only -lgcc_s is supplied (see the "specs" file:
%{static|static-libgcc:-lgcc
-lgcc_eh}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc
-lgcc_eh}%{shared-libgcc:-lgcc_s-IFX -lgcc}}%{shared:-lgcc_s-IFX}}}
) and the shared lib has unresolved dependencies on __eprintf. So basically
this could be the root cause of the libstdc++ trouble above - wouldn't it be
correct to link shared libs with "-lgcc_s -lgcc" as well, to avoid that the
shared object will have the unresolved dependency on __eprintf?
I looked at Bug 15253 and Bug 15527, but that did not seem to give an answer to
the questions above.
On Linux (RedHat Enterprise Linux 3.0) this looks totally different: All the
symbols above (__ctzsi2 __udivdi3 __umoddi3) are in libgcc_s.so, __eprintf is
in libgcc.a, and the libstdc++.so only has the unresolved symbols _Unwind_*,
but no others.
Let me know if you need more information.
-Marek
--
Summary: unresolved symbols in libstdc++, shared lib link
strategy of libgcc.a
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marek dot rouchal at infineon dot com
GCC build triplet: sparc-sun-solaris2.8
GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28377
