|
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 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
[Prev in Thread] | Current Thread | [Next in Thread] |