Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2

[Charles Wilson]

On Mon, 05 Jan 2009 21:55:13 +0100, "Peter Rosin" said:
> Works for me (also works for import libs produced with the msvc branch).

Good.

> How likely is dllname to make it into msys 1.11? Or will that have to
> wait until 1.12? (I'm asking what you think, I know that definitive
> answers to such questions are in short supply...)

I can put it on the mingw sourceforge site as a standalone package
myself.

Lobbying Cesar and/or Keith to include it in the "standard" msys-1.11
set...well, that's up to them, I guess.

Because it is similar in purpose to the pexports (latest version here:
http://www.mail-archive.com/address@hidden/msg00125.html

and to the reimp [*] program, it might be more logical to include
dllname in the mingw-utils package that those other two programs belong
to.  However, mingw-utils is a grab bag of a lot of stuff, most of it
unmaintained, which just won't become part of the default msys
installation. So, putting on my msys/mingw project developer hat, I'd be
in favor of splitting the various pieces of mingw-utils into separate
packages, then pushing (e.g.) for pexports and a (working) reimp into
the "base" msys distro.

Then, it makes sense for this new dllname tool to be its own package,
and also to push for it to be included in the "base" msys distro.  To
that end, then, even if it is logical for dllname to go into
mingw-utils, I'd anticipate a hoped-for splitup and keep dllname
separate.  Furthermore, since reimp seems rather badly broken, its
--only-def functionality could be replaced by dllname (with its current
"impgen" historical functionality).  Then, dllname + dlltool = (working)
reimp.  'Course, at that point, the dllname --identify is only a small
part of the prog's functionality, and the name should probably be
reverted to impgen anyway.

==================
[*] Aside: I've never had much luck with reimp. On the surface, it seems
like the logical place to put "I have a MS lib and want information
about it".  It's purpose is to, given an MS .lib, create either a DEF
file or a gcc-style .a import lib. This means it extracts the target DLL
name, etc.  In fact: 
   reimp --only-def foo.lib |\
      sed -n -e /^LIBRARY/s/^LIBRARY[ \t][ \t]*\([^ \t]*\)[
      \t]\{0,1\}/\1/p'
should work. But I've never managed to get reimp to work at all, which
is why I:

1) long ago went hunting for the libtool impgen.c code and had a
cleaned-up, libbfd-ified version sitting around on my harddrive
2) then, when I wanted the "what DLL goes with this .dll.a" I used my
version of impgen as the original testbed
3) finally, I decided to take that --identify functionality and make it
into a patch for dlltool
(with a lot of cross-fertilization in the process).

Anyway, reimp is supposed to "convert Microsoft's new-style (short)
import libraries to import libraries for win32 ports of GNU tools
(mingw32, cygwin)." 'new-style'? What?
==================


> However, from where I'm sitting adding a tool to MSYS proper that really
> only benefits MSVC users (MinGW users could just as well have it
> distributed with MinGW) seems a bit far fetched.

Maybe. You don't know til you ask.

> Or? There are ways to
> dig out the info using the dumpbin and lib programs, so it's not a
> showstopper if this is not added to MSYS, even if the code in libtool
> will be a wee bit longer. When there is an alternative, it seems even
> more far fetched to have dllname added to MSYS. But *I* wouldn't say no
> to it of course...

Maybe under that name. But a libbfd-ified version of impgen (as a
replacement for the IMO totally broken -- but part of mingw-utils-0.3 --
reimp program), that happens to also supply an --identify <foo>
--identify-ms functionality? Not so far-fetched.

> BTW, my libiberty is probably old, I had to take out the expandargv
> call and add this CONST_STRNEQ definition:
> #define CONST_STRNEQ(STR1,STR2) (strncmp (STR1, STR2 "", sizeof (STR2) -
> 1) == 0)

Yeah, I was using the cygwin distro. If you dl the latest binutils from
mingw, you should get a newer libiberty. I think.

> >> (Speaking of dependencies, I don't think the current MinGW code
> >>  in libtool requires 'file' to be present, and I don't think it is
> >>  part of a minimal MSYS install. It's not in my install anyway.)
> > 
> > Only because its been over two years since "msys 1.11 will be ready
> > RSN". It is intended that the file package be included in the minimal
> > 1.11 install.
> 
> Oh, ok. Good enough for me.

Ditto join, paste, BTW.
 
> >> I have found that for MSVC import libraries the simplest thing is
> >> to list the archive members to get to the dll name. I have tried
> >> with:
> >>   lib -nologo -list $implib | grep -v '\.obj$' | sort -u
> >> or, in gnu speak:
> >>   ar t $implib | grep -v '\.obj$' | sort -u
> > 
> > I noticed that, but wasn't sure if self-compiled (using MSVC) import
> > libraries were the same.
> 
> They are (at least mine...)

Good to know.

> >> Also, it will not fail for Vfw32.Lib, it will instead list the three
> >> dlls it imports (AVICAP32.dll, AVIFIL32.dll, MSVFW32.dll).
> > 
> > Well, we probably want it to fail. dlpreopen is supposed to work like
> > dlopen -- and you'd need to dlopen each of the three DLLs separately.
> > But if you -dlpreopen Vfw32.Lib, you'd need to determine which symbols
> > IN Vfw32.Lib came from which DLL, and generate three different groups in
> > you LT_LTX_*[] structure, to register those symbols with their effective
> > "dlopen" source:
> >    { "AVICAP32.dll", 0 }
> >    { .... symbols .... }
> >    { "AVIFIL32.dll", 0 }
> >    { .... symbols .... }
> >    { "MSVFW32.dll", 0 }
> >    { .... symbols .... }
> > I don't think this is going to work well.
> 
> I don't really see why this is not going to work well, but I'm not a
> heavy libltdl user (yet...) so I'm pretty ignorant on the subject.

No, what I meant was: IF you constructed all that then it would work.
BUT there is no support currently in libtool for generating that kind of
thing from a single implib.  It would be very ugly indeed.  So, at
present if func_msvc_dll_for_implib returns a list of DLLs, what will
the caller actually do?  How will the caller know which symbols should
go with which DLL? Does it need to be stateful?

But weigh the cost/benefit: LOADS of new code to write, test, and debug
-- so that a pathological import lib that specifies imports from more
than one DLL can be -dlpreopened.  Is it worth it? What's the
opportunity cost -- what /other/ more useful things could that
developer-time be spent on?

> So, for the sake of argument, I agree that it should fail. But then I
> think it should fail in libtool, not in the tool that digs out the
> dll name(s) from the import library. But that's a minor point...

Well, see this and the following thread:
http://sourceware.org/ml/binutils/2008-11/msg00078.html

--
Chuck