From: SourceForge.net <no...@so...> - 2005-02-18 11:57:14
|
Bugs item #1053029, was opened at 2004-10-23 22:50 Message generated for change (Comment added) made by earnie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1053029&group_id=2435 Category: msys Group: component package >Status: Pending >Resolution: Accepted Priority: 8 Submitted By: Johan Boulé (johan-boule) Assigned to: Earnie Boyd (earnie) Summary: libtool needs the "file" command Initial Comment: libtool relies on the "file" command to determine the type of a library file, but the "file" command isn't included in any of the packages. To reproduce the bug, simply try to make libtool link a shared library against other shared libraries referred by -L/-l options. The bug is so obvious that now i wonder if i missed a package which contains this required "file" command. Regards. ---------------------------------------------------------------------- >Comment By: Earnie Boyd (earnie) Date: 2005-02-18 06:57 Message: Logged In: YES user_id=15438 I will be using the script provided by johan-boule. ---------------------------------------------------------------------- Comment By: johnc (john-c) Date: 2005-02-17 19:03 Message: Logged In: YES user_id=1221988 I have used the file command provided by GnuWin32 (http://gnuwin32.sourceforge.net/) with success. This works from both DOS and Msys shells if you install it in the mingw directory. ---------------------------------------------------------------------- Comment By: Johan Boulé (johan-boule) Date: 2005-01-18 09:57 Message: Logged In: YES user_id=96100 Here is the minimalistic 'file' command as an attached file. ---------------------------------------------------------------------- Comment By: Johan Boulé (johan-boule) Date: 2005-01-17 16:19 Message: Logged In: YES user_id=96100 just some info... The place where libtool use the 'file' command is in the win32_libid() shell function in the libtool file itself. ---------------------------------------------------------------------- Comment By: Johan Boulé (johan-boule) Date: 2005-01-17 16:13 Message: Logged In: YES user_id=96100 Hello, Since we only need the 'file' command because libtool require it to determine the type of library files, i propose a minimalistic version of it not to bloat msys-dtk with uneeded things: #!/bin/sh while $(echo "$1" | grep --silent '^-') do shift done case "$1" in *.exe) echo "MS Windows PE 32-bit Intel 80386 console executable not relocatable" ;; # libtool doesn't match the "32-bit" *.dll) echo "MS Windows PE 32-bit Intel 80386 console DLL" ;; *.dll.a) echo "ar archive import library" ;; # <-- import library for relocatable library *.a | *.lib) echo "ar archive" ;; # <-- could be static library or import library for relocatable library; libtool will use objdump to find out *) echo "unkown" ;; esac #eof I have tested in in some complex cases involving many libraries of different types and naming conventions, and it works well. Regards. ---------------------------------------------------------------------- Comment By: Johan Boulé (johan-boule) Date: 2004-10-24 11:41 Message: Logged In: YES user_id=96100 Thank you :-) I think libtool tries to find shared libraries (or import libraries) in favor of static ones, maybe because I run libtool with options to disable static libraries and enabled shared libraries. Anyway, it tries to determine the type of each "potential" library file (whose name matches libfoo.la, libfoo.a, libfoo.dl.a or libfoo.dll), and since libtool doesn't test wether the "file" command exist, all files are reported as being of unkown type, and libtool stops, complaning it can't find the "real file for library -lfoo, using file magic". ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2004-10-24 09:53 Message: Logged In: YES user_id=15438 Must be a newer requirement to prevent static and shared mixture. In my opinion that is not correct since I can indeed link a static library when creating a dll. I will add file to the next MSYS snapshot. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1053029&group_id=2435 |