From: "Edmund Horner" Newsgroups: comp.os.msdos.djgpp Subject: RE: DXE/DLX and C++ Lines: 49 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4029.2901 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4029.2901 Organization: Paradise Net Ltd. Customer Message-ID: <961062010.341342@shelley.paradise.net.nz> Cache-Post-Path: shelley.paradise.net.nz!unknown AT 203-79-65-203 DOT tnt8 DOT paradise DOT net DOT nz X-Cache: nntpcache 2.4.0b2 (see http://www.nntpcache.org/) Date: Thu, 15 Jun 2000 21:47:09 +1200 NNTP-Posting-Host: 203.96.152.26 X-Complaints-To: newsadmin AT xtra DOT co DOT nz X-Trace: news.xtra.co.nz 961062027 203.96.152.26 (Thu, 15 Jun 2000 21:40:27 NZST) NNTP-Posting-Date: Thu, 15 Jun 2000 21:40:27 NZST To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Firstly, my thanks for your interest and advice. (I was unsure whether to reply to you or to the newsgroup. I have opted for the newsgroup.) Eli Zaretskii said: > Please post here what changes did you do in dxe.ld. Three lines added in the obvious place (eh_fram was already present): *(.ctor) *(.dtor) *(.gcc_exc) > > 2. But I am now stuck with "unable to resolve external symbols" on > > '___builtin_delete', '_terminate__Fv', '___throw', '___builtin_new' and > > '___eh_pc'. > > As explained in section 22.15 of the DJGPP FAQ list, DXE cannot access > functions linked into the main module; the unresolved externals you > cite are from the standard C++ library. Yes; that's why I have made versions of 'strcmp', 'malloc' and 'free' (and soon others) in a support module that gets linked in by dxegen. > I think the easiest way out of this mess (if there is one) would be to > not use any standard C++ classes in your DXE. In particular, it seems > your code uses exceptions and `new' and `delete' operators; try to > rewrite it so as not to use these features. No standard C++ classes are used, nor do I use exceptions. It must be the case that these features are used by the C++ compiler itself, and aren't optional. 'new' and 'delete' can be avoided if necessary... > Another possibility would be to pull the object modules that define > these symbols from libstdcxx.a (using the `ar' utility) and link them > into your DXE. This may well be the solution we have to aim for. > Failing all that, I suggest to rewrite your DXE in C (why do you need > it in C++, anyway?) Finally, the module _must_ be in C++, because it is intended to be compiled from a hybrid HTML/C++ file. I already have the HTML/C version working, this sub-project is for C++. With C++ it is easier to make an intuitive interface that doesn't require much parsing by my own simple code.