[Top][All Lists]

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

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

From: Guido Draheim
Subject: Re: [Mingw-users] Re: libbfd, libtool & Win32
Date: Tue, 17 Sep 2002 00:23:11 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826

Max Bowsher wrote:
Guido Draheim wrote:

hmm, perhaps, the LD can now link with dlls directly, and that should
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.

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?

Why not just make sure libfoo.dll.a is always available ???

See how Cygwin does it in libtool.m4. Libtool is told that libfoo.dll.a is the
library, and postinstall commands put libfoo.dll into ../bin.

I am not that knowing about the actual backgrounds, but to me
it did look as if one can not be sure about the dll.a format,
so that one does not trust it. Unlike cygwin, it is much more
likely that mingw binds with dlls *not* compiled by mingw gcc
but from another compiler. Since mingw is on the same
augenhoehe ("eye height", here: being-level) other than cygwin's
posixisch environment which is another layer atop the basic
operating system services. And damn, we want to bind with
other dlls for which we have no dll.a available. About all the
other win32 compilers come with some kind of implib.exe that
one can use to make an importlib from any dll that was not
shipped along with that compiler. That is, in another step,
before linking. That's not the gcc/unix way I say, where we
are even used that LD link lines look always somewhat like
-L. -lz, other than the plethora of w32 compilers, IIRC.

Personally, I do not have a problem with having libtool to do
some automatics, to call some implib.exe  if the importlib
is not availabe  - or when one does not trust that the imp.lib
is up to date with the lib in parallel that (the dll versioning
scheme is not quite like that one unix systems, and dlls get
often replaced, while unix sharedlibs are not and get a cousin
in parallel). Anyway, for having libtool to do some automatics
successfully... there has to be an implib.exe-like step that
can be done and trusted.

I don't even have a problem with libtool to wrap some icc or
msvc compiler, and do the correct calls for it, possibly even
calling *their* implib.exe to prepare the link-step. We are
not just talking about cygwin/mingw here, libtool is meant
to wrap even nongcc compilers, although gcc is the most
succesful currently as a crosscompiler, which has given the
current problems we started of earlier on libtool ML.

or am I wrong? oh well..... cheers, guido

reply via email to

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