Re: Can't build Win32 DLL that links with static libraries
Hi Neil, * Neil Roberts wrote on Sat, Mar 01, 2008 at 08:24:22PM CET: As I understand it, when linking a shared library libtool checks whether all of the dependencies are found and that they are valid libraries. In the old version of libtool it just did this using objdump which reports the same string regardless of whether the library it finds is static or an import library. However in the new version it will use func_win32_libid if the 'file' command is available. That function returns a different string depending on whether the library is static or import. The regular expression that is tested on this string only accepts import libraries which makes it imposible to link against static libraries. Is this intentional? Yes, I think this was a conscious decision made by the Cygwin/MinGW maintainers of Libtool. Why would you want to stop people linking against static libraries? AFAIK for cleanliness issues. You shouldn't do this on other systems, so it's encouraged to also not do it on w32. I've attached a patch which fixes it for my by just allowing it to match against static libraries as well. A similar patch has been rejected before, for these reasons. (This isn't a rejection, but an AFAIR. For arguing it, it would probably help to look up previous discussions on this.) Hope that helps. Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Can't build Win32 DLL that links with static libraries
Hi, I'm using libtool to cross-compile a Windows DLL (Clutter) from a Linux box. The Windows version of the library depends on a static library called libGLee. This works fine in older versions of libtool but in the version in my Ubuntu installation (1.5.24) it resorts to building a static library with a warning about libGLee. As I understand it, when linking a shared library libtool checks whether all of the dependencies are found and that they are valid libraries. In the old version of libtool it just did this using objdump which reports the same string regardless of whether the library it finds is static or an import library. However in the new version it will use func_win32_libid if the 'file' command is available. That function returns a different string depending on whether the library is static or import. The regular expression that is tested on this string only accepts import libraries which makes it imposible to link against static libraries. Is this intentional? Why would you want to stop people linking against static libraries? I've attached a patch which fixes it for my by just allowing it to match against static libraries as well. Thanks, - Neil --- libtool-2.1b/libltdl/m4/libtool.m4 2008-01-30 12:02:43.0 + +++ libtool-2.1b-patched/libltdl/m4/libtool.m4 2008-03-01 18:41:02.0 + @@ -2974,7 +2974,7 @@ bsdi[[45]]*) cygwin*) # func_win32_libid is a shell function defined in ltmain.sh - lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL' + lt_cv_deplibs_check_method='file_magic ^x86 archive (import|static)|^x86 DLL' lt_cv_file_magic_cmd='func_win32_libid' ;; @@ -2983,7 +2983,7 @@ mingw* | pw32*) # func_win32_libid shell function, so use a weaker test based on 'objdump', # unless we find 'file', for example because we are cross-compiling. if ( file / ) /dev/null 21; then -lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL' +lt_cv_deplibs_check_method='file_magic ^x86 archive (import|static)|^x86 DLL' lt_cv_file_magic_cmd='func_win32_libid' else lt_cv_deplibs_check_method='file_magic file format pei*-i386(.*architecture: i386)?' ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
