Mail Archives: djgpp-workers/2003/04/20/13:51:53
Hi guys!
You are mixing two different things here! Or are there
three?
PRIMO: Yes, Andrew, you are right: "the DXE code must
not call code in LIBC which is linked with the app".
And here's why: let's take the simpler example.
`statsimp.exe' is linked against LIBC and uses
"strlen"; that means the `strlen' code is being
injected into the DXE. By default, the generator will
make the "strlen" symbol visible *FROM* DXE (unless
you filter it with -E or -X). When you link your
application, the "strlen" entry from LIBC is discarded
and replaced with the one in the import library. The
import library does not contain actual code (only DXE
does!), but wrappers (initially pointing to
`dlopen()'). Now, suppose your application fires and
hits "strlen"; this will invoke `dlopen()' to load
that DXE where "strlen" has moved. But `dlopen()'
needs the *REAL* "strlen", so calling it will again
get to `dlopen()'. It's a deadly embrace situation.
Special note: "strlen" is just an example here. It
might be "open" or "memset" as well! Bottom line,
symbols required by the `dlopen()' code must be hidden
inside DXE, so the linker won't get confused.
So, your problem does not have anything to do with
what Charles suggested. But yes, basically, you'll
need to run dxe3res. Which moves us to the second
point.
SECUNDO: I doubt turning Allegro into a DXE will be of
any usefulness. Because Allegro gives public
variables, such as `mouse_x', `mouse_b' and so on. I
mailed mr. Hargreaves about a month ago, regarding
this issue. He never replied. Having that said, you
need to manually write some little functions:
`get_mouse_x()' etc. because the documentation clearly
states: VARIABLES cannot be accessed directly when
using IMPORT LIBRARIES. The only way to do this is via
`dlsym()' -- which somehow contradicts the import
library concept. The problem lies with the COFF.
Ohwell, I'm tired of this COFF subject... nobody
listens, yet everybody needs "super-cool" dynamic
modules.
For your information, I managed to turn Allegro into a
DXE directly from the static lib. And was able to use
it also :)
And now the grand finale...
TERTIO: the `dlopen()' strength resides in its
tradition. OTOH, the import libraries are important
where you want to use DXEs, YET YOU DON'T WANT TO
CHANGE A LINE OF CODE. All you have to do is pay a
little more attention to how the linking is done, and
provide the symbol table. Unfortunately, the DXE needs
to know where the symbols from the main image are
located. Two or more DXEs can resolve each other (in a
non-cyclical fashion). But when it comes to LIBC,
things get complicated. Charles' plans to build
LIBC.DXE would solve all the aforementioned problems.
There is a workaround... very shallow, though. Make
the import library "touch" the symbols it needs. This
way, the linker will be forced to trigger them
(symbols) from all static libs it requires.
Determining the address will be very simple, then. The
drawback? This method cannot be applied to `dlopen()'
which knows nuts about import libraries.
Again, LIBC.DXE could be the solution...
Ciao Ciao!
PS: Tim was right about the `const'. Excellent
explanation!
=====
Regards,
Borca Daniel
http://www.geocities.com/dborca/
__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
- Raw text -