bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#21400: Location of "file" is hard coded


From: John Frankish
Subject: bug#21400: Location of "file" is hard coded
Date: Thu, 3 Sep 2015 12:25:08 +0400

> > I see an error that /usr/bin/file cannot be found when running the 
> > configure script in many packages - in my distro "file" is at
/usr/local/bin/file.
> > 
> > As an example, using NetworkManager-1.0.4, gives:
> > 
> > ./configure
> > ...
> > checking for archiver @FILE support... @ checking for strip... strip 
> > [which is in /usr/local/bin] checking for ranlib... ranlib [which is 
> > in /usr/local/bin] checking command to parse /usr/local/bin/nm -B 
> > output from gcc object... ok checking for sysroot... no
> > ./configure: ./configure.lineno: line 1: /usr/bin/file: not found [but 
> > it is in /usr/local/bin] checking for mt... no checking if : is a 
> > manifest tool... no checking for dlfcn.h... yes
> > 
> > I'm told this is due to the location of "file" being hard coded in
> > NetworkManager-1.0.4/m4/libtool.m4
> > 
> > Would it be possible to look for "file" in $PATH instead?
> 
> I'm not saying that I'm going to look further at this, but we need more
info.
> 
> What triplet is this?

In this case x86_64, but the same thing happens on 32-bit x86

> Did you build from the NetworkManager-1.0.4 release tar-ball (which
includes Libtool 2.4.2),
> or did you build NetworkManager from git?
> And what version of Libtool did you bootstrap with in case you did use
git?

I built from the NetworkManager-1.0.4 release tar-ball, but the same thing
happens on many other release tar-balls

> I had a quick look, and AFAICT, all uses of hardcoded /usr/bin/file are in
system-specific code paths.
> So, you must have the file utility in an odd location for your type of
system
> (and /usr/local/bin seems a bit odd for a basic utility such as file).

This distro (tinycorelinux) works on the basis that anything not in the base
release should be compiled to /usr/local, which I believe was the original
idea of /usr/local.

As can be seen from above, the configure script finds strip, ranlib and nm
in /usr/local so it would be kind of logical that it could find file in the
same place, no?

John





reply via email to

[Prev in Thread] Current Thread [Next in Thread]