GNU bug report logs - #17840
[PATCH] libtool: Use 'file' instead of '/usr/bin/file' on GNU systems.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17840 in the body.
You can then email your comments to 17840 AT debbugs.gnu.org in the normal way.

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

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: bug-libtool <at> gnu.org
Cc: Mark H Weaver <mhw <at> netris.org>
Subject: [PATCH] libtool: Use 'file' instead of '/usr/bin/file' on GNU systems.
Date: Mon, 23 Jun 2014 21:43:05 +0200

[Message part 1 (text/plain, inline)]

Hello,

The patch below changes occurrences of ‘/usr/bin/file’ to just ‘file’.

The impetus is that on systems using GNU Guix, NixOS, GoboLinux, and
others, the ‘file’ command is not available as /usr/bin/file, so it must
instead be taken from $PATH.

(I conservatively left ‘/usr/bin/file’ for more centralized systems such
as BSD, IRIX, etc. where it’s more likely to be a valid command.)

WDYT?

Ludo’.

[0001-libtool-Use-file-instead-of-usr-bin-file-on-GNU-syst.patch (text/x-patch, inline)]

From 8b4c022281a7c86c2fa604fc76297ffc1ceb2644 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= <ludo <at> gnu.org>
Date: Mon, 23 Jun 2014 21:36:39 +0200
Subject: [PATCH] libtool: Use 'file' instead of '/usr/bin/file' on GNU
 systems.

* m4/libtool.m4 (_LT_ENABLE_LOCK): Use 'file' instead of '/usr/bin/file'
  on GNU- and Linux-based systems.
---
 m4/libtool.m4 | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 320d8b3..6fb67b0 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1312,7 +1312,7 @@ mips64*-*linux*)
   echo '[#]line '$LINENO' "configure"' > conftest.$ac_ext
   if AC_TRY_EVAL(ac_compile); then
     emul=elf
-    case `/usr/bin/file conftest.$ac_objext` in
+    case `file conftest.$ac_objext` in
       *32-bit*)
 	emul="${emul}32"
 	;;
@@ -1320,7 +1320,7 @@ mips64*-*linux*)
 	emul="${emul}64"
 	;;
     esac
-    case `/usr/bin/file conftest.$ac_objext` in
+    case `file conftest.$ac_objext` in
       *MSB*)
 	emul="${emul}btsmip"
 	;;
@@ -1328,7 +1328,7 @@ mips64*-*linux*)
 	emul="${emul}ltsmip"
 	;;
     esac
-    case `/usr/bin/file conftest.$ac_objext` in
+    case `file conftest.$ac_objext` in
       *N32*)
 	emul="${emul}n32"
 	;;
@@ -1348,14 +1348,14 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
   # not appear in the list.
   echo 'int i;' > conftest.$ac_ext
   if AC_TRY_EVAL(ac_compile); then
-    case `/usr/bin/file conftest.o` in
+    case `file conftest.o` in
       *32-bit*)
 	case $host in
 	  x86_64-*kfreebsd*-gnu)
 	    LD="${LD-ld} -m elf_i386_fbsd"
 	    ;;
 	  x86_64-*linux*)
-	    case `/usr/bin/file conftest.o` in
+	    case `file conftest.o` in
 	      *x86-64*)
 		LD="${LD-ld} -m elf32_x86_64"
 		;;
-- 
1.8.4

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

From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Mark H Weaver <mhw <at> netris.org>, bug-libtool <at> gnu.org, 17840 <at> debbugs.gnu.org
Subject: Re: bug#17840: [PATCH] libtool: Use 'file' instead of '/usr/bin/file'
 on GNU systems.
Date: Tue, 24 Jun 2014 08:35:30 -0500 (CDT)

[Message part 1 (text/plain, inline)]

On Mon, 23 Jun 2014, Ludovic Courtès wrote:

> Hello,
>
> The patch below changes occurrences of ‘/usr/bin/file’ to just ‘file’.
>
> The impetus is that on systems using GNU Guix, NixOS, GoboLinux, and
> others, the ‘file’ command is not available as /usr/bin/file, so it must
> instead be taken from $PATH.
>
> (I conservatively left ‘/usr/bin/file’ for more centralized systems such
> as BSD, IRIX, etc. where it’s more likely to be a valid command.)

