[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS libtool fails under MinGW 1.0

From: Charles Wilson
Subject: Re: CVS libtool fails under MinGW 1.0
Date: Mon, 13 Oct 2003 20:58:58 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624

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
  lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL'

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


reply via email to

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