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: Charles Wilson
Subject: Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2
Date: Tue, 13 Jan 2009 10:41:46 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.5.666

Peter Rosin wrote:
> 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...

After playing with this idea for a while, it made more sense actually to
separate the impgen2 functionality from the dllname stuff. It's not yet
ready for prime time (and I'm trying to keep it in sync with on-going
changes to dlltool in binutils HEAD), but I'll send my latest version of
 these new tools to you offlist.  They compile with both cygwin-gcc
(using libiberty and libbfd from 20080624), and with mingw-gcc-3.4.5
(not sure what binutils version I have; one of the more recent releases
from mingw/sourceforge I'm sure).

>>>>> 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. 
> 
>>> 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...

A new patch to binutils' dlltool was accepted that makes the following
changes to --identify:
  1) automatically determines -- and operates with -- MS-style or
binutils-style implibs
  2) by default, lists all imported DLLs
  3) new --identify-strict flag causes multiple imported DLLs to be
reported as an error
http://sourceware.org/ml/binutils/2009-01/msg00152.html

--
Chuck





reply via email to

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