Were you able to re-test on all of the impacted platforms?

The reason for the hard-coded path is because there are a number of 
different 'file' programs and libtool expects particular output from 
the 'file' program that it uses.  If the 'file' encountered via PATH 
is not the same as the common one available as ‘/usr/bin/file’ on GNU 
systems, then there would be a problem.

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

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
Cc: Mark H Weaver <mhw <at> netris.org>, bug-libtool <at> gnu.org, 17840 <at> debbugs.gnu.org
Subject: Re: bug#17840: [PATCH] libtool: Use 'file' instead of '/usr/bin/file'
 on GNU systems.
Date: Tue, 24 Jun 2014 16:37:23 +0200

Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us> skribis:

> On Mon, 23 Jun 2014, Ludovic Courtès wrote:
>
>> Hello,
>>
>> The patch below changes occurrences of ‘/usr/bin/file’ to just ‘file’.
>>
>> The impetus is that on systems using GNU Guix, NixOS, GoboLinux, and
>> others, the ‘file’ command is not available as /usr/bin/file, so it must
>> instead be taken from $PATH.
>>
>> (I conservatively left ‘/usr/bin/file’ for more centralized systems such
>> as BSD, IRIX, etc. where it’s more likely to be a valid command.)
>
> Were you able to re-test on all of the impacted platforms?

No, but that list is verrry long.

> The reason for the hard-coded path is because there are a number of
> different 'file' programs and libtool expects particular output from
> the 'file' program that it uses.  If the 'file' encountered via PATH
> is not the same as the common one available as ‘/usr/bin/file’ on GNU
> systems, then there would be a problem.

Well, the systems I was referring to are GNU systems too.  ;-)

Do you remember what other ‘file’ programs could interfere?  Debian has
only one ‘file’ program, for instance:
<https://packages.debian.org/search?searchon=contents&keywords=file&mode=exactfilename&suite=stable&arch=any>.

Besides, relying on file names to identify programs seems fragile: just
like I can have an unrelated ‘file’ command in $PATH, I can install an
unrelated ‘file’ command in /usr/bin.

If there’s a concrete risk of confusion with a same-named program,
perhaps the most robust thing to do would be to try, say, ‘file
--version’ and search for some distinguishing pattern in the output.

WDYT?

Thanks,
Ludo’.

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

From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Mark H Weaver <mhw <at> netris.org>, bug-libtool <at> gnu.org, 17840 <at> debbugs.gnu.org
Subject: Re: bug#17840: [PATCH] libtool: Use 'file' instead of '/usr/bin/file'
 on GNU systems.
Date: Tue, 24 Jun 2014 11:28:25 -0500 (CDT)

[Message part 1 (text/plain, inline)]

On Tue, 24 Jun 2014, Ludovic Courtès wrote:
>
>> The reason for the hard-coded path is because there are a number of
>> different 'file' programs and libtool expects particular output from
>> the 'file' program that it uses.  If the 'file' encountered via PATH
>> is not the same as the common one available as ‘/usr/bin/file’ on GNU
>> systems, then there would be a problem.
>
> Well, the systems I was referring to are GNU systems too.  ;-)
>
> Do you remember what other ‘file’ programs could interfere?  Debian has
> only one ‘file’ program, for instance:
> <https://packages.debian.org/search?searchon=contents&keywords=file&mode=exactfilename&suite=stable&arch=any>.

This is the web page for the most popular and common 'file' command. 
It is not a GNU program:

	http://darwinsys.com/file/

> Besides, relying on file names to identify programs seems fragile: just
> like I can have an unrelated ‘file’ command in $PATH, I can install an
> unrelated ‘file’ command in /usr/bin.

Yes, it is fragile but it is more likely to encounter a wrong program 
named 'file' in the path than to encounter a wrong /usr/bin/file 
program.

> If there’s a concrete risk of confusion with a same-named program,
> perhaps the most robust thing to do would be to try, say, ‘file
> --version’ and search for some distinguishing pattern in the output.

What would we do if 'file' did not respond appropriately to a 
--version argument?

A simple approach would be to use /usr/bin/file if is available, or 
otherwise use the first 'file' found in the executable search path. 
This avoids the need for re-testing on exotic systems and does not 
substantially increase the level of risk.

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

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

