Detecting platform version because libstdc++.a disapeared

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

John Smith - 13 Nov 2005 18:56 GMT

Why did libstdc++.a disapear in 10.4? This seems to be a bad thing at first
sight.
When compiling C++ code I used it to create code which would not have
external C++ dependencies. The reason for this is ofcourse increased
compatibility.

Let me give an example:

I use 10.3.9 currently to compile my code (since gcc 4.0.0 had some bugs
which prevented me to use it... these has now been fixed in xcode 2.2) and
relink my c++ object code with libstdc++.a into a new archive file. This
archive is used with a client application for static linking. This works
very good. Users of both 10.3 and 10.4 can use my code. From 10.4 this will
not be possible as 10.5 (or whatever the next future version will be called)
will assumably have another version of libstdc++ which will be binary
incompatible. This means in future I cannot make code which will work for
future platforms unless I stick to 10.3. This will not be possible with
Intel Mac's though.
I know the first thing people will say is to link the archive into a dylib
but this is not an option.

Long story made short I need to identify the platform version from
commandline to change my makefiles to work correctly. Is there any easy way
you can do that?

Thanks in advance.

-- John

Reply to this Message

Eric Albert - 13 Nov 2005 19:21 GMT

> Why did libstdc++.a disapear in 10.4? This seems to be a bad thing at first
> sight.

GCC switched to using a dylib version of it for better system
performance, and because the C++ ABI was finally implemented fully, so
libstdc++ could be guaranteed to be compatible from release to release.

> Let me give an example:
>
[quoted text clipped - 8 lines]
> future platforms unless I stick to 10.3. This will not be possible with
> Intel Mac's though.

Mac OS X 10.3.9 includes libstdc++.dylib. If you can require 10.3.9 or
later, you can use gcc 4.0 (or 4.0.1) and you'll be fine. If you need
to support earlier versions of Mac OS X, you'll have to use gcc 3.3 for
the PowerPC side of your application and gcc 4.0 or later for the Intel
side. Xcode 2.2 supports per-architecture compilers, SDKs, and
deployment targets.

-Eric

Signature

Eric Albert ejalbert@cs.stanford.edu
http://outofcheese.org/

Reply to this Message

John Smith - 14 Nov 2005 06:43 GMT

> GCC switched to using a dylib version of it for better system
> performance, and because the C++ ABI was finally implemented fully, so
> libstdc++ could be guaranteed to be compatible from release to release.

That is true but it only goes for compiled binaries, right? In otherwords
people will have problems when I try to compile object code with g++ 4.0.1
and they will use _any_ other version of g++. This can (an probably will)
result in faulty linking which could succeed and eventually end up as
runtime errors. With the static linking I avoided that scenario.

> Mac OS X 10.3.9 includes libstdc++.dylib. If you can require 10.3.9 or
> later, you can use gcc 4.0 (or 4.0.1) and you'll be fine. If you need
> to support earlier versions of Mac OS X, you'll have to use gcc 3.3 for
> the PowerPC side of your application and gcc 4.0 or later for the Intel
> side. Xcode 2.2 supports per-architecture compilers, SDKs, and
> deployment targets.

Thanks for the notice. I still wonder how to detect which OS I'm compiling
under. There is a env variable named OSTYPE and is set to 'darwin8.0'. If I
remember correctly OS 10.3 was Darwin 7.x.

-- John

Reply to this Message

Eric Albert - 14 Nov 2005 10:09 GMT

> > GCC switched to using a dylib version of it for better system
> > performance, and because the C++ ABI was finally implemented fully, so
> > libstdc++ could be guaranteed to be compatible from release to release.

> That is true but it only goes for compiled binaries, right? In otherwords
> people will have problems when I try to compile object code with g++ 4.0.1
> and they will use _any_ other version of g++. This can (an probably will)
> result in faulty linking which could succeed and eventually end up as
> runtime errors. With the static linking I avoided that scenario.

With static linking, you couldn't build object files that were
compatible between compiler versions because the ABI was different
between each compiler version. Now the ABI has been finalized, so
anyone using gcc 4.0 or later can use the libstdc++ dylib.

> > Mac OS X 10.3.9 includes libstdc++.dylib. If you can require 10.3.9 or
> > later, you can use gcc 4.0 (or 4.0.1) and you'll be fine. If you need
[quoted text clipped - 6 lines]
> under. There is a env variable named OSTYPE and is set to 'darwin8.0'. If I
> remember correctly OS 10.3 was Darwin 7.x.

You generally don't want to do this. The OS that you're targeting is
the interesting value, not the OS that you're building on.

-Eric

Signature

Eric Albert ejalbert@cs.stanford.edu
http://outofcheese.org/

Reply to this Message

Mac Forum / Programming / Mac Programming / November 2005

Detecting platform version because libstdc++.a disapeared