Re: Can we link an application with different libstdc++.so.x version?

[praks]

Thanks Paul for your valuable suggestions.
I have few doubts :
Java provides JNI interface to call C/C++ functions from shared libs.
Suppose JVM is built using gcc 3.3.x and shared libs using gcc 3.4.x,
then how does JVM works in this case.
Similarly, what about some applications which use 3rd party plug-ins,
do they restrict the plug-ins built using specific compilers?

~praks

On Jul 24, 10:20 am, Paul Pluzhnikov <ppluzhnikov-...@gmail.com>
wrote:
> praks <praks.wo...@gmail.com> writes:
> > We want to build an application which requires 3rd party libraries.
> > The 3rd party shared libraries strictly require "libstdc++.so.5" and
> > we don't have source code of these libs
>
> In this case, you *have* to use the same version of GCC which was
> used to link these 3rd party libraries: C++ code compiled with
> different compilers is not link compatible, and gcc-3.3 and 3.4
> are different enough.
>
> > We are using gcc 3.4.x to build main application.
>
> The result of such build is undefined, and should generally not work.
>
> > We have been able to build and link main
> > application with these libraries by using following gcc options:
> > #g++ -rdynamic -g -o app /usr/lib/librt.so /usr/lib/libdl.so /usr/lib/
> > libcrypt.so /usr/lib/libpthread.so /usr/lib/libstdc++.so.5 -
> > l3rdPartyLib1
>
> This command line is largely screwed up, and in fact it's very hard
> to believe that that command produces a runnable application. Don't
> you have any objects to link in? Where is main() coming from?
>
> > It builds and runs fine on my dev ( rhel 4.0 )  machine.
>
> It shouldn't run fine, but for some reason you got (un)lucky.
>
> > But it
> > doesn't work in the build that we gave to QA, we are getting a segv in
> > static initialization of objects.
>
> That's the expected outcome.
>
> > This seems to stem from the fact
> > that we have two versions of libstdc++ linked in the application viz.
> > "libstdc++.so.5" (explicitly linked for 3rd party libs) and "libstdc+
> > +.so.6" (from the complier we are using).
>
> Yes, that's likely the cause.
>
> > Is it fine to use 2 different libstdc++ in same application?
>
> No, it isn't.
>
> You may try to figure out exactly what's different between the QA
> and development box, by comparing the result of running:
>
>   env LD_DEBUG=symbols,bindings ./app
>
> on the two machines. But even if you figure out the difference,
> you are still in "undefined behavior" territory.
>
> Cheers,
> --
> In order to understand recursion you must first understand recursion.
> Remove /-nsp/ for email.