From: Ralf Corsepius <rc040203 <at> freenet.de>
To: bug-libtool <at> gnu.org
Subject: Re: bug#17840: [PATCH] libtool: Use 'file' instead of '/usr/bin/file'
 on GNU systems.
Date: Tue, 24 Jun 2014 18:08:00 +0200

On 06/24/2014 04:37 PM, Ludovic Courtès wrote:
> Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us> skribis:
>
>> On Mon, 23 Jun 2014, Ludovic Courtès wrote:
>>
>>> Hello,
>>>
>>> The patch below changes occurrences of ‘/usr/bin/file’ to just ‘file’.
>>>
>>> The impetus is that on systems using GNU Guix, NixOS, GoboLinux, and
>>> others, the ‘file’ command is not available as /usr/bin/file, so it must
>>> instead be taken from $PATH.
>>>
>>> (I conservatively left ‘/usr/bin/file’ for more centralized systems such
>>> as BSD, IRIX, etc. where it’s more likely to be a valid command.)
>>
>> Were you able to re-test on all of the impacted platforms?
>
> No, but that list is verrry long.

Makes me wonder, why this issue has not come up before and what your 
issue actually is.

>> The reason for the hard-coded path is because there are a number of
>> different 'file' programs and libtool expects particular output from
>> the 'file' program that it uses.  If the 'file' encountered via PATH
>> is not the same as the common one available as ‘/usr/bin/file’ on GNU
>> systems, then there would be a problem.
>
> Well, the systems I was referring to are GNU systems too.  ;-)
>
> Do you remember what other ‘file’ programs could interfere?

Any arbitrary "file" a user may have on $PATH.

Actually, in Fedora's packaging, we generally prefer absolute paths over 
plain "file names", to avoid malfunctions from arbitrary stuff people 
may have laying around on $PATH.

> Besides, relying on file names to identify programs seems fragile:
Correct. Trying to utilize "file"'s output to distinguish file types has 
a long history of breaking things and not being robust.

Ralf

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

From: ludo <at> gnu.org (Ludovic Courtès)
To: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
Cc: Mark H Weaver <mhw <at> netris.org>, bug-libtool <at> gnu.org, 17840 <at> debbugs.gnu.org
Subject: Re: bug#17840: [PATCH] libtool: Use 'file' instead of '/usr/bin/file'
 on GNU systems.
Date: Tue, 24 Jun 2014 21:34:06 +0200

Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us> skribis:

> On Tue, 24 Jun 2014, Ludovic Courtès wrote:
>>
>>> The reason for the hard-coded path is because there are a number of
>>> different 'file' programs and libtool expects particular output from
>>> the 'file' program that it uses.  If the 'file' encountered via PATH
>>> is not the same as the common one available as ‘/usr/bin/file’ on GNU
>>> systems, then there would be a problem.
>>
>> Well, the systems I was referring to are GNU systems too.  ;-)
>>
>> Do you remember what other ‘file’ programs could interfere?  Debian has
>> only one ‘file’ program, for instance:
>> <https://packages.debian.org/search?searchon=contents&keywords=file&mode=exactfilename&suite=stable&arch=any>.
>
> This is the web page for the most popular and common 'file'
> command. It is not a GNU program:
>
> 	http://darwinsys.com/file/

Right.  I was asking about hypothetical unrelated ‘file’ commands that
would justify hard-coding /usr/bin/file.

Do we know of any?

Otherwise it’s no different from cat, touch, grep, etc.

Ludo’.

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

From: Peter Rosin <peda <at> lysator.liu.se>
To: Ralf Corsepius <rc040203 <at> freenet.de>, 17840 <at> debbugs.gnu.org
Subject: Re: bug#17840: [PATCH] libtool: Use 'file' instead of '/usr/bin/file'
 on GNU systems.
Date: Tue, 24 Jun 2014 22:35:24 +0200

