------- Comment #6 from joerg dot richter at pdv-fs dot de 2009-07-15 13:15
-------
I stumpled across the same problem recently.
Executable references both libstdc++.so and libgcc_s.so.
libstdc++.so references libgcc_s.so.
Both executable dependencies will be correctly resolved (due to RPATH).
But when the dynamic linker tries to resolve the second reference to
libgcc_s.so it is not using the RPATH of the executable. Only the (not
existing) RPATH of libstdc++.so. Which is correct IMHO.
So it goes on and tries the system default search directories. There it finds
another libgcc_s.so. But this time it is an old version. The executable
refused to start, because some versioned symbols could not be found.
If libstdc++.so would be linked with -rpath '$ORIGIN' this would work.
Note that this even works, when libstdc++.so and libgcc_s.so are moved to a
different location.
So I think this bug should be reopened.
Note: this was observed on solaris2.10
--
joerg dot richter at pdv-fs dot de changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |joerg dot richter at pdv-fs
| |dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32354
