[bug] macos arm64 (macos-14) with py 3.13 is having ld require architecture x86_64 but configured to arm64

[pechersky]

Describe the bug

I have a Github workflow that builds rdkit wheels on linux and mac, x86 and arm64, and python versions 3.9 to 3.13. It runs on all fine except for macos-14 arm64 python 3.13.

The cibuildwheel run fails at the repair step, but already during the C++ build, one sees worrisome lines like

    [ 34%] Linking CXX shared library ../../lib/libRDKitRDBoost.dylib
    ld: warning: ignoring file '/Users/runner/work/rdkit-pypi/rdkit-pypi/build/temp.macosx-11.0-arm64-cpython-313/rdkit/build/Code/RDBoost/CMakeFiles/RDBoost.dir/Wrap.cpp.o': found architecture 'arm64', required architecture 'x86_64'
    ld: warning: ignoring file '/Users/runner/.conan2/p/b/boost297312143d5bd/p/lib/libboost_log_setup.dylib': found architecture 'arm64', required architecture 'x86_64'

I'm concerned that somehow, conan is supplying x86_64 libs instead of arm64. The conan detected profiles are

    Detected profile:
    [settings]
    arch=armv8
    build_type=Release
    compiler=apple-clang
    compiler.cppstd=gnu17
    compiler.libcxx=libc++
    compiler.version=15
    os=Macos
  
    WARN: This profile is a guess of your environment, please check it.
    WARN: Defaulted to cppstd='gnu17' for apple-clang.
    WARN: The output of this command is not guaranteed to be stable and can change in future Conan versions.
    WARN: Use your own profile files for stability.
    Saving detected profile to /Users/runner/.conan2/profiles/default
  
    ======== Input profiles ========
    Profile host:
    [settings]
    arch=armv8
    build_type=Release
    compiler=apple-clang
    compiler.cppstd=gnu17
    compiler.libcxx=libc++
    compiler.version=15
    os=Macos
  
    Profile build:
    [settings]
    arch=armv8
    build_type=Release
    compiler=apple-clang
    compiler.cppstd=gnu17
    compiler.libcxx=libc++
    compiler.version=15
    os=Macos

The cmake command is

    ['cmake -S . -B build -DCMAKE_TOOLCHAIN_FILE=/Users/runner/work/rdkit-pypi/rdkit-pypi/conan/conan_toolchain.cmake -DCMAKE_POLICY_DEFAULT_CMP0091=NEW -DBoost_LIB_VERSION=1_85 -DPython3_EXECUTABLE=/private/var/folders/qn/7t0vq3ts721cmgt0tgrtgzl80000gn/T/cibw-run-a83a2axg/cp313-macosx_arm64/build/venv/bin/python -DRDK_BUILD_INCHI_SUPPORT=ON -DRDK_BUILD_AVALON_SUPPORT=ON -DRDK_BUILD_PYTHON_WRAPPERS=ON -DRDK_BOOST_PYTHON3_NAME=python -DRDK_BUILD_YAEHMOP_SUPPORT=ON -DRDK_BUILD_XYZ2MOL_SUPPORT=ON -DRDK_INSTALL_INTREE=OFF -DRDK_BUILD_CAIRO_SUPPORT=ON -DRDK_BUILD_FREESASA_SUPPORT=ON -DBoost_NO_SYSTEM_PATHS=ON -DCMAKE_INSTALL_PREFIX=/Users/runner/work/rdkit-pypi/rdkit-pypi/build/temp.macosx-11.0-arm64-cpython-313/rdkit_install -DCMAKE_BUILD_TYPE=Release -DRDK_BUILD_CPP_TESTS=OFF -DCMAKE_C_FLAGS=-Wno-implicit-function-declaration -DCMAKE_CXX_FLAGS="-Wno-implicit-function-declaration -DCATCH_CONFIG_NO_CPP17_UNCAUGHT_EXCEPTIONS" -DRDK_OPTIMIZE_POPCNT=OFF -DFREETYPE_LIBRARY=/opt/homebrew/lib/libfreetype.dylib -DFREETYPE_INCLUDE_DIRS=/opt/homebrew/include -DCMAKE_OSX_ARCHITECTURES=arm64 -DCMAKE_OSX_DEPLOYMENT_TARGET=14.0 ', 'cmake --build build --config Release', 'cmake --install build']