On 2014-06-24 18:08, Ralf Corsepius wrote:
> On 06/24/2014 04:37 PM, Ludovic Courtès wrote:
>> Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us> skribis:
>>
>>> On Mon, 23 Jun 2014, Ludovic Courtès wrote:
>>>
>>>> Hello,
>>>>
>>>> The patch below changes occurrences of ‘/usr/bin/file’ to just ‘file’.
>>>>
>>>> The impetus is that on systems using GNU Guix, NixOS, GoboLinux, and
>>>> others, the ‘file’ command is not available as /usr/bin/file, so it must
>>>> instead be taken from $PATH.
>>>>
>>>> (I conservatively left ‘/usr/bin/file’ for more centralized systems such
>>>> as BSD, IRIX, etc. where it’s more likely to be a valid command.)
>>>
>>> Were you able to re-test on all of the impacted platforms?
>>
>> No, but that list is verrry long.
> 
> Makes me wonder, why this issue has not come up before and what your issue actually is.

I suspect this has something to do with merging /usr/bin and /bin coupled
with some purist attempt to get rid of the compatibility symlink from one
to the other.

But that's just a guess.

Cheers,
Peter

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Peter Rosin <peda <at> lysator.liu.se>
Cc: Ralf Corsepius <rc040203 <at> freenet.de>, 17840 <at> debbugs.gnu.org
Subject: Re: bug#17840: [PATCH] libtool: Use 'file' instead of
 '/usr/bin/file' on GNU systems.
Date: Wed, 16 Jun 2021 16:16:03 -0400

Hello,

Peter Rosin <peda <at> lysator.liu.se> writes:

> On 2014-06-24 18:08, Ralf Corsepius wrote:
>> On 06/24/2014 04:37 PM, Ludovic Courtès wrote:
>>> Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us> skribis:
>>>
>>>> On Mon, 23 Jun 2014, Ludovic Courtès wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> The patch below changes occurrences of ‘/usr/bin/file’ to just ‘file’.
>>>>>
>>>>> The impetus is that on systems using GNU Guix, NixOS, GoboLinux, and
>>>>> others, the ‘file’ command is not available as /usr/bin/file, so it must
>>>>> instead be taken from $PATH.
>>>>>
>>>>> (I conservatively left ‘/usr/bin/file’ for more centralized systems such
>>>>> as BSD, IRIX, etc. where it’s more likely to be a valid command.)
>>>>
>>>> Were you able to re-test on all of the impacted platforms?
>>>
>>> No, but that list is verrry long.
>> 
>> Makes me wonder, why this issue has not come up before and what your issue actually is.
>
> I suspect this has something to do with merging /usr/bin and /bin coupled
> with some purist attempt to get rid of the compatibility symlink from one
> to the other.
>
> But that's just a guess.

Ludovic being the creator of GNU Guix, a functional package
manager/distribution, I rather suspect that it comes from the fact that
Guix does not follow the Linux Foundation's File Hierarchy Standard (for
a good reason -- to be able to refer to each input unambiguously based
on their corresponding hash).  On those systems, the only sane way to
find commands is to use the PATH.

HTH,

Maxim

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
Cc: mhw <at> netris.org, Ludovic Courtès <ludo <at> gnu.org>,
 17840 <at> debbugs.gnu.org
Subject: Re: bug#17840: [PATCH] libtool: Use 'file' instead of
 '/usr/bin/file' on GNU systems.
Date: Wed, 16 Jun 2021 16:25:53 -0400

Hi,

Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us> writes:

> On Tue, 24 Jun 2014, Ludovic Courtès wrote:
>>
>>> The reason for the hard-coded path is because there are a number of
>>> different 'file' programs and libtool expects particular output from
>>> the 'file' program that it uses.  If the 'file' encountered via PATH
>>> is not the same as the common one available as ‘/usr/bin/file’ on GNU
>>> systems, then there would be a problem.
>>
>> Well, the systems I was referring to are GNU systems too.  ;-)
>>
>> Do you remember what other ‘file’ programs could interfere?  Debian has
>> only one ‘file’ program, for instance:
>> <https://packages.debian.org/search?searchon=contents&keywords=file&mode=exactfilename&suite=stable&arch=any>.
>
> This is the web page for the most popular and common 'file'
> command. It is not a GNU program:
>
> 	http://darwinsys.com/file/
>
>> Besides, relying on file names to identify programs seems fragile: just
>> like I can have an unrelated ‘file’ command in $PATH, I can install an
>> unrelated ‘file’ command in /usr/bin.
>
> Yes, it is fragile but it is more likely to encounter a wrong program
> named 'file' in the path than to encounter a wrong /usr/bin/file
> program.
>
>> If there’s a concrete risk of confusion with a same-named program,
>> perhaps the most robust thing to do would be to try, say, ‘file
>> --version’ and search for some distinguishing pattern in the output.
>
> What would we do if 'file' did not respond appropriately to a
> --version argument?

