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

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

Ian Lance Taylor-3 wrote:
> 
> 
> 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.
> 
> 

Hmm, I'm not sure how to see which version is called-- is there a "version"
function in libstdc++ (or some other function that is in the older one but
not the newer one)?

I think I proved to myself that it works, though- I created two versions of
a function called "whoAmI()", each printing out different strings. I put
each of them into a library (same library name, different versions--version
3 and version 4).  I then put a call to whoAmI() from a
yet-another-function, which I put into yet-another-library (different name
from the first libraries)--yet-another-library is created by linking against
version 3 of the first library.

>From main(), I put in a call whoAmI() to see what version of output comes
out.  I then use dlopen() to open yet-another-library, use dlsym() to find
the address of and call yet-another-function (which also calls whoAmI()).  
I link main() against version 4 of the first library. When I run the
resulting program, the output from the main-line call to whoAmI() comes from
version 4; the output from the call to whoAmI() via yet-another-function
comes from version 3.  I watched via strace and saw that the dlopen() on
yet-another-library explicitly opened version 3 of the first library.

Thanks again for your insight here.  I'll be able to sleep easier tonight
;-)

Jeff

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