bug-autoconf
[Top][All Lists]
Advanced

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

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


From: anonymous
Subject: [sr #108605] autoconf mis-detects arch (and other things)
Date: Mon, 30 Jun 2014 02:02:42 +0000
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0

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: address@hidden
             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/




reply via email to

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