Mail Archives: djgpp/2002/06/12/01:30:15
> > 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.
- Raw text -