From: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: DXE2GEN: unresolved symbol
Date: Wed, 12 Jun 2002 00:01:56 CDT
Organization: Rice University, Houston TX
Lines: 78
Message-ID: <3d06d5c4.sandmann@clio.rice.edu>
References: <3d023ad8$0$23717$9b622d9e AT news DOT freenet DOT de>
NNTP-Posting-Host: clio.rice.edu
X-Trace: joe.rice.edu 1023858765 23587 128.42.105.3 (12 Jun 2002 05:12:45 GMT)
X-Complaints-To: abuse AT rice DOT edu
NNTP-Posting-Date: 12 Jun 2002 05:12:45 GMT
X-NewsEditor: ED-1.5.9
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

> > These are constructors and destructors; you really need to import them
> > from the main image

> Huh? What main image?

When you are trying to dynamically link the DXE it needs to access things
in the image which runs and loads the DXE.  DXE (as bundled with DJGPP)
doesn't currently do this; DXE2 can (I think) if it's set up properly.
This seems to indicate something isn't quite right - bit rot in the
implementation maybe?  

> > (or do something special).

> Oh - well - now - ya think?! :-)
> This whole dxe2gen program is becoming real special.

Someday the out of the box DXE may support this, maybe not ;-)  

> > Use the ld option to create a map; you can then see what included them.

> Good try. It was a bit wierd. The symbols that are causing me trouble are
> nowhere to be found in the mapfile. (there was a
> _djgpp_last_ctor
> but not a
> djgpp_last_ctor)
> They seem to be uninvited guests in my house that have no idea what they are
> doing there.

Sometimes you bring in a module to resolve one symbol, but it brings in
other things which must be resolved itself.  Usually when this happens 
you are already in trouble ...

> > `djgpp_first_dtor'
> > `djgpp_last_ctor'
> > `djgpp_last_dtor'
> > `djgpp_first_ctor'
> > `end'

> So what it sounds like to me is more-or-less "this is normally defined
> on-the-fly automaticly, so it isn't neccessary for you to define it." But
> DXE2GEN is apparently not allowing 'the linker' to define it. This is my
> problem.

Correct.  If it's not clear in the DXE2 docs how to fix this, it just
may not work on what you are trying to build in.

> BTW: By 'the linker', do you mean gcc or really just ld? Because dxe2gen
> *bypasses* gcc and gpp because it calls ld.exe directly. Any command options
> that dxe2gen does not understand get passed on to ld.exe. Suggestion: Could
> there be a direct ld.exe option that defines these symbols (or read
> djgpp.djl )?

gcc calls ld (newer versions call collect which calls ld...); doing gcc -v
will show you the linker options to get the scipt.

> > The linker itself defines those, in accordance with its linker script
> > (lib/djgpp.djl at the moment, or perhaps built in or elsewhere
> > depending on your build).

> > > `__djgpp_selector_limit'

> > crt0.o but it's a "common" definition, so ultimately the linker
> > creates a suitable global for it.

> Been there tried that. I can't call up crt0.o manually. I get a dxe2gen
> error:

> $$dxe$$.o: linker output file has more than one section

You don't want to link in crt0 - it's the startup code for a main image.
The DXE would need to back reference something in the main image
(the selector limit) - which is a special trick.

There are two "enhanced" DXE packages; maybe you should look at the other
one also or check the documentation carefully.  

Dynamic link libraries are not for the faint hearted if you try to do 
complex things.