mainAutoconf - Support: sr #110360, AC_CANONICAL_HOST sets wrong...

 
 

sr #110360: AC_CANONICAL_HOST sets wrong $host_cpu on Raspberry Pi 3

Submitter:  Karl Berry <karl>
Submitted:  Tue 03 Nov 2020 10:27:50 PM UTC
   
 
Priority:  * 5 - Unprioritized Severity:  3 - Normal
Status:  Not Autoconf Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 09 Nov 2020 06:33:59 PM UTC, comment #11: 

Despite the name, $host_cpu has always held a value more like the architecture rather than the exact CPU.  Anyway, autoconf just passes through what config.guess prints -- changing "armv7l" to "armcortex-aXX" (for instance) will need to be taken up with the mailing list -email is unavailable- (see https://savannah.gnu.org/projects/config ).

> what is the recommended way to get a value for -mcpu in the GNU Toolchain?


We don't have a good answer to that question for cross-compilation right now.  I'd recommend discussing that with the GCC development list (gcc@gcc.gnu.org) and getting their agreement first, then coming back to Autoconf if any changes are needed here.

I don't think there's any further action for us to take in Autoconf right now so I'm going to close this bug report.

Zack Weinberg <zackw>
Group administrator
Sat 07 Nov 2020 12:27:15 PM UTC, comment #10: 

@Zack: you are right, that's a cleaner solution. I will do it like that, Thank you very much :-)

Looking at https://en.wikipedia.org/wiki/ARM_Cortex-A and https://en.wikipedia.org/wiki/ARM_architecture I would say that cortex-a53 is a CPU (so should be admissible as value for $host_cpu) while armv7l is an architecture and should not be an admissible value for $host_*cpu*.
armcortex-aXX or arm7cortex-aXX might be a compromise to not break scripts that check for arm*
But that would have to be agreed on with the gcc folks, cf. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70210

If $host_cpu isn't supposed to hold a fitting value for -mcpu, then what is the recommended way to get a value for -mcpu in the GNU Toolchain? I don't think that an application programmer should have to deal with that question.

Viktor Engelmann <algorithman>
Wed 04 Nov 2020 03:59:38 PM UTC, comment #9: 

I looked over spinhawk/configure.ac and I can now say with confidence that you shouldn't override $host_cpu.  "armv7l" is not incorrect, just not recognized as a -march= argument by GCC; changing it to start with "cortex" will cause a whole bunch of "case $host_cpu in" blocks later in the configure script to make the wrong choice.

I think the proper fix is for the code that sets $hc_cv_optimization_flags (e.g. https://github.com/rbowler/spinhawk/blob/master/configure.ac#L1909)...


    case "$host_cpu-$GCC" in
...
        xscale-yes|arm*-yes)

            hc_cv_is_intel_x86_arch=no
            hc_cv_optimization_flags="$hc_cv_optimization_flags -mcpu=$host_cpu -mtune=$host_cpu -frename-registers"
            ;;


to become aware that the value of $host_cpu is not necessarily usable as the argument to either -mcpu= or -mtune=.  What I would recommend is for this entire mess to be replaced with `-O2 -march=native -mtune=native` in native compilation.  Cross compilation could continue to use $host_cpu as the default, but a command-line option should be added (using AC_ARG_WITH) that lets people set it to whatever specific thing they want.

I think this is not a bug in autoconf or automake, and should be re-filed as a bug on spinhawk.  Viktor, it's probably best if you do that, but feel free to cc: me on it (my Github handle is @zackw).

Zack Weinberg <zackw>
Group administrator
Wed 04 Nov 2020 03:35:50 PM UTC, comment #8: 

comment #7:

> The CPU names never contain underscores, do they?

No, there are CPUs containing an underscore.

Jannick <jannick>
Wed 04 Nov 2020 03:03:58 PM UTC, comment #7: 

It works on both models with

host_cpu=$(LANG=en_US lscpu | grep 'Model name' | cut -d: -f2 | tr '[:upper:]' '[:lower:]')

I'm thinking about how you would cross-compile to Raspberry... you'd have to set a --host, but couldn't set that to cortex-aXX. The CPU names never contain underscores, do they? So you could specify --host=cortex_a53-os-abi or return cortex_a53-os-abi from config.guess and sed s/_/-/g that somewhere in AC_CANONICAL_HOST...

Viktor Engelmann <algorithman>
Wed 04 Nov 2020 02:30:48 PM UTC, comment #6: 

I have tested the most recent config.guess and config.sub on a Raspberry Pi 4 now - and I see "armv7l" there, too. That is a Cortex-A73, though.

Yes, I think $host_cpu is passed to -mcpu at least if it starts with "arm". It's this project:
https://github.com/rbowler/spinhawk/pull/96

I have the x-trick right in the configure.ac - I just mistyped it when I put it here. Sorry for the noise.

Viktor Engelmann <algorithman>
Wed 04 Nov 2020 02:05:18 PM UTC, comment #5: 

Yeah, I don't think there will ever be an official CPU-COMPANY-SYSTEM triplet where CPU contains a dash.  That would break far too many existing parsers.  Also, there are dozens of programs out there that expect $host_cpu to start with "arm" for all ARM32 CPUs; "cortex-a53" doesn't fit that pattern.

Do I understand correctly that this package assumes that $host_cpu will always be directly usable as the argument to GCC's `-march=` switch?  If so, I think that's a bug in the package.  GCC has never guaranteed that that will work, as far as I know.

> AS_IF([test "x$host_cpu" = 'armv7l'],[host_cpu=cortex-a53])


  • This should be `test "x$host_cpu" = xarmv7l`; the x-trick requires a leading x on both operands to the comparison.
    • In this case you don't need the x-trick, you can use `test "$host_cpu" = armv7l`. After AC_CANONICAL_HOST, $host_cpu is guaranteed to be nonempty, and not to start with a dash.
  • Not all "armv7l" CPUs are Cortex-A53s.  You might need to parse the output of `lscpu` yourself here.


If you tell me which package this is, I might be able to make some more specific suggestions.

Zack Weinberg <zackw>
Group administrator
Wed 04 Nov 2020 01:27:52 PM UTC, comment #4: 

@Jannick
Thanks! I didn't want to pass a --host, because that would break cross-platform compatibility. So I have put this into configure.ac


> # override host_cpu in in special case (having dash)
> AS_IF([test "x$host_cpu" = 'armv7l'],[host_cpu=cortex-a53])
> AC_SUBST([host_cpu])


That works without setting --host.
Not a perfect solution, but a suitable workaround.

I had tried something like that before, but had used BASH syntax, which hadn't worked.

> @Zack:  Not sure if AC_CONONICAL_HOST and cousins should be prepared to be able to digest also quadruplets config.sub might generate?


As I said, quadruples do produce an error

Viktor Engelmann <algorithman>
Wed 04 Nov 2020 12:27:46 PM UTC, comment #3: 

As of now AC_CANONICAL_HOST, AC_CANONICAL_BUILD and AC_CANONICAL_TARGET expect pure triplets.  The latest config.sub might return a triplet or a quadruplet (see the header of config.sub).  It appears unlikely that a cpu having a dash can meet the 3/4-plet nomenclature requirements in any way.

Victor, this evil hackery might do the job in your case:  Add in configure.ac (right below AC_CANONICAL_HOST)

# override host_cpu in in special case (having dash)
AS_IF([test "x$host_cpu" = 'xcortex_a53'],[host_cpu=cortex-a53])
AC_SUBST([host_cpu])

and smuggle the artificial triplet 'cortex_a53-<vendor>-<os>' (with vendor and os set appropriately) into autoconf like so

./configure --build=cortex_a53-<vendor>-<os>


@Zack:  Not sure if AC_CONONICAL_HOST and cousins should be prepared to be able to digest also quadruplets config.sub might generate?

Jannick <jannick>
Wed 04 Nov 2020 08:43:42 AM UTC, comment #2: 

config.guess prints armv7l-unknown-linux-gnueabihf

I just pulled the most recent versions of config.guess and config.sub to be sure. Same problem.

Not sure how these 2 CAN respond, to get a cpu with a dash through the rest of autoconf...

Viktor Engelmann <algorithman>
Tue 03 Nov 2020 11:50:21 PM UTC, comment #1: 

This is probably a bug in config.sub and config.guess, which would need to be reported to config-patches@gnu.org. To verify this, Viktor, could you please report the output of running config.guess on your Pi3? No arguments are required.

Zack Weinberg <zackw>
Group administrator
Tue 03 Nov 2020 10:27:50 PM UTC, original submission:  

Received this report on Automake:

https://bugs.gnu.org/44422

Maybe it is really for Autoconf?
(I have no clue about arm architecture variants myself.)

I will copy the text here (unfortunately I expect it will be mangled by the web form). The reporter is Viktor Engelmann <viktor.engelmann <at> googlemail.com>.




I'm trying to port a project to docker and I'm also testing it on my
Raspberry Pi 3B+

when I ./configure and make the project, it fails with this message

gcc: error: unrecognized -mcpu target: armv7l
gcc: note: valid arguments are: arm8 arm810 strongarm [...] cortex-a53 [...]
gcc: error: missing argument to '-march='

lscpu says this:

Architecture:        armv7l
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):           1
Vendor ID:           ARM
Model:               4
Model name:          Cortex-A53
Stepping:            r0p4
CPU max MHz:         1200.0000
CPU min MHz:         600.0000
BogoMIPS:            38.40
Flags:               half thumb fastmult vfp edsp neon vfpv3 tls vfpv4
idiva idi
                     vt vfpd32 lpae evtstrm crc32

So it seems to me that AC_CANONICAL_HOST sets $host_cpu to armv7l,
although that is the Architecture and should be passed to -march
instead. -mcpu should get the Model name.

I couldn't get it to accept the --host=cpu-os-abi parameter, because
cortex-a35 contains a dash and that seems to confuse autoconf (that
produces the error message Invalid configuration
`cortex-a53-unknown-linux-gnueabihf': machine `cortex-a53-unknown' not
recognized). I did manage to compile with
--host=native-unknown-linux-gnueabihf, but I'd rather not define a fixed
ABI, because that would break the cross-platform compatibility of the
Dockerfile.

I'm using autoconf 2.69 from the docker base image "ubuntu:latest".

Karl Berry <karl>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #50201:  config.log added by algorithman (299KiB - text/x-log - This is the config.log. Savannah should have a link to the submit-form in the issues list btw.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jannick (Posted a comment)
  • -email is unavailable- added by zackw (Posted a comment)
  • -email is unavailable- added by algorithman (Updated the item)
  • -email is unavailable- added by karl (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 logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-11-09 zackw StatusNone Not Autoconf
        Open/ClosedOpen Closed
    2020-11-03 algorithman Attached File- Added config.log, #50201

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code