Re: risk of mixing libstdc++ versions in one executable

[jhfrontz <jeff dot frontz at gmail dot com>]

Ian Lance Taylor-3 wrote:
> 
> 
> Well, I said a C only program, but on further thought I don't think
> that is required.  It should work to write a C++ program, and to just
> dlopen the shared library which uses libstdc++.so.5.  The
> RTLD_DEEPBIND should protect you from the libstdc++ version collision,
> I hope.  The main difficulty is that you need to use dlsym to get the
> functions you want to call; you can't call them directly.
> 
> 

OK, thanks yet again. This sounds very practical and possible.  It's in line
with another posting that I just found
(http://www.nabble.com/-Bug-libc-6610--New%3A-NSS-modules-should-be-dlopen%28%29ed-with-RTLD_DEEPBIND-tt17739013.html#a17739013
).  The functions I need to call in the third-party library are
well-defined/known and I can easily call them by using function pointers set
using dlsym().

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

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

Jeff

-- 
View this message in context: http://www.nabble.com/risk-of-mixing-libstdc%2B%2B-versions-in-one-executable-tp19909697p19948421.html
Sent from the gcc - libstdc++ mailing list archive at Nabble.com.