It seems to me that we are looking farther than needed; unless we have
good reasons not to (which we do not seem to have), it seems reasonable
to assume 'file' to be correctly working; if the user install a 'file'
command on their PATH which behaves differently than the traditional
'file' utility, they can only blame themselves for problems.

> A simple approach would be to use /usr/bin/file if is available, or
> otherwise use the first 'file' found in the executable search path.
> This avoids the need for re-testing on exotic systems and does not
> substantially increase the level of risk.

For the non-FHS package managers such as Guix/Nix, that are able to run
on top of any GNU/Linux distribution, that would be sub-optimal as the
command would be used from the host instead of from the user's PATH;
e.g. if you 'guix install file', file wouldn't be used from Guix but
from the host distribution instead.

I hope that helps to understand the rationale for behind preferring PATH
to hard coded locations.

Maxim

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

From: Felix Lechner <felix.lechner <at> lease-up.com>
To: 17840 <at> debbugs.gnu.org
Cc: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, Mark H Weaver <mhw <at> netris.org>,
 Ludovic Courtès <ludo <at> gnu.org>,
 Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>, bug-libtool <at> gnu.org,
 Ralf Corsepius <rc040203 <at> freenet.de>, Peter Rosin <peda <at> lysator.liu.se>
Subject: Re: bug#17840: [PATCH] libtool: Use 'file' instead of '/usr/bin/file'
 on GNU systems.
Date: Wed, 28 Sep 2022 06:34:14 -0700

Hi,

> there are a number of different 'file' programs and libtool expects
> particular output from the 'file' program that it uses.

I only have one kind of 'file' program installed, and Libtool cannot find it.

Developing on Guix—which is a GNU project like Libtool—I hope to
migrate the authentication logic in Linux PAM to Guile (another GNU
project). I presently use Autotools and Libtool. [1] When running
'./configure' I get the error:

    ./configure: line 6750: /usr/bin/file: No such file or directory

As you can see at the bottom of this message, the issue probably
originated in Libtool, at least in part. With the help of a friend, I
found this bug.

While './configure' continues after the error, my appetite for
warnings is low due to the potential security implications of my work.

> If the 'file' encountered via PATH
> is not the same as the common one available as ‘/usr/bin/file’ on GNU
> systems, then there would be a problem.

That is a hypothetical. I have a real problem—for some value of
$problem. More significantly the hypothetical is my problem, and mine
alone.

If I were to use another implementation of the 'file' program,
/usr/bin/file would probably point to it. The use of the absolute path
does not ensure the program is the one Libtool expects. Moreover, it
falls outside the responsibilities of the Libtool maintainers to
curate my namespace of available executables. That is the domain of
distributions and system administrators. While the concern is valid,
it is not Libtool's problem.

As a side note, the positions here in favor of the absolute path
/usr/bin/file are only half correct. In Guix, we unequivocally believe
in absolute path names, perhaps more than most. The absolute
references allow us to have multiple versions of the same program
co-installed and available at the same time. Fans of /usr/bin/file are
encouraged to explore Guix. [2] You may find happiness!

Thank you for maintaining Libtool, an old and trusted friend!

Kind regards
Felix Lechner

[1] https://codeberg.org/lechner/guile-pam
[2] https://guix.gnu.org/

* * *

$ guix shell --development --file=guix.scm --check
$ autoreconf -fi
$ fgrep /usr/bin/file configure
  lt_cv_file_magic_cmd='/usr/bin/file -L'
      lt_cv_file_magic_cmd=/usr/bin/file
  lt_cv_file_magic_cmd=/usr/bin/file
  lt_cv_file_magic_cmd=/usr/bin/file
    case `/usr/bin/file conftest.$ac_objext` in
      case `/usr/bin/file conftest.$ac_objext` in
      case `/usr/bin/file conftest.$ac_objext` in
    case `/usr/bin/file conftest.$ac_objext` in
    case `/usr/bin/file conftest.$ac_objext` in
    case `/usr/bin/file conftest.$ac_objext` in
    case `/usr/bin/file conftest.o` in
        case `/usr/bin/file conftest.o` in
    case `/usr/bin/file conftest.o` in
