# Executable not found for macos/clang/M1-arm64 but yes for macos/clang/x86\_64

**URL:** <https://discourse.cmake.org/t/executable-not-found-for-macos-clang-m1-arm64-but-yes-for-macos-clang-x86-64/8235>\
**Category:** Code\
**Created:** [May 30, 2023, 5:06pm UTC](https://discourse.cmake.org/t/executable-not-found-for-macos-clang-m1-arm64-but-yes-for-macos-clang-x86-64/8235 "2023-05-30T17:06:29Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![rturrado](https://discourse.cmake.org/user_avatar/discourse.cmake.org/rturrado/32/3499_2.png) [@rturrado](https://discourse.cmake.org/u/rturrado)\
**Post date:** [May 30, 2023, 5:06pm UTC](https://discourse.cmake.org/t/executable-not-found-for-macos-clang-m1-arm64-but-yes-for-macos-clang-x86-64/8235/1 "2023-05-30T17:06:29Z")

</div>

Hi all,

I’m adding a package to [Conan Center](https://github.com/conan-io/conan-center-index/pull/17719). It builds correctly for `macos/clang/x86_64`, but fails for `macos/clang/M1-arm64`. The error comes from this piece of code:

```auto
cmake_minimum_required(VERSION 3.12 FATAL_ERROR)

add_executable(func-gen "func-gen.cpp")

target_include_directories(func-gen
    PRIVATE "."
    PRIVATE "${CMAKE_CURRENT_BINARY_DIR}"
)

function(generate_funcs HDR SRC VER)
    get_filename_component(HDR_DIR "${HDR}" PATH)
    file(MAKE_DIRECTORY "${HDR_DIR}")

    get_filename_component(SRC_DIR "${SRC}" PATH)
    file(MAKE_DIRECTORY "${SRC_DIR}")

    add_custom_command(
        COMMAND func-gen "${HDR}" "${SRC}" "${VER}"
        OUTPUT "${HDR}" "${SRC}"
        DEPENDS func-gen
    )
endfunction()

```

It basically cannot find `func-gen` during execution (full logs [here](https://c3i.jfrog.io/c3i/misc/logs/pr/17719/15-macos-m1-clang/libqasm/0.5.6//f1a36a2aea2da1148eb4bddd758d8db183c6db83-build.txt)):

```auto
/bin/sh: func-gen: command not found

```

That `generate_funcs` function is called from a parent `CMakeLists.txt`. I’ve tried using a variable:

`set(func-gen-path ${CMAKE_CURRENT_BINARY_DIR}/func-gen PARENT_SCOPE)`

instead of using the name of the target, `func-gen`, directly, and that works for `linux/gcc` (haven’t tried yet for `macos/clang/M1-arm64`), but breaks something else in my `windows` build. Apart from the fact that I don’t think it should be the proper way to go.

Any idea why `macos/clang/arm64` cannot find the target here?

Thanks!

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [May 31, 2023, 7:11pm UTC](https://discourse.cmake.org/t/executable-not-found-for-macos-clang-m1-arm64-but-yes-for-macos-clang-x86-64/8235/2 "2023-05-31T19:11:54Z")

</div>

> [@rturrado](#):
>
> ```auto
> add_custom_command(
> COMMAND "$<TARGET_FILE:func-gen>" "${HDR}" "${SRC}" "${VER}"
> OUTPUT "${HDR}" "${SRC}"
> DEPENDS func-gen
> )
> 
> ```

Try to use a genex here. I know `add_test` does some magic for command replacement, but I don’t know if `add_custom_command` does or not.

> [@rturrado](#):
>
> Any idea why `macos/clang/arm64` cannot find the target here?

I suspect that something is different in `PATH`.

---

<div class="post-metadata">

**Author:** ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)\
**Post date:** [May 31, 2023, 11:41pm UTC](https://discourse.cmake.org/t/executable-not-found-for-macos-clang-m1-arm64-but-yes-for-macos-clang-x86-64/8235/3 "2023-05-31T23:41:13Z")

</div>

> [@ben.boeckel](#):
>
> Try to use a genex here. I know `add_test` does some magic for command replacement, but I don’t know if `add_custom_command` does or not.

It does. The `add_custom_command()` docs say this:

> If `COMMAND` specifies an executable target name (created by the [`add_executable()`](https://cmake.org/cmake/help/latest/command/add_executable.html#command:add_executable) command), it will automatically be replaced by the location of the executable created at build time if either of the following is true:
> 
> - The target is not being cross-compiled (i.e. the [`CMAKE_CROSSCOMPILING`](https://cmake.org/cmake/help/latest/variable/CMAKE_CROSSCOMPILING.html#variable:CMAKE_CROSSCOMPILING) variable is not set to true).
> - New in version 3.6: The target is being cross-compiled and an emulator is provided (i.e. its [`CROSSCOMPILING_EMULATOR`](https://cmake.org/cmake/help/latest/prop_tgt/CROSSCOMPILING_EMULATOR.html#prop_tgt:CROSSCOMPILING_EMULATOR) target property is set). In this case, the contents of [`CROSSCOMPILING_EMULATOR`](https://cmake.org/cmake/help/latest/prop_tgt/CROSSCOMPILING_EMULATOR.html#prop_tgt:CROSSCOMPILING_EMULATOR) will be prepended to the command before the location of the target executable.
> 
> If neither of the above conditions are met, it is assumed that the command name is a program to be found on the `PATH` at build time.

---

<div class="post-metadata">

**Author:** ![rturrado](https://discourse.cmake.org/user_avatar/discourse.cmake.org/rturrado/32/3499_2.png) [@rturrado](https://discourse.cmake.org/u/rturrado)\
**Post date:** [June 1, 2023, 8:50am UTC](https://discourse.cmake.org/t/executable-not-found-for-macos-clang-m1-arm64-but-yes-for-macos-clang-x86-64/8235/4 "2023-06-01T08:50:00Z")

</div>

Many thanks @ben.boeckel, that worked. The Conan Center [build](https://c3i.jfrog.io/c3i/misc/logs/pr/17719/20-macos-m1-clang/libqasm/0.5.7//2b2201f54b77f855edf1189196431cb2e3f87839-build.txt) can find the executables now.

That didn’t make the build work though, but that’s another problem that has nothing to do with CMake anymore.

---

<div class="post-metadata">

**Author:** ![rturrado](https://discourse.cmake.org/user_avatar/discourse.cmake.org/rturrado/32/3499_2.png) [@rturrado](https://discourse.cmake.org/u/rturrado)\
**Post date:** [June 1, 2023, 9:11am UTC](https://discourse.cmake.org/t/executable-not-found-for-macos-clang-m1-arm64-but-yes-for-macos-clang-x86-64/8235/5 "2023-06-01T09:11:37Z")

</div>

Thanks for the comment @craig.scott. Cross-compilation may be the cause of the issue here.

I don’t fully understand yet how Conan Center is compiling my package for `M1-arm64`, but if you have a look at the profiles, it seems to say `arch_build=x86_64` and then, for `profile_host`, `arch=armv8`:

```auto
Auto detecting your dev setup to initialize the default profile (/Users/jenkins/w/prod/BuildSingleReference@3/.conan/profiles/default)
Found apple-clang 13.0
apple-clang>=13, using the major as version
Default settings
	os=Macos
	os_build=Macos
	arch=x86_64
	arch_build=x86_64
	compiler=apple-clang
	compiler.version=13
	compiler.libcxx=libc++
	build_type=Release
***You can change them in /Users/jenkins/w/prod/BuildSingleReference@3/.conan/profiles/default***
 ***Or override with -s compiler='other' -s ...s***

Configuration (profile_host):
[settings]
arch=armv8
build_type=Release
compiler=apple-clang
compiler.libcxx=libc++
compiler.version=13.0
os=Macos
[options]
libqasm:shared=True
[build_requires]
[env]
[conf]

```

---

<div class="post-metadata">

**Author:** ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)\
**Post date:** [June 1, 2023, 11:11am UTC](https://discourse.cmake.org/t/executable-not-found-for-macos-clang-m1-arm64-but-yes-for-macos-clang-x86-64/8235/6 "2023-06-01T11:11:06Z")

</div>

> [@rturrado](#):
>
> I don’t fully understand yet how Conan Center is compiling my package for `M1-arm64`, but if you have a look at the profiles, it seems to say `arch_build=x86_64` and then, for `profile_host`, `arch=armv8`:

Ah ha! I ran into something like this when supporting our superbuilds over to macOS arm64. Rosetta 2 is likely getting in the way here. The insight is that when a process is running in `x86_64` mode under Rosetta, any process it launches will _also_ see `x86_64` only and `arm64`-only binaries will refuse to launch. It would seem that `/bin/sh` (or something that launches it) is `x86_64`-only and that is why it fails to launch. I would highly recommend getting multi-arch or `arm64`-only copies of _everything_ in your setup (`ninja` was the problem in my case).