X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 	tests=AWL,BAYES_00,J_CHICKENPOX_74,SPF_PASS
X-Spam-Check-By: sourceware.org
Message-ID: <49BFD524.4050801@gmail.com>
Date: Tue, 17 Mar 2009 16:51:48 +0000
From: Dave Korn <dave DOT korn DOT cygwin AT googlemail DOT com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: [ANNOUNCEMENT] [1.7] Updated: {libtool/libltdl7}-2.2.7a-10
References: <89694 DOT 8915 DOT qm AT web25006 DOT mail DOT ukl DOT yahoo DOT com> <49BFAD95 DOT 4000709 AT gmail DOT com> <20090317145526 DOT GA12457 AT calimero DOT vinschen DOT de> <20090317150149 DOT GC9322 AT calimero DOT vinschen DOT de>
In-Reply-To: <20090317150149.GC9322@calimero.vinschen.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Corinna Vinschen wrote:
> On Mar 17 15:55, Corinna Vinschen wrote:
>> On Mar 17 14:03, Dave Korn wrote:
>>>   I noticed that the output from 'file' has changed recently, e.g.:
>>>
>>> /bin $ file -L /bin/ls.exe
>>> /bin/ls.exe: MS-DOS executable PE  for MS Windows (console) Intel 80386 32-bit
>>>
>>>   Maybe this will help?  Or perhaps something similar elsewhere.  Libtool uses
>>> file in several ways to help it decide what it's going to build.
>>>
>>>
>>> /bin $ diff -pu libtool.orig libtool
>>> --- libtool.orig        2009-03-15 23:19:29.500000000 +0000
>>> +++ libtool     2009-03-15 23:21:14.906250000 +0000
>>> @@ -3273,6 +3273,7 @@ func_win32_libid ()
>>>    *executable*) # but shell scripts are "executable" too...
>>>      case $win32_fileres in
>>>      *MS\ Windows\ PE\ Intel*)
>>> +    *PE*\ *MS\ Windows\ *Intel*)
>>>        win32_libid_type="x86 DLL"
>> I'm wondering how the original expression was supposed to work even
>> with older file(1) versions:
>>
>>   $ file-4.21 /bin/bash
>>   /bin/bash: MS-DOS executable PE  for MS Windows (console) Intel 80386 32-bit
>>
>> That doesn't match "*MS\ Windows\ PE\ Intel*" as far as I can see.

  Hang on, maybe I've thrown out a red herring here and this is dead code.  I
have a memory of having had to extend some pattern somewhere in libtool to
match new output from 'file' for executables recently but I can't find my notes.

> Either way, do you want me to take this upstream?  I'm already writing
> a mail to the upstream maintainer about the apparent inability to
> recognize troff files.  While I'm at it, I could ask if the string for
> Win32 executables could be reverted to the old style.

  Dunno if it's worth reverting or not, the damage is done now and everyone
just has to fix their scripts (or have them fail on some systems and not
others according to the installed version of file).  *sigh* Maybe you could
just remind them that it would be nice to keep the churn to a minimum.  I
understand there are bound to be issues when you split a detection into two
different subtypes as with dividing ASCII text into ASCII text and ASCII
troff'd text, but the above change seems to just contain the exact same
information in a different order, which seems unnecessary.

    cheers,
      DaveK


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/