$ fgrep -n usr/bin -r
/gnu/store/81n58x4293zwhvydzvvnypcz7y59jqmx-libtool-2.4.6/share/aclocal/libtool.m4
1295:    case `/usr/bin/file conftest.$ac_objext` in
1312:      case `/usr/bin/file conftest.$ac_objext` in
1324:      case `/usr/bin/file conftest.$ac_objext` in
1346:    case `/usr/bin/file conftest.$ac_objext` in
1354:    case `/usr/bin/file conftest.$ac_objext` in
1362:    case `/usr/bin/file conftest.$ac_objext` in
1382:    case `/usr/bin/file conftest.o` in
1389:    case `/usr/bin/file conftest.o` in
1457:    case `/usr/bin/file conftest.o` in
2661:  if test -x /usr/bin/objformat; then
2662:    objformat=`/usr/bin/objformat`
3226:[_LT_PATH_TOOL_PREFIX(${ac_tool_prefix}file, /usr/bin$PATH_SEPARATOR$PATH)
3229:    _LT_PATH_TOOL_PREFIX(file, /usr/bin$PATH_SEPARATOR$PATH)
3457:  lt_cv_file_magic_cmd='/usr/bin/file -L'
3498:      lt_cv_file_magic_cmd=/usr/bin/file
3512:  lt_cv_file_magic_cmd=/usr/bin/file
3559:  lt_cv_file_magic_cmd=/usr/bin/file

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

From: Sam James <sam <at> gentoo.org>
To: Felix Lechner <felix.lechner <at> lease-up.com>
Cc: peda <at> lysator.liu.se, maxim.cournoyer <at> gmail.com, mhw <at> netris.org,
 ludo <at> gnu.org, rc040203 <at> freenet.de, bfriesen <at> simple.dallas.tx.us,
 17840 <at> debbugs.gnu.org
Subject: Re: bug#17840: [PATCH] libtool: Use 'file' instead of '/usr/bin/file'
 on GNU systems.
Date: Wed, 28 Sep 2022 21:29:01 +0100

[Message part 1 (text/plain, inline)]

> On 28 Sep 2022, at 14:34, Felix Lechner via Bug-libtool via Bug reports for the GNU libtool shared library maintenance tool <bug-libtool <at> gnu.org> wrote:
> 
> Hi,
> 
>> there are a number of different 'file' programs and libtool expects
>> particular output from the 'file' program that it uses.
> 
> I only have one kind of 'file' program installed, and Libtool cannot find it.
> 
> Developing on Guix—which is a GNU project like Libtool—I hope to
> migrate the authentication logic in Linux PAM to Guile (another GNU
> project). I presently use Autotools and Libtool. [1] When running
> './configure' I get the error:
> 
>    ./configure: line 6750: /usr/bin/file: No such file or directory

Which version of libtool? Can you share the header of the configure script too?

See also https://git.savannah.gnu.org/cgit/libtool.git/commit/?id=da2e352735722917bf0786284411262195a6a3f6
which landed in 2.4.7. Note that configure scripts must be regenerated using a newer libtool to use this.

(See also the far older https://lists.gnu.org/archive/html/bug-libtool/2014-06/msg00005.html but I don't
think that landed at a very quick glance).

Best,
sam

[signature.asc (application/pgp-signature, attachment)]

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Sam James <sam <at> gentoo.org>
Cc: peda <at> lysator.liu.se, mhw <at> netris.org, ludo <at> gnu.org, rc040203 <at> freenet.de,
 Felix Lechner <felix.lechner <at> lease-up.com>, bfriesen <at> simple.dallas.tx.us,
 17840 <at> debbugs.gnu.org
Subject: Re: bug#17840: [PATCH] libtool: Use 'file' instead of
 '/usr/bin/file' on GNU systems.
Date: Wed, 28 Sep 2022 21:26:37 -0400

Hello Sam,

Sam James <sam <at> gentoo.org> writes:

>> On 28 Sep 2022, at 14:34, Felix Lechner via Bug-libtool via Bug reports for the GNU libtool shared library maintenance tool <bug-libtool <at> gnu.org> wrote:
>> 
>> Hi,
>> 
>>> there are a number of different 'file' programs and libtool expects
>>> particular output from the 'file' program that it uses.
>> 
>> I only have one kind of 'file' program installed, and Libtool cannot find it.
>> 
>> Developing on Guix—which is a GNU project like Libtool—I hope to
>> migrate the authentication logic in Linux PAM to Guile (another GNU
>> project). I presently use Autotools and Libtool. [1] When running
>> './configure' I get the error:
>> 
>>    ./configure: line 6750: /usr/bin/file: No such file or directory
>
> Which version of libtool? Can you share the header of the configure script too?
>
> See also https://git.savannah.gnu.org/cgit/libtool.git/commit/?id=da2e352735722917bf0786284411262195a6a3f6
> which landed in 2.4.7. Note that configure scripts must be regenerated using a newer libtool to use this.

I don't have a reproducer handy, but we'll soon see if it works with
2.4.7; the patch linked suggests it should!  We have 2.4.7 lined up for
the next rebuild cycle in Guix.

Thanks for sharing, that's great news!

-- 
Maxim

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

From: Felix Lechner <felix.lechner <at> lease-up.com>
To: 17840 <at> debbugs.gnu.org
Cc: Peter Rosin <peda <at> lysator.liu.se>,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, Mark H Weaver <mhw <at> netris.org>,
 Ludovic Courtès <ludo <at> gnu.org>, Sam James <sam <at> gentoo.org>,
 Ralf Corsepius <rc040203 <at> freenet.de>,
 Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
Subject: Re: bug#17840: [PATCH] libtool: Use 'file' instead of '/usr/bin/file'
 on GNU systems.
Date: Wed, 28 Sep 2022 20:48:10 -0700

Hi Sam,

On Wed, Sep 28, 2022 at 1:29 PM Sam James <sam <at> gentoo.org> wrote:
>
> See also https://git.savannah.gnu.org/cgit/libtool.git/commit/?id=da2e352735722917bf0786284411262195a6a3f6
> which landed in 2.4.7.

Yay! With version 2.4.7, the warning disappeared. Instead, I see:

  checking for file... file

> Can you share the header of the configure script too?

I browsed around but could find nothing of interest to you. Please
feel free to write if you still need more information.

Thank you so much for your fast reply!

Kind regards
Felix Lechner

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

From: Sam James <sam <at> gentoo.org>
To: Felix Lechner <felix.lechner <at> lease-up.com>
Cc: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>,
 Peter Rosin <peda <at> lysator.liu.se>,
 Ludovic Courtès <ludo <at> gnu.org>,
 Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>,
 Ralf Corsepius <rc040203 <at> freenet.de>, Mark H Weaver <mhw <at> netris.org>,
 17840 <at> debbugs.gnu.org
Subject: Re: bug#17840: [PATCH] libtool: Use 'file' instead of '/usr/bin/file'
 on GNU systems.
Date: Thu, 29 Sep 2022 20:55:56 +0100

[Message part 1 (text/plain, inline)]

> On 29 Sep 2022, at 04:48, Felix Lechner via Bug-libtool via Bug reports for the GNU libtool shared library maintenance tool <bug-libtool <at> gnu.org> wrote:
> 
> Hi Sam,
> 
> On Wed, Sep 28, 2022 at 1:29 PM Sam James <sam <at> gentoo.org> wrote:
>> 
>> See also https://git.savannah.gnu.org/cgit/libtool.git/commit/?id=da2e352735722917bf0786284411262195a6a3f6
>> which landed in 2.4.7.
> 
> Yay! With version 2.4.7, the warning disappeared. Instead, I see:
> 
>  checking for file... file
> 
>> Can you share the header of the configure script too?
> 
> I browsed around but could find nothing of interest to you. Please
> feel free to write if you still need more information.
> 

If it works, then no need at all! Fantastic to hear! :)

> Thank you so much for your fast reply!

No worries and happy compiling!

Best,
sam

[signature.asc (application/pgp-signature, attachment)]

Previous Next

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