|
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
[Prev in Thread] | Current Thread | [Next in Thread] |