bugGNU Octave - Bugs: bug #49213, Please use $host_alias for...

 
 

bug #49213: Please use $host_alias for canonical host (m4/acinclude.m4:2010)

Submitter:  None
Submitted:  Wed 28 Sep 2016 05:35:30 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Duplicate Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 4.0.3
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 24 Nov 2016 12:36:56 AM UTC, comment #5: 

Discussion here has stalled, marking as a duplicate of bug #48710 because it seems related.

If there are still issues here that I am not getting, that would not be resolved by having an installation directory that does not contain the "vendor" part of the host triplet, please comment with more details or what you expect to happen, or file a new bug report.

Mike Miller <mtmiller>
Group Member
Wed 28 Sep 2016 08:36:11 PM UTC, comment #4: 

Well, the script that transforms whatever the user passes with --build or --host is called config.sub. The standard GNU config.sub script translates an OS string of "linux" to "linux-gnu".

I typically build Octave with --build=x86_64-linux, which is canonicalized into a build/host label of "x86_64-pc-linux-gnu".

This is the correct canonical host name and won't be changing unless the relevant upstream projects (autoconf, automake, gnulib, etc) change their naming conventions.

What we might find acceptable, as described on bug #48710, would be to only use the CPU and OS portions of the host label for constructing certain installation paths, so what is now "${prefix}/lib/octave/${version}/oct/x86_64-pc-linux-gnu" might become "${prefix}/lib/octave/${version}/oct/x86_64-linux-gnu".

I still don't see clearly enough what the problem reported here is, so I don't know if this would solve the problem or make it worse or what, but that's the issue discussed in open bug #48710.

Mike Miller <mtmiller>
Group Member
Wed 28 Sep 2016 07:13:01 PM UTC, comment #3: 

Perhaps I understand things a bit better now:

Boring background:
pkgsrc uses a very plain script to discover MACHINE_GNU_PLATFORM:

MACHINE_GNU_PLATFORM?=${MACHINE_GNU_ARCH}-${LOWER_VENDOR}-${LOWER_OPSYS:C/[0-9]//g}${APPEND_ELF}${LOWER_OPSYS_VERSUFFIX}${APPEND_ABI}

config.guess appends -gnu for Debian* machines, we don't distinguish them.

in octave, it seems this string is used as the directory name for some files,
so we end up with a file:
lib/octave/${PKGVERSION}/oct/${MACHINE_GNU_PLATFORM}/ccolamd.oct

Once the build process is done, pkgsrc has an installation process which (I think) forms a package based on files in a package file list, with pathnames of the files to be used.

Because we aim to install for more than one operating system, we use ${MACHINE_GNU_PLATFORM} in this list, rather than a fixed linux-unknown-...-gnu

However, the directory octave used and the directory we expect via our MACHINE_GNU_PLATFORM are different.

I'm not entirely sure why config.guess decides it should guess what $host is, because --host is also passed.

Anonymous
Wed 28 Sep 2016 06:26:33 PM UTC, comment #2: 

Can you please describe what is the concrete problem with the use of the canonical host triplet with "-gnu" suffix? I've read the linked message and I can't see where the specific problem is described. Is it because Octave installs files into directories that contain the canonical host triplet? Something else?

Changing what the definition of the variable canonical_host_type is will surely cause other breakage, so that simple change is not acceptable, but something like what is briefly proposed in bug #48710 would be worth looking into.

Mike Miller <mtmiller>
Group Member
Wed 28 Sep 2016 06:19:00 PM UTC, comment #1: 

see also bug #48710

Hartmut <hardy>
Wed 28 Sep 2016 05:35:30 PM UTC, original submission:  

Hi,

This problem is a little tricky, I'm not sure I understand it fully. However, the requested change is hopefully sane enough anyway.

We have a package for Octave in pkgsrc, and it seems that our build tools expect a pre-defined MACHINE_GNU_PLATFORM to be used in various places.
This is passed value via --build normally, and is defined in configure as $host_alias.

The guess used by Octave differs from what we use, and it caused a very tricky build failure.

for linux, we seem to use x86_64-unknown-linux whereas octave's build guessed x86_64-unknown-linux-gnu.

See the original discussion here:
https://mail-index.netbsd.org/pkgsrc-users/2014/03/26/msg019464.html

I'm not sure what value $host has normally.

Thanks.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by None (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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-11-24 mtmiller StatusNeed Info Duplicate
        Open/ClosedOpen Closed
        Dependencies- Depends on bugs #48710
    2016-09-28 mtmiller StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code