> -----Original Message----- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 30, 2008 2:21 PM > To: [email protected] > Subject: Re: ABI problem on Darwin > > Eric Lemings wrote: > > > > > >> -----Original Message----- > >> From: Eric Lemings [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday, April 30, 2008 11:05 AM > >> To: [email protected] > >> Subject: RE: ABI problem on Darwin > >> > >> > >> > >>> -----Original Message----- > >>> From: Martin Sebor [mailto:[EMAIL PROTECTED] > >>> Sent: Wednesday, April 30, 2008 10:43 AM > >>> To: [email protected] > >>> 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.