The delocate failure is

  Traceback (most recent call last):
    File "/private/var/folders/qn/7t0vq3ts721cmgt0tgrtgzl80000gn/T/cibw-run-a83a2axg/cp313-macosx_arm64/build/venv/bin/delocate-wheel", line 8, in <module>
      sys.exit(main())
               ~~~~^^
    File "/private/var/folders/qn/7t0vq3ts721cmgt0tgrtgzl80000gn/T/cibw-run-a83a2axg/cp313-macosx_arm64/build/venv/lib/python3.13/site-packages/delocate/cmd/delocate_wheel.py", line 115, in main
      copied = delocate_wheel(
          wheel,
      ...<4 lines>...
          **delocate_values(args),
      )
    File "/private/var/folders/qn/7t0vq3ts721cmgt0tgrtgzl80000gn/T/cibw-run-a83a2axg/cp313-macosx_arm64/build/venv/lib/python3.13/site-packages/delocate/delocating.py", line 1094, in delocate_wheel
      raise DelocationError(
      ...<2 lines>...
      )
  delocate.libsana.DelocationError: Some missing architectures in wheel
  /usr/local/lib/libRDKitRDBoost.1.dylib needs arch x86_64 missing from /Users/runner/.conan2/p/b/boost297312143d5bd/p/lib/libboost_atomic.dylib
  /usr/local/lib/libRDKitRDBoost.1.dylib needs arch x86_64 missing from /Users/runner/.conan2/p/b/boost297312143d5bd/p/lib/libboost_charconv.dylib
  /usr/local/lib/libRDKitRDBoost.1.dylib needs arch x86_64 missing from /Users/runner/.conan2/p/b/boost297312143d5bd/p/lib/libboost_chrono.dylib
[...]

CI logs:
logs_36596700182.zip

Related issues:
pypa/cibuildwheel#2345
matthew-brett/delocate#250

How to reproduce it

No response

[memsharded]

Hi @pechersky

Thanks for your feedback.

This is indeed surprising, there is nothing in conan that would make it behave differently just in that macos-14 arm64 python 3.13. situation.

I recall @jcar87 investigating some issue because in some OSX setup, the installed Python architecture or its combination with CMake or something like that was kind of changing the architecture flags.

It seems that Conan created the default armv8 profile correctly, and it also installed and put in the path the /Users/runner/.conan2/p/b/boost297312143d5bd/p/lib/libboost_log_setup.dylib correct armv8 libraries, but it is somehow the consumer build the one that thinks it should be building for x86_64 instead, which seems the error.

You said that it was only failing for Python 3.13, but I see python-version: 3.11 in the logs, could you please clarify?

Also the project is pretty large. It would be amazing if it can be reduced to something minimal, like some simple and fast "hello world" dependency or in any case depending on something "fast to build" like zlib if that triggers the error.

[pechersky]

Thanks for reading the issue and looking at the logs. I'll try to figure out if there is anything I can do to minimize/recreate the situation.

Regarding 3.11 -- that's the base python to be able to invoke cibuildwheel, which then does the wheel building in a container (with its own python). Invoked so:

          python -m pip install cibuildwheel==2.23.2
          python -m cibuildwheel --output-dir wheelhouse

For sanity, I'll try rerunning CI with a base python 3.13 -- update: same errors as before.

[pechersky]

Sleuthing tracked down the fix and the issue. In the rdkit CMakeLists (added in rdkit#1808), ld flags are retrieved from sysconfig.get_config_var('LDSHARED'). Those are then used as LINK_FLAGS to build python "modules linked against the _installed python".

Turns out those LDSHARED flags, which for example on a WSL Ubuntu machine look like the following:

>>> import sysconfig
>>> sysconfig.get_config_var("LDSHARED")
'x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions  -Wl,-z,relro -g -fwrapv -O2   '

will have -arch x86_64 on the macos-14 py 3.13 context. And thus one can modify the generated CMakeLists to strip that from the ld flags that have been passed:
kuelumbus/rdkit-pypi@c2a9431#diff-60f61ab7a8d1910d86d9fda2261620314edcae5894d5aaa236b821c7256badd7R286-R290

So the issue was that the CMake was running with -arch x86_64 because I initially did not perform the CMakeLists surgical change on how it gets the link flags.

[memsharded]

Hi @pechersky

Happy that you found the root cause. Thanks for the follow up and explaining the details!