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

 
 

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

Submitter:  Hartmut <hardy>
Submitted:  Fri 05 Aug 2016 06:56:49 PM UTC
   
 
Category:  Configuration and Build System Severity:  1 - Wish
Priority:  5 - Normal Item Group:  Feature Request
Status:  Postponed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 12 Jan 2019 06:53:55 AM UTC, comment #6: 

No, not for 5. I want to look at this on the default branch.

I've marked as won't fix on the wiki.

 Mike Miller <mtmiller>
Group Member
Sat 12 Jan 2019 12:07:12 AM UTC, comment #5: 

@Mike: You indicated (back in 2016) that you might want to work on this before the next release cycle.  Do you still want to for 5.0, or should I mark it WON'T FIX on the Bug Fix List?

 Rik <rik5>
Group administrator
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")



/usr/lib/  aarch64-linux-gnu        /octave/4.0.3/oct/  aarch64-unknown-linux-gnu
/usr/lib/  alpha-linux-gnu          /octave/4.0.3/oct/  alpha-unknown-linux-gnu
/usr/lib/  arm-linux-gnueabi        /octave/4.0.3/oct/  arm-unknown-linux-gnueabi
/usr/lib/  arm-linux-gnueabihf      /octave/4.0.3/oct/  arm-unknown-linux-gnueabihf
/usr/lib/  hppa-linux-gnu           /octave/4.0.3/oct/  hppa-unknown-linux-gnu
/usr/lib/  i386-gnu                 /octave/4.0.3/oct/  i686-pc-gnu
/usr/lib/  i386-kfreebsd-gnu        /octave/4.0.3/oct/  i686-pc-kfreebsd-gnu
/usr/lib/  i386-linux-gnu           /octave/4.0.3/oct/  i686-pc-linux-gnu
/usr/lib/  mips-linux-gnu           /octave/4.0.3/oct/  mips-unknown-linux-gnu
/usr/lib/  mips64el-linux-gnuabi64  /octave/4.0.3/oct/  mips64el-unknown-linux-gnuabi64
/usr/lib/  mipsel-linux-gnu         /octave/4.0.3/oct/  mipsel-unknown-linux-gnu
/usr/lib/  powerpc-linux-gnu        /octave/4.0.3/oct/  powerpc-unknown-linux-gnu
/usr/lib/  powerpc64-linux-gnu      /octave/4.0.3/oct/  powerpc64-unknown-linux-gnu
/usr/lib/  powerpc64le-linux-gnu    /octave/4.0.3/oct/  powerpc64le-unknown-linux-gnu
/usr/lib/  s390x-linux-gnu          /octave/4.0.3/oct/  s390x-ibm-linux-gnu
/usr/lib/  sparc64-linux-gnu        /octave/4.0.3/oct/  sparc64-unknown-linux-gnu
/usr/lib/  x86_64-kfreebsd-gnu      /octave/4.0.3/oct/  x86_64-pc-kfreebsd-gnu
/usr/lib/  x86_64-linux-gnu         /octave/4.0.3/oct/  x86_64-pc-linux-gnu


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>
Group Member
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>
Group Member
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>
Group Member
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:

pkg uninstall image
pkg install image -forge
pkg load image
path

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:

pkg uninstall image
path

  • 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:

pkg uninstall image
pkg install image -forge
pkg load image
path

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 Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one
bugsPlease use $host_alias for canonical host (m4/acinclude.m4:2010) (bug #49213, Duplicate)

Digest:
   bug dependencies.

 

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

    •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-11-24 mtmiller Dependencies- bugs #49213 is dependent
    2016-09-30 mtmiller Item 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
    2016-09-30 mtmiller Severity3 - Normal 1 - Wish
    2016-08-05 mtmiller CategoryNone Configuration and Build System
        StatusNone Need Info
        Summarychanged &quot;configured for&quot; string makes installed packages unusable changed config.guess helper script makes installed packages unusable

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.14-f13d.
    Corresponding source code