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

[Guido Draheim]

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