Re: [ANNOUNCEMENT] [1.7] Updated: {libtool/libltdl7}-2.2.7a-10

[Dave Korn <dave dot korn dot cygwin at googlemail 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/