Re: [Mingw-users] Re: libbfd, libtool & Win32

[Earnie Boyd]

Guido Draheim wrote:
> 
> hmm, perhaps, the LD can now link with dlls directly, and that should

Yes, indeed it can, and will search for it in the LIBRARY_PATH.  If it
can't find libfoo.dll.a or libfoo.a it will look for libfoo.dll when
-lfoo is given.

> be checked throughoughly. That was achieved by pushing code from the
> dlltool into the LD, what I now wonder if it wouldn't be right to put
> the other part of dlltool into objdump. The LD is used to create a
> dll, and objdump is used to examine a dll, that's the scheme.
> 
> As noted by Rob Collins, the objdump does already exhibit the symbol
> tables and he did guess that there is also the export table which is
> fetched with the impgen.c extra code in libtool - but in a format
> unusable by other compile steps.
> 

Perhaps the methods of sf.net/projects/perdr would be an interesting
study.  It can give the function names and entry address of those
functions from the dll, much like an objdump.

> Now, we have dlltool-z to take a .dll and create a .def file. Can we
> have a w32-specific objdump call to not only print the export-table,
> but have in a def-style format? That we can then use for other
> compile steps?
> 

Yes, I see no reason why objdump should be able to do this.

> Actually, some other platforms use -no-undefined too, and they do of
> course examine the other libs with the help of objdump - it's just
> they need no def files, just map-style functionname lists (for the
> unresolvable symbols detection made by libtool).
> 
> Putting a w32-specific output-formatting option into objdump would
> solve the impgen.c crosscompiler problem too, I hope. And the
> `objdump -p` does already see an export-table today. See the example
> in Rob's message:
>     mail.gnu.org/pipermail/libtool/2002-January/005942.html
> 
> for reference, the description I made back then:
>     http://mail.gnu.org/pipermail/libtool/2002-January/005931.html
> 

Thanks, I'll take a look.

Earnie