From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32388 invoked by alias); 13 Jun 2006 16:44:25 -0000 Received: (qmail 32307 invoked by uid 48); 13 Jun 2006 16:44:16 -0000 Date: Tue, 13 Jun 2006 16:55:00 -0000 Message-ID: <20060613164416.32306.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/26792] [4.2 Regression] C++ is broken on *-*-darwin* In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "howarth at nitro dot med dot uc dot edu" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-06/txt/msg01286.txt.bz2 List-Id: ------- 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