bugGNU Octave - Bugs: bug #48710, normalize core and package...

 
 

bug #48710: normalize core and package architecture-dependent installation directories

Submitted by:  Hartmut <hardy>
Submitted on:  Fri 05 Aug 2016 06:56:49 PM UTC  
 
Category: Configuration and Build SystemSeverity: 1 - Wish
Priority: 5 - NormalItem Group: Feature Request
Status: PostponedAssigned to: None
Originator Name: Open/Closed: Open
Release: devOperating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Fri 30 Sep 2016 07:38:57 PM UTC, comment #4:

Ok I'm retitling this appropriately, I think it makes sense for a future release to make the directory components that Octave installs into and uses to be a little more robust and depend only on the minimal information needed to separate one incompatible build from another.

I am motivated to work on this, but it will have to wait until the next release cycle.

Here is a list of installation directory components from the Debian builds of octave for all supported architectures. I chose the same "oct" directory for all builds. The path contains both the Debian multiarch tuple (after "/usr/lib") and the GNU host triplet (after "4.0.3/oct")

I think it's safe to remove the VENDOR part of the GNU triplet, in most cases the path component that we compute from the canonical host identifier will be the same as the Debian multiarch tuple.

The one quirk is ix86, but I think it's fine to continue using i686 as the CPU identifier that config.guess normally returns (or is specified by the user). Debian builds packages with "--build=i686-linux-gnu" and continues to call the architecture i386, just a quirk everyone is used to.

Mike Miller <mtmiller>
Project Administrator
Sat 06 Aug 2016 10:18:06 AM UTC, comment #3:

I like the suggestion to have a more robust "platform string" like "x86_64-linux-gnu", removing the vendor part like "unknown" or "pc". I assume the oct-file subfolder of package installations would then be named "x86_64-linux-gnu-v50+".

The advantages of such a change of "platform string" would be

  • the oct-file subfolder of packages will be FOUND in EVERY case when its binary content CAN technically be used. (same OS, same processor architecture, same oct-file API, ...)
  • the oct-file subfolder will still be NOT FOUND in cases when its binary content is technically UNUSABLE anyway.

The disadvantage of such a change of "platform string" would be

  • There is one more change of platform string, making once again all installed packages unusable after an Octave version update.

Therefore I think the ideal point of time for such a change of "platform string" will be the next major version update of Octave, like the upcoming 4.2 release. After this update, many packages won't be usable without a package update anyways. That might be the point of time when a change of "platform string" will distrurb Octave users the least.

Hartmut <hardy>
Fri 05 Aug 2016 08:14:10 PM UTC, comment #2:

Sorry, that should be "--build=" instead of "--host=" in comment #1.

Mike Miller <mtmiller>
Project Administrator
Fri 05 Aug 2016 08:01:41 PM UTC, 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?

Mike Miller <mtmiller>
Project Administrator
Fri 05 Aug 2016 06:56:49 PM UTC, original submission:

Forge packages that where installed under Octave 4.0.1 aren't fully functional under Octave 4.0.3. The reason seems to be a change in the "configured for" string between those two Octave version. (In my case this was "x86_64-unknown-linux-gnu-api-v50+" and changed to "x86_64-pc-linux-gnu-api-v50+".)

This was observed on a Ubuntu 14.04 linux system, both Octave versions are self compiled from the official release tar-balls.

Here is how to reproduce the behavior, with the example of the image package:
In Octave 4.0.1 do:
This will show the two paths of the image package:

  • ~/octave/image-2.4.1
  • ~/octave/image-2.4.1/x86_64-unknown-linux-gnu-api-v50+

Then in Octave 4.0.3 do:

  • This will only show one of the necessary paths for the image package, the subfolder with the compiled oct-files is missing:
  • ~/octave/image-2.4.1

The reason for this becomes obvious when you continue in Octave 4.0.3:
This will again show the two necessary paths:

  • ~/octave/image-2.4.1
  • ~/octave/image-2.4.1/x86_64-pc-linux-gnu-api-v50+

Note that the name of the oct-file subfolder is now DIFFERENT, it is "pc-linux" instead of "unknown-linux". This seems to be the reason for packages to not work properly under Octave 4.0.3 if they have been installed under Octave 4.0.1 (or earlier).

(Prior to this bug report, this was nailed down during bug #48601.)

This change in this "configured for" string might be an intended change and well known change during the development from Octave 4.0.3 to 4.0.1. But it does have the explained side effects.

I am fully aware of the possibility to "work around" this behavior, by simply re-installing all packages. But this might not be obvious for the other Octave users.

Hartmut <hardy>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by hardy (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 9 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 24 Nov 2016 12:36:56 AM UTCmtmillerDependencies-=>bugs #49213 is dependent
    Fri 30 Sep 2016 07:38:57 PM UTCmtmillerItem GroupIncorrect Result=>Feature Request
      StatusNeed Info=>Postponed
      Release4.0.3=>dev
      Summarychanged config.guess helper script makes installed packages unusable=>normalize core and package architecture-dependent installation directories
    Fri 30 Sep 2016 07:38:56 PM UTCmtmillerSeverity3 - Normal=>1 - Wish
    Fri 05 Aug 2016 08:01:41 PM UTCmtmillerCategoryNone=>Configuration and Build System
      StatusNone=>Need Info
      Summarychanged "configured for" string makes installed packages unusable=>changed config.guess helper script makes installed packages unusable

    Back to the top


    Powered by Savane 3.1-cleanup1