----- Original Message -----
From: "Guido Draheim" <[EMAIL PROTECTED]>
> > Guido, can you succintely describe what impgen does - particularly
in a
> > cross- environment.
> >
>
> short explanation:
> impgen.exe is the first part of an implib.exe - it scans a given dll
for
> exported symbols and creates an .exp-def file - then the (cross)gcc
is used
> to create a binary import-library. Usage: to bind the zlib, you give
a
> "-lz" on the command line to libtool - libtool will find the .dll
(IIRC it
> will prefer a prebuilt import lib) - scan the export table, create an
> binary import lib, and give it to the linker so that it can be bound
to
> the .dll currently under creation.
Have a look at the output of
objdump -p foo.dll.
Specifically look for the
"[Ordinal/Name Pointer] Table"
which comes in this area:
===
The Export Tables (interpreted .edata section contents)
Export Flags 0
Time/Date stamp xxxx
Major/Minor 0/0
Name 000xxxx foo.dll
Ordinal Base 1
Number in:
Export Address Table 00000779
[Name Pointer/Ordinal] Table 00000779
Table Addresses
Export Address Table 00090028
Name Pointer Table 00091e0c
Ordinal Table 00093bf0
=====
(skip the EAT listing, the ordinal/name pointer is straight after that).
This list does *not* include the imports, only the exports, so I believe
it's what you need. The question is - how to get it.
Well, there are two things here.
1) Current ld can link directly against a dll (-L
/path/to/dll -ldllname).
so I'm not convinced that this process is needed at all.
2) I haven't had time to bulid a debug objdump, but IMO if you build one
and debug a -p foo.dll run you'll find the bfd directory needed to
access the export name pointer table easily.
If you need further assistance (ie an objdump debug session doesn't
make it all come clear), let me know.
> cross-environment:
So, in a cross environment, if binutils provides the tool, you don't
need HOST_CC at all - it's part of the compiler suite (i.e.
i686-pc-mingw-objdump or i686-pc-cygwin-objdump).
What's also worth noting is that the current impgen generated .def file
results in (apparently) some cases of linking-by-ordinal, which means
that drop in replacement dll's have been reported to fail to run. Now
AFAIK the PE loader is meant to search for missing ordinals for the name
pointer import, *shrug*. I'm just mentioning this in passing - IMO it
would be preferrable to skip listing the ordinal in the .def file (given
a revamped impgen process) until this issue is clarified and the real
cause + solution solved. Chuck Wilson can possibly recall more than I of
this issue (which appear about a year ago, an has not IIRC appeared
since).
Rob
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
