On Apr 18, 2005, at 2:53 PM, Matthew Sachs wrote:
I got word that the default for -fabi-version in 3.3 is -1, for compatibility with 3.1. So that explains why you can't link -fabi-version=1 packages with 3.3-built default ABI packages.
Code is here: http://www.opensource.apple.com/darwinsource/November2004GCCUpdate/ gcc_os-1671/gcc/c-common.c
I've looked at the source some. Looks like there's no way at all to pass -fabi-version=-1 to gcc, it doesn't like the non-digit '-'. Silly tricks like passing 2**32-1 don't work either. If anybody can figure out some way (however hacky) to specifically tell GCC to use -1, that may solve our problem.
The ONLY change that -fabi-version=1 makes (at least on Panther) is apparently the typeinfo bug that has been discovered. The bug does not occur if -fno-rtti is passed, but of course then programs that use RTTI don't work. Not much code uses typeid or dynamic_cast, so passing -fno-rtti could be a *very temporary* workaround for us, but programs that do need RTTI just won't work. (Unfortunately, if code uses RTTI and it's not enabled, there's no compile-time error, it just fails at runtime.)
Are we sure that mixing things compiled with 'g++-3.3' on panther and on tiger has no problems ?I got an answer on this; you'll need to use the 10.3.9 SDK for this to be guaranteed to work.
I suspect that the non-Apple-guaranteed probability of them working together all the time very closely approaches 1. I wrote a very small test case for the RTTI issue, it's at http://vasi.webhop.org/files/misc/breakgcc.tgz . It's already half-built, under Panther. If anybody wants to test with 'make CC=gcc3.3' on Tiger, that would let us see whether we'd hit this issue in a 3.3 -> 3.3 Tiger transition.
Dave
PGP.sig
Description: This is a digitally signed message part
