[Bug target/26792] [4.2 Regression] C++ is broken on *-*-darwin*

[geoffk at gcc dot gnu dot org]

------- Comment #2 from geoffk at gcc dot gnu dot org  2006-06-06 01:17 -------
Clearly, we cannot add any symbols to the 10.4 libgcc_s.  10.4 has already
shipped, and we do not have a time travel device.

By default, gcc compiles for the earliest OS version it knows about.  For C++,
that means 10.3.9/10.4.  This is best for users.

Thus, by default, you cannot use any new symbols in libgcc_s.

The problem occurs because libstdc++ wants to use the new symbol by default.  I
can think of a bunch of solutions to the problem:
1. Have libstdc++ use autoconf to detect the presence of the new symbol and use
it only if it exists.
2. Decide that the purpose of libstdc++ is to be installed only on new (not yet
existing) system versions, and pass appropriate flags to the compiler to make
this happen.  Of course, this might make testing hard for people still using
10.4.
3. Decide that libstdc++ and libgcc go together, and hack libstdc++'s link to
use libgcc_s.1.dylib directly.  Apple doesn't do this internally, we're
shipping 4.0.0 libstdc++ and 4.0.1 libgcc.   Apple's libstdc++ is binary
incompatible with FSF libstdc++ (in small but important ways) and so the effect
of this might be that no-one can use FSF libstdc++ or FSF libgcc on Darwin at
all.
4. Declare that we don't care.  The problem right now affects only people with
the MACOSX_DEPLOYMENT_TARGET environment variable set which they probably
shoudn't have set while building FSF GCC.

I think we should go for (1), although (4) has certain advantages...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792