From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23615 invoked by alias); 20 May 2003 16:17:25 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 22179 invoked from network); 20 May 2003 16:16:43 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 20 May 2003 16:16:43 -0000 Received: from webmail.ott.qnx.com (webmail.ott.qnx.com [192.168.2.3]) by hub.ott.qnx.com (8.9.3p2/8.9.3) with ESMTP id LAA13361; Tue, 20 May 2003 11:15:04 -0400 Received: (from apache@localhost) by webmail.ott.qnx.com (8.11.2/8.11.2) id h4KEB2j08838; Tue, 20 May 2003 10:11:02 -0400 Message-Id: <200305201411.h4KEB2j08838@webmail.ott.qnx.com> To: "Joe Buck" , Subject: Re: libsupc++, _cxa references, and Dinkum libcpp Date: Tue, 20 May 2003 16:19:00 -0000 From: In-Reply-To: <20030516165135.A12185@synopsys.com> Cc: X-SW-Source: 2003-05/txt/msg01871.txt.bz2 Here is the output of a simple C++ compile using gcc-3.2.3 and our port of the Dinkum libcpp. The Dinkumware implements 'new' and 'delete', but it has not presented as a problem yet, except if we try to use the libsupc++ to resolve the cxa symbols. Which is why I thought that splitting the cxa stuff into a libcxa (that would also be linked into the libsupc++) would work. The symbols in libsupc++ that conflict (multiple definitions) are: std::terminate() std::unexpected() std::set_terminate(void (*)()) std::set_unexpected(void (*)()) It seems to me that cc1plus should not be emitting libstdc++ specific symbols, thereby assuming that the c++ libs being used are only going to be GNU libstdc++. Failing that, providing a libcxa of some kind would be very helpful. Comments? Corrections? Clarifications? Thanks. GP $ /usr/bin/ntox86-ld -b elf32-i386 -m i386nto --dynamic-linker /usr/lib/ldqnx.so.2 /x86/lib/crt1.o /x86/lib/crti.o /usr/lib/gcc-lib/ntox86/3.2.3/crtbegin.o t182c01.o -L/home/gp/cvs/lib/c_res_2/lib/x86/a -L/home/gp/cvs/lib/cpp_res_2/x86/a -lcpp -lc -o a.out -Y/x86/lib:/x86/usr/lib -L/usr/lib/gcc-lib/ntox86/3.2.3 -L/x86/lib /usr/lib/gcc-lib/ntox86/3.2.3/libgcc.a -lc -dn -Bstatic -lc /usr/lib/gcc-lib/ntox86/3.2.3/libgcc.a /usr/lib/gcc-lib/ntox86/3.2.3/crtend.o /x86/lib/crtn.o /home/gp/cvs/gcc_3.2.3/tools/gcc/nto-x86-o-ntox86/ntox86/libstdc++-v3/libsupc++/.libs/libsupc++.a /home/gp/cvs/gcc_3.2.3/tools/gcc/nto-x86-o-ntox86/ntox86/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_terminate.o): In function `std::set_unexpected(void (*)())': /home/gp/cvs/gcc_3.2.3/tools/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:83: multiple definition of `std::terminate()' /home/gp/cvs/lib/cpp_res_2/x86/a/libcpp.a(exceptio.o)(.text+0x5c): first defined here /usr/bin/ntox86-ld: Warning: size of symbol `_ZSt9terminatev' changed from 22 to 32 in /home/gp/cvs/gcc_3.2.3/tools/gcc/nto-x86-o-ntox86/ntox86/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_terminate.o) /home/gp/cvs/gcc_3.2.3/tools/gcc/nto-x86-o-ntox86/ntox86/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_terminate.o): In function `std::set_unexpected(void (*)())': /home/gp/cvs/gcc_3.2.3/tools/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:83: multiple definition of `std::unexpected()' /home/gp/cvs/lib/cpp_res_2/x86/a/libcpp.a(exceptio.o)(.text+0xc4): first defined here /usr/bin/ntox86-ld: Warning: size of symbol `_ZSt10unexpectedv' changed from 28 to 32 in /home/gp/cvs/gcc_3.2.3/tools/gcc/nto-x86-o-ntox86/ntox86/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_terminate.o) /home/gp/cvs/gcc_3.2.3/tools/gcc/nto-x86-o-ntox86/ntox86/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_terminate.o): In function `std::set_unexpected(void (*)())': /home/gp/cvs/gcc_3.2.3/tools/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:83: multiple definition of `std::set_terminate(void (*)())' /home/gp/cvs/lib/cpp_res_2/x86/a/libcpp.a(exceptio.o)(.text+0xc): first defined here /usr/bin/ntox86-ld: Warning: size of symbol `_ZSt13set_terminatePFvvE' changed from 77 to 34 in /home/gp/cvs/gcc_3.2.3/tools/gcc/nto-x86-o-ntox86/ntox86/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_terminate.o) /home/gp/cvs/gcc_3.2.3/tools/gcc/nto-x86-o-ntox86/ntox86/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_terminate.o): In function `std::set_unexpected(void (*)())': /home/gp/cvs/gcc_3.2.3/tools/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:83: multiple definition of `std::set_unexpected(void (*)())' /home/gp/cvs/lib/cpp_res_2/x86/a/libcpp.a(exceptio.o)(.text+0x74): first defined here /usr/bin/ntox86-ld: Warning: size of symbol `_ZSt14set_unexpectedPFvvE' changed from 77 to 34 in /home/gp/cvs/gcc_3.2.3/tools/gcc/nto-x86-o-ntox86/ntox86/libstdc++-v3/libsupc++/.libs/libsupc++.a(eh_terminate.o) Joe Buck said: > On Fri, May 16, 2003 at 09:07:31PM -0000, gp@qnx.com wrote: > > I'm working on porting gcc-3.2.3 to the various QNX platforms. We use both > > libstdc++ and Dinkumware libcpp for C++. The difficulty here is that gcc > > (actually cc1plus I think) is emitting __cxa* symbols, like the call: > > > > push_throw_library_fn (get_identifier ("__cxa_call_unexpected"), tmp); > > > > in gcc/cp/except.c:init_exception_processing(). So when I build the > > Dinkumware with gcc-3.2.3, the libcpp ends up with these undefined references > > to various __cxa symbols. These symbols are in libsupc++, but so are a number > > of other symbols that conflict with the Dinkumware. > > Which symbols conflict? Is Dinkumware attempting to provide fundamental > C++ support routines such as the default operator new? If so, then > there's likely to be more work to do than just separating symbols, since > you'll need to have support library functions that correctly interact with > whatever Dinkumware provides. > --