Re: CVS libtool fails under MinGW 1.0

[Charles Wilson]

Bob Friesenhahn wrote:

> Libtool (probably the 1.5 release) did used to work under MinGW.  A
> recent libtool from CVS does not work properly under MinGW.  The
> symptom is that libtool checks a DLL's validity using the 'file'
> command.  This fails so use of the DLL library is rejected.
>
> The MinGW MSYS environment does not provide a 'file' command so
> libtool shouldn't be trying to use file magic tests.  It is
> questionable if it is really necessary to test a file with a .DLL
> extension to verify that what it most likely is.
>
> I assume that a recent Cygwin enhancement to be more exacting is
> causing MinGW builds to fail.

Perhaps this stanza (around line 2109 in libtool.m4):

cygwin* | mingw* | pw32*)
  # win32_libid is a shell function defined in ltmain.sh
  lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL'
  lt_cv_file_magic_cmd='win32_libid'
  ;;

should be split up into separate mingw and cygwin sections.  I still 
think it's a good idea to disallow inclusion of .a's into dlls (unless 
they are local convenience libs) because of the havoc that auto-EXport 
can wreak.

And cygwin users have proven over and over to be a bit too cavalier 
about renaming files specifically to fool the compiler for me to be 
comfortable with a "test file name only" approach.  (And is a given '.a' 
file really a static library, or the import stub of a DLL?)

So, for cygwin, I think win32_libid should still be used.  But 
mingw/MSYS is free to do whatever they like -- including providing a 
port of 'file'...

--
Chuck