libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HOST_CC, crossgcc, mingw32, again/summarized - Re: confusionwith h


From: Robert Collins
Subject: Re: HOST_CC, crossgcc, mingw32, again/summarized - Re: confusionwith host,build,target
Date: Wed, 9 Jan 2002 23:10:01 +1100

----- Original Message -----
From: "Guido Draheim" <address@hidden>


> > 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]