This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: risk of mixing libstdc++ versions in one executable
jhfrontz <jeff.frontz@gmail.com> writes:
> Is there a way to confirm that the RTLD_DEEPBIND is doing what I'm
> expecting--namely ensuring that the third-party library is using libstdc++5
> while the main-line code is using libstdc++6? Is it sufficient to observe
> that libstdc++5 is loaded after the libstdc++5-dependent third-party library
> is opened (obviously with RTLD_DEEPBIND specified)?
You could confirm it by creating finding a function which your library
refers to and which should be found in libstdc++.so.5. Define a
version of that function in your main executable, and see which
version is called.
> Maybe I'm not completely understanding the implications of RTLD_DEEPBIND and
> the proof is obvious-- does RTLD_DEEPBIND prevent using any already open
> libraries for symbol resolution?
No, it changes the order in which shared libraries are searched when
resolving dependencies.
> Is the process for run-time symbol
> resolution to first open all referenced shared libraries, then go through
> and resolve the symbols (and thus RTLD_DEEPBIND says "resolve undefined
> symbols contained herein by looking at shared libraries listed as
> dependencies for this DEEPBIND-flagged object and, only if not so resolved,
> look at the global scope" -- that is, the "symbols in this library"
> referenced in the dlsym() man page entry under RTLD_DEEPBIND include the
> symbols brought in as a result of opening the target library's dependency
> libraries)?
Yes, it should the work in the latter way.
Ian