On Debian and derivatives, the package you’re looking for is gcc-arm-none-eabi:

apt install gcc-arm-none-eabi

To find this out yourself in future, install apt-file, update your indexes and use it to search for commands:

apt install apt-file
apt-file update
apt-file search bin/arm-none-eabi-gcc

(I have the same confusion. And I try to answer it based on my investigation/understanding.)

Possible Naming Schema

According to quote from ARM GNU Toolchain Downloads page, bare metal and Linux are two different targets. And to differentiate from the target architecture, I call it target environment. And my way to tell it is: if it has "linux" in the name, it targets Linux environment, otherwise bare metal.

Available for bare-metal and Linux targets

So I interpret the toolchain names with below schema:

...<host_arch>-<target_arch>-<vendor>-<target_env+abi>

1. Host OS: on what OS the toolchain itself runs. This is not part of the name but listed in the toolchain download page.

2. Host Arch: on what machine architecture the toolchain itself runs.

3. Target Arch: What machine architecture the toolchain's output targets.

4. Vendor: Who offers the toolchain.

5. Target Environment: can be bare metal or GNU/Linux.

6. ABI: things like call conventions for assembly functions. This is related to both architecture and OS (link). So far I have seen: eabi/elf/linux-gnu/linux-gnueabi

About the "target_env+abi" part

I think this is the most confusing part. ABI is related to machine architecture, OS and language (link). And I think below naming convention holds based on the both the Target Arch + Target Environment.

1. For AArch32 + bare metal, use "eabi".

2. For AArch64 + bare metal, use "elf". (similar to eabi)

3. For AArch32 + Linux/GNU, use "linux-gnueabi" (eabi generated by gcc)

4. For AArch64 + Linux/GNU, use "linux-gnu" (maybe similar to 3 just like 2 to 1)

So I think all 4 of them are about EABI. But may have some subtle differences.

Hope some guru can shed some light here.

Examples

Let's take some toolchain names from the ARM GNU Toolchain Downloads page as examples.

Example 1:
arm-gnu-toolchain-14.2.rel1-mingw-w64-i686-arm-none-eabi.zip

1. Host Arch = x86-64 because of the "mingw-w64-i686"

2. Host OS = Windows because listed so.

3. Target Arch = AArch32 because of the arm.

4. Target Environment = bare metal because no linux in the name.

5. Vendor: by open-source community, no specific vendor so it is none.

6. ABI = eabi

Example 2:
arm-gnu-toolchain-14.2.rel1-mingw-w64-i686-arm-none-linux-gnueabihf.zip

1. Host Arch = x86-64 because of the "mingw-w64-i686"

2. Host OS = Windows because listed so.

3. Target Arch = AArch32 because of the arm.

4. Target Environment = GNU Linux because of the "linux" in the name.

5. Vendor: by open-source community, no specific vendor so it is none.

6. ABI = linux-gnueabi

Example 3:
arm-gnu-toolchain-14.2.rel1-mingw-w64-i686-aarch64-none-elf.zip

1. Host Arch = x86-64 because of the "mingw-w64-i686"

2. Host OS = Windows because listed so.

3. Target Arch = AArch64 because of the "aarch64".

4. Target Environment = bare metal because no linux in the name.

5. Vendor: by open-source community, no specific vendor so it is none.

6. ABI = elf

Example 4:
arm-gnu-toolchain-14.2.rel1-x86_64-arm-none-eabi.tar.xz

1. Host Arch = x86-64 because of the "x86_64"

2. Host OS = Linux because listed so.

3. Target Arch = AArch32 because of the "arm".

4. Target Environment = bare metal because no linux in the name.

5. Vendor: by open-source community, no specific vendor so it is none.

6. ABI = eabi

Example 5:
arm-gnu-toolchain-14.2.rel1-aarch64-aarch64-none-linux-gnu.tar.xz

1. Host Arch = AArch64 because of the first "aarch64"

2. Host OS = Linux because listed in Linux-hosted section

3. Target Arch = AArch64 because of the second "aarch64".

4. Target Environment = GNU Linux because of the "linux" in the name.

5. Vendor: by open-source community, no specific vendor so it is none.

6. ABI = linux-gnu

To answer the original question

• aarch64-none-elf: is for AArch64 bare metal, vendor is none

• arm-none-eabi: is for AArch32 bare metal, vendor is none

TL; DR

Have a try at setting SET(APPLE FALSE).

I've encountered a similar problem when cross-compiling a RISC-V project on my MacBook with macOS Sonoma. I found that CMake will set -arch arm64 by default, and there is an option controlling the argument to -arch called CMAKE_OSX_ARCHITECTURES. However, setting this argument to false does not help since CMake still applies a default value of arm64 which is the architecture of the build host.

I'm rather curious about why there's not much information about this question on the Internet; both on StackOverflow and GitHub are some questions/issues on this problem but no one gave a sharp and clear answer, at least none solved my issue.

So, I dived into the source code of CMake and found that if the target is set as Apple platforms, there will be a hardcoded appending to the compilation flags, which caused this problem. Finally, we can avoid this by setting APPLE variable to false, effectively simulating building on other platforms if you do not need to build a universal package which is almost always the case today.