Mail Archives: djgpp/2000/06/15/17:22:13
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.
- Raw text -