[sr #108605] autoconf mis-detects arch (and other things)

[Eric Blake]

Update of sr #108605 (project autoconf):

  Status:None = Invalid
 Open/Closed:Open = Closed 

___

Follow-up Comment #1:

This part of the configure script is informational; it is trying to print as
many useful things for as many platforms as possible.  It is okay that not all
things work on all platforms; the goal is not that everything works
everywhere, only that at least one thing works on your platform.  As you
pointed out, the log sufficiently diagnoses your architecture via uname
output, even without arch doing what is needed on other platforms where arch
-k works.  Therefore, I don't see this as a bug.

___

Reply to this item at:

  http://savannah.gnu.org/support/?108605

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[sr #108605] autoconf mis-detects arch (and other things)

[anonymous]

URL:
  http://savannah.gnu.org/support/?108605

 Summary: autoconf mis-detects arch (and other things)
 Project: Autoconf
Submitted by: None
Submitted on: Mon 30 Jun 2014 02:02:41 AM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: dshadoww...@gmail.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: GNU/Linux

___

Details:

On, at least, GNU/Linux Mint 17 (and the Ubuntu and Debian versions it
descends from) the 'arch' program is located in /usr/bin and is the GNU
version, which does not accept the '-k' parameter, leaving programs configured
using autoconf claiming 'unknown' for the architecture.

1638:/bin/arch  = `(/bin/arch) 2/dev/null  || echo
unknown`
1639:/usr/bin/arch -k   = `(/usr/bin/arch -k) 2/dev/null   || echo
unknown`

Those line are from the git repository of autoconf and are from lib/m4sh.m4  -
 I have not checked, but it seems, to me, that this is broken. 

In the same file it calls the program 'uname' fine with no path, but when it
looks for the '-p' option, it is written to reference /usr/bin/uname (which
doesn't exist on Mint 17). Then, on the next line, it calls /bin/uname with
the '-X' option, which isn't a valid option for the GNU version of the program
(although it does get the path to the program correct).

(note that '-p' and '-X' do not appear in the SuS, so they are either GNU
extensions or vendor extensions, however...)


This does seem, however, to point to a use of absolute paths where not
necessary (all tools needed to configure/build something should be available
via $PATH) and it might be better if, in some cases, the absolute paths were
not used. (or something like 'locate' or 'which' were used to determine the
location/availability of the command needed)




___

Reply to this item at:

  http://savannah.gnu.org/support/?108605

___
  Message sent via/by Savannah
  http://savannah.gnu.org/