libtool assumes that "file" is in /usr/bin

[Vincent Lefevre]

In the generated aclocal.m4 file, one has the following from libtool
(it was generated on Debian/unstable):

# _LT_AC_LOCK
# -----------
AC_DEFUN([_LT_AC_LOCK],
[AC_ARG_ENABLE([libtool-lock],
    [AC_HELP_STRING([--disable-libtool-lock],
        [avoid locking (might break parallel builds)])])
test "x$enable_libtool_lock" != xno && enable_libtool_lock=yes

# Some flags need to be propagated to the compiler or linker for good
# libtool support.
case $host in
ia64-*-hpux*)
  # Find out which ABI we are using.
  echo 'int i;' > conftest.$ac_ext
  if AC_TRY_EVAL(ac_compile); then
    case `/usr/bin/file conftest.$ac_objext` in
[...]

But some systems do not have "file" in /usr/bin. See the bug that has
been reported here:

https://gforge.inria.fr/tracker/index.php?func=detail&aid=5557&group_id=136&atid=619

Is there any reason why libtool uses "/usr/bin/file" instead of "file"
(/usr/bin being in $PATH)?

Perhaps "file" can be a problem under some systems, where the user
may have installed a "file" utility different from the system "file",
which is found first in $PATH and can return different output. So, a
solution could be to locally add /usr/bin in front of $PATH and use
"file".

-- 
Vincent Lefèvre <address@hidden> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)