* libsupc++, _cxa references, and Dinkum libcpp @ 2003-05-16 21:24 gp 2003-05-16 23:55 ` Joe Buck 0 siblings, 1 reply; 8+ messages in thread From: gp @ 2003-05-16 21:24 UTC (permalink / raw) To: gcc Hi. 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. Does a way exist now to resolve this? If not, perhaps the __cxa stuff coud be split out of libsupc++ into a libcxa.a that gets linked into libsupc++, but could also be installed/used for this kind of situation. This is what I am considering doing internally, but I would have to potentially update my lib with each gcc release. Thoughts? Comments? Thanks. GP ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: libsupc++, _cxa references, and Dinkum libcpp 2003-05-16 21:24 libsupc++, _cxa references, and Dinkum libcpp gp @ 2003-05-16 23:55 ` Joe Buck 2003-05-20 16:19 ` gp 0 siblings, 1 reply; 8+ messages in thread From: Joe Buck @ 2003-05-16 23:55 UTC (permalink / raw) To: gp; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: libsupc++, _cxa references, and Dinkum libcpp 2003-05-16 23:55 ` Joe Buck @ 2003-05-20 16:19 ` gp 2003-05-20 17:34 ` Joe Buck 0 siblings, 1 reply; 8+ messages in thread From: gp @ 2003-05-20 16:19 UTC (permalink / raw) To: Joe Buck, gp; +Cc: gcc 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 <jbuck@synopsys.com> 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. > -- ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: libsupc++, _cxa references, and Dinkum libcpp 2003-05-20 16:19 ` gp @ 2003-05-20 17:34 ` Joe Buck 2003-05-20 18:38 ` gp 0 siblings, 1 reply; 8+ messages in thread From: Joe Buck @ 2003-05-20 17:34 UTC (permalink / raw) To: gp; +Cc: gcc On Tue, May 20, 2003 at 02:11:02PM -0000, gp@qnx.com wrote: > 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 (*)()) So evidently Dinkumware is also trying to provide some exception handling support, not just new and delete. > 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. All the symbols that cc1plus exports should be (and are, as far as I know) provided by libsupc++. That is, any symbol emitted by the compiler itself should be satisfied by that mini-library. You should not need libstdc++. You are running into trouble because Dinkumware is attempting to provide some but not all C++ support. I think you'd be better off stripping the conflicting symbols from Dinkumware and using the libsupc++ symbols. If you don't, you risk trouble later, because the compiler may be assuming properties of the support routines that aren't obeyed by Dinkumware. Supporting the Dinkumware library was never a GNU C++ goal, so if you want to make it work, great, but asking for a redesign of libstdc++ for such a narrow goal doesn't seem reasonable to me. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: libsupc++, _cxa references, and Dinkum libcpp 2003-05-20 17:34 ` Joe Buck @ 2003-05-20 18:38 ` gp 2003-05-20 18:38 ` Joe Buck 2003-05-20 18:41 ` Andrew Pinski 0 siblings, 2 replies; 8+ messages in thread From: gp @ 2003-05-20 18:38 UTC (permalink / raw) To: Joe Buck, gp; +Cc: gcc Thanks, Joe. I appreciate your feedback. I was under the impression that gcc and libstdc++ were seperate products, and that the __cxa symbols being emitted by cc1plus were gnu stdc++ specific, thereby tying gcc to a particular C++ library. And I thought this was generally undesireable, as opposed to being undesireable just for me. Always willing to be corrected. :-) So to clarify my understanding, the __cxa symbols being emitted by cc1plus are part of the C++ standard, and are missing from Dinkumware, yes? Cheers, and thanks again. GP Joe Buck <jbuck@synopsys.com> said: > On Tue, May 20, 2003 at 02:11:02PM -0000, gp@qnx.com wrote: > > 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 (*)()) > > So evidently Dinkumware is also trying to provide some exception handling > support, not just new and delete. > > > 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. > > All the symbols that cc1plus exports should be (and are, as far as I know) > provided by libsupc++. That is, any symbol emitted by the compiler itself > should be satisfied by that mini-library. You should not need libstdc++. > > You are running into trouble because Dinkumware > is attempting to provide some but not all C++ support. I think you'd be > better off stripping the conflicting symbols from Dinkumware and using > the libsupc++ symbols. If you don't, you risk trouble later, because the > compiler may be assuming properties of the support routines that aren't > obeyed by Dinkumware. Supporting the Dinkumware library was never a > GNU C++ goal, so if you want to make it work, great, but asking for a > redesign of libstdc++ for such a narrow goal doesn't seem reasonable to me. > -- ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: libsupc++, _cxa references, and Dinkum libcpp 2003-05-20 18:38 ` gp @ 2003-05-20 18:38 ` Joe Buck 2003-05-20 19:37 ` gp 2003-05-20 18:41 ` Andrew Pinski 1 sibling, 1 reply; 8+ messages in thread From: Joe Buck @ 2003-05-20 18:38 UTC (permalink / raw) To: gp; +Cc: gcc On Tue, May 20, 2003 at 05:21:34PM -0000, gp@qnx.com wrote: > > > Thanks, Joe. I appreciate your feedback. > > I was under the impression that gcc and libstdc++ were seperate products, and > that the __cxa symbols being emitted by cc1plus were gnu stdc++ specific, > thereby tying gcc to a particular C++ library. And I thought this was > generally undesireable, as opposed to being undesireable just for me. > > Always willing to be corrected. :-) It appears that you continue to confuse libsupc++ and libstdc++. The former is a tiny library, the latter is a big library. The compiler alone will generate code that requires only the former. > So to clarify my understanding, the __cxa symbols being emitted by cc1plus are > part of the C++ standard, and are missing from Dinkumware, yes? No. Names beginning with double underscore are reserved to the implementation: they are non-portable compiler internals. According to ISO C++ rules, user programs may not define such names, only the compiler and standard library get to (programmers who violate this rule might get away with it, but they are not writing portable programs). Dinkumware probably contains a number of its own double-underscore names, to implement needed features. They are allowed to use this namespace because they are also implementing a standard library. GNU C++ assumes that libsupc++ is present. Your problem appears to be that Dinkumware wants to provide its own version of some things that libsupc++ provides. So, you'll have to hack one or the other. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: libsupc++, _cxa references, and Dinkum libcpp 2003-05-20 18:38 ` Joe Buck @ 2003-05-20 19:37 ` gp 0 siblings, 0 replies; 8+ messages in thread From: gp @ 2003-05-20 19:37 UTC (permalink / raw) To: Joe Buck, gp; +Cc: gcc Joe Buck <jbuck@synopsys.com> said: > > It appears that you continue to confuse libsupc++ and libstdc++. The > former is a tiny library, the latter is a big library. The compiler alone > will generate code that requires only the former. Ok. Thanks. > > So to clarify my understanding, the __cxa symbols being emitted by cc1plus > > are part of the C++ standard, and are missing from Dinkumware, yes? Sorry, I mispoke/mistyped. I meant ABI, not standard. > Your problem appears to be that Dinkumware wants to provide its own version > of some things that libsupc++ provides. So, you'll have to hack one or the > other. Yes, you are right. I was wrong. I will chase this from my end with Dinkumware. As I said, always willing to be corrected. :-) Thanks again. GP ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: libsupc++, _cxa references, and Dinkum libcpp 2003-05-20 18:38 ` gp 2003-05-20 18:38 ` Joe Buck @ 2003-05-20 18:41 ` Andrew Pinski 1 sibling, 0 replies; 8+ messages in thread From: Andrew Pinski @ 2003-05-20 18:41 UTC (permalink / raw) To: gp; +Cc: Andrew Pinski, Joe Buck, gcc Not really, they are part of the C++ abi used by gcc, the ia64 c++ abi. Thanks, Andrew Pinski On Tuesday, May 20, 2003, at 13:21 US/Eastern, <gp@qnx.com> wrote: > > So to clarify my understanding, the __cxa symbols being emitted by > cc1plus are > part of the C++ standard, and are missing from Dinkumware, yes? ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-05-20 18:59 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-05-16 21:24 libsupc++, _cxa references, and Dinkum libcpp gp 2003-05-16 23:55 ` Joe Buck 2003-05-20 16:19 ` gp 2003-05-20 17:34 ` Joe Buck 2003-05-20 18:38 ` gp 2003-05-20 18:38 ` Joe Buck 2003-05-20 19:37 ` gp 2003-05-20 18:41 ` Andrew Pinski
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).