[Mingw-notify] [ mingw-Bugs-1053029 ] libtool needs the "file" command

[SourceForge.net <no...@so...>]

Bugs item #1053029, was opened at 2004-10-24 12:20
Message generated for change (Comment added) made by john-c
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1053029&group_id=2435

Category: msys
Group: component package
Status: Open
Resolution: None
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: johnc (john-c)
Date: 2005-02-18 10:33

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-19 01:27

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-18 07:49

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-18 07:43

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-25 01:11

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 23:23

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