incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Lemings" <Eric.Lemi...@roguewave.com>
Subject RE: ABI problem on Darwin
Date Wed, 30 Apr 2008 20:50:57 GMT
 

> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com] 
> Sent: Wednesday, April 30, 2008 2:21 PM
> To: dev@stdcxx.apache.org
> Subject: Re: ABI problem on Darwin
> 
> Eric Lemings wrote:
> >  
> > 
> >> -----Original Message-----
> >> From: Eric Lemings [mailto:Eric.Lemings@roguewave.com] 
> >> Sent: Wednesday, April 30, 2008 11:05 AM
> >> To: dev@stdcxx.apache.org
> >> Subject: RE: ABI problem on Darwin
> >>
> >>  
> >>
> >>> -----Original Message-----
> >>> From: Martin Sebor [mailto:sebor@roguewave.com] 
> >>> Sent: Wednesday, April 30, 2008 10:43 AM
> >>> To: dev@stdcxx.apache.org
> >>> Subject: Re: ABI problem on Darwin
> >>>
> >>> Eric Lemings wrote:
> >>> [...]
> >>>>> 1) In a program compiled and linked with 4.2.0 the user
> >>>>>     replaces libstd.dylib.4.2.0 with libstd.dylib.4.2.1.
> >>>>>
> >>>>> 2) In a program compiled and linked with 4.2.1 the user
> >>>>>     replaces libstd.dylib.4.2.1 with libstd.dylib.4.2.0.
> >>>>>
> >>>>> In both of these, the library is NOT in BUILDDIR/lib but
> >>>>> rather under PREFIX/lib (e.g., /usr/local/lib).
> >>>> In this situation, the user would have to set the 
> >> DYLD_LIBRARY_PATH
> >>>> as they would have to set LD_LIBRARY_PATH on other Unix 
> platforms.
> >>> I assume "this situation" refers to case (2) above. On most
> >>> platforms setting LD_LIBRARY_PATH can be avoided by installing
> >>> the lib in one of the usual locations that the dynamic linker
> >>> searches by default (e.g., /usr/lib or /usr/local/lib). Does
> >>> hardcoding BUILDDIR have any impact on this? (I can't tell
> >>> from the Mac OS X ld man page: http://tinyurl.com/4grw9o)
> >> I believe it works the same on Darwin: if the library is installed
> >> in a standard location, it will be found without needing to set
> >> DYLD_LIBRARY_PATH or whether it matches @install_name.
> >>
> >> I'll verify that to make sure.
> > 
> > Verified.  I moved the library with an @install_name of
> > /var/tmp/stdcxx/build/lib/libstd.dylib.4.2.1 to /usr/local/lib,
> > made sure DYLD_LIBRARY_PATH had no value, and ran a test.  It
> > worked.  I removed /usr/local/lib/libstd.*, tried the test
> > again and it failed with "image not found".
> 
> Okay, so the only ABI problem is with forward compatibility
> (i.e., moving an executable linked with 4.2.1 to a system
> with 4.2.0 installed).

Other way around actually.  Replacing 4.2.0 with 4.2.1 -- binary
upgrades are not so uncommon -- works okay since 4.2.0 has no
compatibility version (i.e. 0) and the 4.2.1 has a greater (i.e.
compatible) version number.  The problem is with the opposite scenario
which should be much more rare occurrence -- replacing a newer
installation with an older library version.

Speaking of which, can anyone think of an actual scenario for doing the
latter?  Just curious.

Brad.

Mime
View raw message