Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: ABI problem on Darwin
Date: Wed, 30 Apr 2008 10:13:15 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A49010A3761@exchmail01.Blue.Roguewave.Com>
Thread-Topic: ABI problem on Darwin
Thread-Index: Aciq2ECYTGn0MlODQDO7YLdw/MBkXAABEu7g
References: <481161B6.2020305@roguewave.com>
 <001B1BAD-BC9B-41BF-9E09-D98F28CA0425@roguewave.com>
 <4815F4AD.2080400@roguewave.com>
 <58479750-45E0-424B-915D-03AF30CFCE69@roguewave.com>
 <4815FA4A.1030603@roguewave.com> <4816A7D3.1020307@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A3750@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA82D@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A49010A3752@exchmail01.Blue.Roguewave.Com>
 <48189236.7000306@roguewave.com>
From: "Eric Lemings" <Eric.Lemings@roguewave.com>
To: <dev@stdcxx.apache.org>

=20

> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]=20
> Sent: Wednesday, April 30, 2008 9:37 AM
> To: dev@stdcxx.apache.org
> Subject: Re: ABI problem on Darwin
>=20
> Eric Lemings wrote:
> > =20
> >=20
> >> -----Original Message-----
> >> From: Travis Vitek [mailto:Travis.Vitek@roguewave.com]=20
> >> Sent: Tuesday, April 29, 2008 12:10 PM
> >> To: dev@stdcxx.apache.org
> >> Subject: RE: ABI problem on Darwin (was: Re: [VOTE] stdcxx=20
> >> 4.2.1 release)
> >>
> >> =20
> >>
> >>> Eric Lemings wrote:
> >>>
> >>> The workaround is to remove the link flags for version info (i.e.
> >>> -compatibility_version and -current_version) from the file
> >>> etc/config/gcc.config.  This takes care of the runtime link error.
> >>
> >> We should probably commit the fix to 4.2.x to get the ball rolling.
> >=20
> > Hold up on that.  I've found the problem may actually have been the
> > result of an anomoly in my environment.  I suspect I may have had
> > another version of the library installed in a standard=20
> location which
> > is why the observation I posted was so puzzling.  My latest builds
> > are running fine.
>=20
> I'm afraid I'm confused about what exactly is the problem,
> or if there even is one. Can you summarize what symptoms
> users might see in the following two scenarios, and what
> is the workaround:
>=20
> 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.
>=20
> 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.
>=20
> 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.

In the first case, the user would encounter incompatible version
error since 4.2.1 specifies version numbers in the library but
4.2.0 does not (i.e. it defaults to 0.0.0).  The 4.2.0 library
would have to be linked with the corresponding flags or the 4.2.1
library would have to be linked without these flags.

In the second case, everything should work correctly, assuming
the DYLD_LIBRARY_PATH variable is set.

Brad.