libtool-patches
[Top][All Lists]
Advanced

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

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


From: Peter Rosin
Subject: Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2
Date: Tue, 06 Jan 2009 08:10:34 +0100
User-agent: Thunderbird 2.0.0.19 (Windows/20081209)

Den 2009-01-06 02:06 skrev Charles Wilson:
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.

Right, but it still seems as if this new fixed impgen tool is closer
to MinGW than to MSYS proper. However, as you say, better ask on a better
list...

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?

Agreed.

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

I'm only saying that from the "binutils p.o.v." it makes at least some
sence to report all imported dlls. At least optionally, but again, this
was just a minor point...

Cheers,
Peter




reply via email to

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