octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #48710] changed config.guess helper script mak


From: Mike Miller
Subject: [Octave-bug-tracker] [bug #48710] changed config.guess helper script makes installed packages unusable
Date: Fri, 5 Aug 2016 20:01:41 +0000 (UTC)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0

Update of bug #48710 (project octave):

                Category:                    None => Configuration and Build
System
                  Status:                    None => Need Info              
                 Summary: changed "configured for" string makes installed
packages unusable => changed config.guess helper script makes installed
packages unusable

    _______________________________________________________

Follow-up Comment #1:

Thanks for helping to identify what's going on here.

The relevant change is the config.guess build helper script that was updated
between version 4.0.2 and 4.0.3. The script was not updated intentionally, the
gnulib repository was updated for other unrelated fixes (bug #48001).

I hadn't noticed this fix because I always build Octave with
--host=x86_64-linux, which bypasses the config.guess script, exactly because I
want a consistent host triplet between successive builds of Octave. It has
always been "x86_64-pc-linux-gnu" for me.

The new version of config.guess and the host triplet "x86_64-pc-linux-gnu" is
what you will probably get going forward, but for best results you should
build Octave with --host if you want to specify exactly what your host triplet
should be and avoid it changing if the logic in the detection script fails.

The only change we could possibly make in Octave would be to construct a
"platform string" that is a condensed version of the GNU standard host
triplet. For example GCC on my system is installed into directories named
"/usr/lib/gcc/x86_64-linux-gnu", without the "vendor" part of the host.

Any other thoughts, or should we close this as won't fix?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?48710>

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




reply via email to

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