Executable not found for macos/clang/M1-arm64 but yes for macos/clang/x86_64

Code
1

Hi all,

I’m adding a package to Conan Center. It builds correctly for macos/clang/x86_64, but fails for macos/clang/M1-arm64. The error comes from this piece of code:

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):

/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!

2

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.

I suspect that something is different in PATH.

1 Like
3

It does. The add_custom_command() docs say this:

If COMMAND specifies an executable target name (created by the 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 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 target property is set). In this case, the contents of 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.

1 Like
4

Many thanks @ben.boeckel, that worked. The Conan Center build 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.

5

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 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]
6

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).

1 Like