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

[Robert Heller]

At Thu, 24 Jul 2008 01:29:27 -0700 (PDT) praks <praks.world@gmail.com> wrote:

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

A *plain* C application has 'broader' requirements WRT run-time lbraries
-- the *plain* C GLIBC libraries are much more downward compatible than
the StdC++ libraries.  *Plain* C applications built with gcc versions as
old as 2.xxx will run on modern systems, if linked against a new enough
GLIBC.  I have some RedHat 9 built *plain C* apps that run just fine
under RHEL 4. C++ is very much more version specific.  You will need to
either re-build the old third party libraries (or simply replace them
with modern or open source equivalents) or replicate the build
environment used when these libraries were built and build your system
with this build environment. 


> 
> ~praks
> 
> On Jul 24, 10:20=A0am, 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 ) =A0machine.
> >
> > 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:
> >
> > =A0 env LD_DEBUG=3Dsymbols,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.
> 
>                                                                               
>                         

-- 
Robert Heller             -- Get the Deepwoods Software FireFox Toolbar!
Deepwoods Software        -- Linux Installation and Administration
http://www.deepsoft.com/  -- Web Hosting, with CGI and Database
heller@deepsoft.com       -- Contract Programming: C/C++, Tcl/Tk