Add arm64 arch option to settings.yml

[krisanovdev]

Problem: For now (Conan 1.9.2) I can't build packages for arm64 architecture (iOS target for example). Here is my profile: `[build_requires] darwin-toolchain/1.0.3@theodelrieu/stable

[settings] os=iOS os.version=11.0 arch=arm64 arch_build=x86_64 os_build=Macos compiler=apple-clang compiler.version=10.0 compiler.libcxx=libc++ build_type=Release`

And obviously there is an error when we try to conan install someconanfile.txt I can say that armv8 is not equivalent to arm64 due to my linking problem.

[Johnnyxy]

Hi there, for compiling for QNX I am using the arch aarch64le and use this as custom arch in my settings.yml. You can modify your settings.yml (see here) and add support for any architectures you like. As this is in reality only a "string" Conan uses.

Just add a new string arm64 and everything will run fine. I would advise you to use an architecture named aarch64 as this is the official name of the ARM 64 Bit architecture (see here, here).

[lasote]

arm64=armv8: https://docs.conan.io/en/latest/reference/config_files/settings.yml.html?highlight=armv8#architectures

[Johnnyxy]

@lasote It is a bit confusing. At the moment I do not have such a problem but I am not sure that the setting "armv8" is sufficient.

The wikipedia article lists serval instruction sets: https://en.wikipedia.org/wiki/ARM_architecture#64/32-bit_architecture

• AArch64
• ARMv8.1-A
• ARMv8.2-A
• ARMv8.3-A
• ARMv8.4-A
• ARMv8.5-A

If someone wants to compile against just an ARM architecture that is generally 64 bit compatible then the choice would be Aarch64. But if someone needs certain features of the instruction set additions then one has to use the newer ones.

I do not have a reliable source (like someone deeply involved in ARM usage) but hopefully someone here could shed some light on this.

EDIT: I found that the architectures list lists armv8.3. This means the others are just missing. But this still would leave a "aarch64" and "aarch32" as general architectures like (Intel/AMD) x86_64 and x86.

[lasote]

Take into account that the default settings.yml file is a classification for general purpose. We are not modeling either sub-architectures of x86_64 or instructions sets.

If you need more specification (because you need to distinguish binaries from different instructions sets) you can modify it as @Johnnyxy suggested, for example adding a new subsetting of arch with the instruction set.

[Johnnyxy]

What I found in ARM docs for Aarch64, Aarch32, A32 and A64: https://developer.arm.com/docs/100076/latest/part-a-instruction-set-overview/overview-of-the-arm-architecture/about-the-arm-architecture

https://developer.arm.com/docs/100076/latest/part-a-instruction-set-overview/overview-of-the-arm-architecture/changing-between-aarch64-and-aarch32-states

[SSE4]

there are multiple names of the same entity, used by various tools, for instance:

• ARMv8-A - seems to be an official name
• ARMv8-R - and another official name
• A64 - name of the instruction set
• just ARMv8 - e.g. used by Xcode or Android NDK, things are mostly used for ARM development these days
• Aarch64 - mostly used by GNU stuff
• ARM64 - cite from debian: 'arm64' is the Debian port name for the 64-bit Armv8 architecture, referred to as 'aarch64' in upstream toolchains (GNU triplet aarch64-linux-gnu), and some other distros. also Microsoft compiler uses this name.

see also: https://lkml.org/lkml/2012/7/15/133

I personally don't think it's worth to rename now, as it would be breaking. you always may rename things in your own settings.yml as you need. and we simply can't satisfy everyone, as various names are used in various places, so it will be always confusing, as there is no standard.

these architecture names often change during the time. e.g. that we currently call x86_64 was initially named by Intel IE32e, then later as EM64T in Intel Manuals, but now it's just an Intel 64 in all Intel Manuals. we might choose either name of previously mentioned, depending on time we introduced it in conan, but all mentioned name are just non-sense for most of people, as almost nobody call it that way nowadays (despite all 3 names are official). other names, like x64, x86_64 or amd64 are equally wide-spread today than official Intel names. same story about x86 - nobody called it x86 at the beginning, as there were no x at the time 8086 arrived. and official name for it is ia32, which is also something less common than informal and well-known i386 or x86 variants.

[Johnnyxy]

I agree that the naming from ARM is not that good. I thought they set sail for a common architecture naming like a basic instruction set (e.g. aarch64) plus additional instructions as extensions (like ARMv8.1) by newer processors.

As I am compiling against ARM I have to use some third party libraries and they are using different names like ARMv8, Aarch64, ... . Now the problem is how can one be sure to compile against the correct architecture? I do not want to compile against a specific CPU/chips. At least a minimal set would be sufficient for me (at the moment).

@SSE4 Thx for the background informations. Just as a side note. ARMv8-A and ARMv8-M are official names but describing different aspects. ARMv8-R and ARMv8-M do not have the 64 bit instructions like ARMv8-A has. For the x86_64 as I understand Intel licensed the 64 Bit instruction set from AMD. In general the 64 bit instructions of Intel and AMD are compatible despite some minor quirks. Thus there are AMD64 and Intel64 instruction set implementations but the compilers know how to deal with the differences as such that we can just use "x86_64" as common ground. I think the "evolution" in the architecture naming that we can finally name it "x86_64" has come a long way.

[SSE4]

I think for now just document in conan docs that armv8 is synonymous for aarch64 / arm64 in conan codebase, or the most common instruction set. if you need something more specific, you need to add your own architectures to the settings.yml (e.g. someone may want to distinguish aarch64le vs aarch64be, for instance), or just micro-architecture sub-settings (things like -mcpu = cortex-a9 or whatever). but for 99% of use-cases, two common of them are iOS and Android cross-compilations, and third-one less wide-spread is Raspberry Pi, these things aren't usually needed, and correct toolchain already ensures you build for the correct CPU. so I don't think it's really needed to be something in default settings.yml. but I might be wrong, if there will be many users requesting/upvoting it, we always can reconsider it.

[newsages]

and settings.arch=multiarch ??? Android and others

[bret-bailey]

if you need something more specific, you need to add your own architectures to the settings.yml

@SSE4 or anyone else, how is this accomplished?

specifically, we're targeting AWS Graviton 3 (InstanceType C7g), which equates to ARMv8.4-a according to their documentation found here: https://github.com/aws/aws-graviton-getting-started

Conan version 1.48.1 output shows the following:

Possible values are ['x86', 'x86_64', 'ppc32be', 'ppc32', 'ppc64le', 'ppc64', 'armv4', 'armv4i', 'armv5el', 'armv5hf', 'armv6', 'armv7', 'armv7hf', 'armv7s', 'armv7k', 'armv8', 'armv8_32', 'armv8.3', 'sparc', 'sparcv9', 'mips', 'mips64', 'avr', 's390', 's390x', 'asm.js', 'wasm', 'sh4le', 'e2k-v2', 'e2k-v3', 'e2k-v4', 'e2k-v5', 'e2k-v6', 'e2k-v7', 'xtensalx6', 'xtensalx106']

I'm happy to add my own architecture to ensure compatibility, but I cannot find any documentation on how to ... any help/direction is appreciated

[SSE4]

@bret-bailey check this out https://docs.conan.io/en/1.50/extending/custom_settings.html

[memsharded]

Closing this ticket as inactive