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

[howarth at nitro dot med dot uc dot edu]

------- Comment #4 from howarth at nitro dot med dot uc dot edu  2006-06-13 16:44 -------
Geoff,
    Does any other os, that uses gcc, version libgcc_s in the manner that Apple
does?
Simply not setting MACOSX_DEPLOYMENT_TARGET during the build of gcc 4.2 doesn't
make the problem go away. The resulting libstdc++.6.dylib and libgcc_s.1.dylib
libraries
have _Unwind_GetIPInfo symbols whereas libgcc_s.10.4.dylib and
libgcc_s.10.5.dylib
don't. This precludes safely using MACOSX_DEPLOYMENT_TARGET  at all with gcc
4.2.
I know you said you won't assign this to yourself until it happens to you.
However it
isn't happening to you because you don't want it to. Apple really needs to deal
with the
breakage caused by their decision to version libgcc_s.
                        Jack


(In reply to comment #2)
> 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