GNU bug report logs - #21400
Location of "file" is hard coded

Previous Next

To reply to this bug, email your comments to 21400 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: John Frankish <john.frankish <at> outlook.com>
To: <bug-libtool <at> gnu.org>
Subject: Location of "file" is hard coded
Date: Wed, 2 Sep 2015 19:18:06 +0400

Hi,

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?

Regards
John

Message #8 received at 21400 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: John Frankish <john.frankish <at> outlook.com>, 21400 <at> debbugs.gnu.org
Subject: Re: bug#21400: Location of "file" is hard coded
Date: Wed, 2 Sep 2015 20:16:10 +0200

On 2015-09-02 17:18, John Frankish wrote:
> Hi,
> 
> 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?

Hi,

and thanks for the report!

I'm not saying that I'm going to look further at this, but we need more
info.

What triplet is this? 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 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).

Cheers,
Peter

Message #11 received at 21400 <at> debbugs.gnu.org (full text, mbox):

From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: 21400 <at> debbugs.gnu.org, John Frankish <john.frankish <at> outlook.com>,
 bug-libtool <at> gnu.org
Subject: Re: bug#21400: Location of "file" is hard coded
Date: Wed, 2 Sep 2015 14:02:55 -0500 (CDT)

On Wed, 2 Sep 2015, Peter Rosin wrote:
>
> 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).

I do recall libtool discussions of the 'file' command from a long time 
ago.  The hard-coded path is surely by design and not by accident.

While there is one popular implementation of the 'file' command it may 
be that there are other programs called 'file' in the path which do 
something else entirely.

Libtool depends on specific text being printed by the 'file' command 
in order to make key decisions.

Bob
-- 
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Message #17 received at 21400 <at> debbugs.gnu.org (full text, mbox):

From: John Frankish <john.frankish <at> outlook.com>
To: <21400 <at> debbugs.gnu.org>
Cc: 'Peter Rosin' <peda <at> lysator.liu.se>
Subject: RE: 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

Message #20 received at 21400 <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: John Frankish <john.frankish <at> outlook.com>, 21400 <at> debbugs.gnu.org
Subject: Re: bug#21400: Location of "file" is hard coded
Date: Thu, 3 Sep 2015 17:50:54 +0200

On 2015-09-03 10:25, John Frankish wrote:
>> 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?

I always thought that /usr/local was for stuff built locally by the local
admin. FHS agrees with me, AFAICT.

Are you saying that tinycorelinux puts optional (non-base) packages in
/usr/local? Seems like a very bad call to me, diverging from every other
distro and unix history is painful, to put it plainly. Not even Gentoo
goes as far as putting stuff in /usr/local, even if everything really is
built by the local admin. Where is the local admin supposed to put
locally built stuff in tinycorelinux, if /usr/local is cluttered with
optional distro packages?

And, I refuse to think that tinycorelinux does not, at least optionally,
offer a GNU file package, so I would suggest that you install that package
and move on (it's not like Libtool depends on any state-of-the-art
option that is only available since file version x.y). If 'file' ends up
under /usr/local when you do that, switch to a sane distro instead.

Besides, as always, whatever Libtool upstream does, it will take a long
time for any change to reach all the packages that you likely want to
build ASAP. So, anything you do to make up for this file problem will
probably not go away anytime soon.

Also see: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17840

Cheers,
Peter

Message #23 received at 21400 <at> debbugs.gnu.org (full text, mbox):

From: John Frankish <john.frankish <at> outlook.com>
To: <21400 <at> debbugs.gnu.org>
Cc: 'Peter Rosin' <peda <at> lysator.liu.se>
Subject: RE: bug#21400: Location of "file" is hard coded
Date: Thu, 3 Sep 2015 20:06:17 +0400

> > > 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?
>
>  I always thought that /usr/local was for stuff built locally by the local
admin.
> FHS agrees with me, AFAICT.
> 
> > Are you saying that tinycorelinux puts optional (non-base) packages in
/usr/local?

Yes :)

> Seems like a very bad call to me, diverging from every other distro and
unix history is painful,
> to put it plainly. Not even Gentoo goes as far as putting stuff in
/usr/local,
> even if everything really is built by the local admin.
> Where is the local admin supposed to put locally built stuff in
tinycorelinux,
> if /usr/local is cluttered with optional distro packages?

If the app doesn't exist, the local admin compiles it to /usr/local and
submits it to the online repo it so everybody can use it.

> And, I refuse to think that tinycorelinux does not, at least optionally,
offer a GNU file package,
> so I would suggest that you install that package and move on
> (it's not like Libtool depends on any state-of-the-art option that is only
available since file
> version x.y). If 'file' ends up under /usr/local when you do that, switch
to a sane distro instead.

Tinycorelinux does offer a GNU file package, which is compiled to
/usr/local.

Of course it's entirely up to you whether to ignore this or not, but as said
previously, it does not  seem logical to search $PATH for items like strip,
ranlib and nm, but not for file.

John

Message #26 received at 21400 <at> debbugs.gnu.org (full text, mbox):

From: Earnie <earnie <at> users.sourceforge.net>
To: John Frankish <john.frankish <at> outlook.com>, 21400 <at> debbugs.gnu.org
Cc: 'Peter Rosin' <peda <at> lysator.liu.se>
Subject: Re: bug#21400: Location of "file" is hard coded
Date: Fri, 4 Sep 2015 09:58:41 -0400

On 9/3/2015 12:06 PM, John Frankish wrote:
> 
> Of course it's entirely up to you whether to ignore this or not, but as said
> previously, it does not  seem logical to search $PATH for items like strip,
> ranlib and nm, but not for file.
> 

Earlier stated that LIBTOOL requires specific strings from file to make
decisions.  Better then that LIBTOOL would package its own version of
file and use that to make those decisions.  Otherwise regardless of
where file exists one is likely to execute the wrong binary.

Also, if I grab the GNU file package and build it with ./configure &&
make && make install where is it installed?  In a prefix of /usr/local
because that is the default!

-- 
Earnie

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.