[C++] AWS SDK not found for osx-arm #55357

Activity

1. h-vetinari

   added

   Type: bug

   on Nov 1, 2026
2. github-actions

   added

   Component: C++

   on Nov 1, 2026
3. h-vetinari

   changed the title [-][C++] newer AWS SDK not found in cross-compilation anymore.[/-] [+][C++] newer AWS SDK not found for osx-arm anymore[/+] on Nov 1, 2026
4. h-vetinari

   changed the title [-][C++] newer AWS SDK not found for osx-arm anymore[/-] [+][C++] AWS SDK not found for osx-arm[/+] on Nov 1, 2026
5. h-vetinari commented on Nov 1, 2026

   

   h-vetinari

   on Nov 1, 2026

   ContributorAuthor

   More actions

   I've rebased conda-forge/arrow-cpp-feedstock#2007; the failure is now easily observable there
6. h-vetinari commented on Nov 4, 2026

   

   h-vetinari

   on Nov 4, 2026

   ContributorAuthor

   More actions

   CC @raulcd @kou The ThirdParty CMake code here is a maze. Please help fix this, it's making feedstock maintenance a real burden (because every migrator wants to switch to native builds for osx-arm64, now that sufficient agents are generally available)
7. raulcd commented on Nov 5, 2026

   

   raulcd

   on Nov 5, 2026

   Member

   More actions

   @h-vetinari it seems like homebrew is messing up with some dependencies on that job. I've created a draft PR adding the following commit on top of your PR and CI was successful for the native OSX arm64.

   $ git log -1 -p
   commit a27c32f257e97c8a22e516d77884a7a04648e5f1 (HEAD -> test-aws-arm, origin/test-aws-arm)
   Author: Raúl Cumplido <raulcd@apache.org>
   Date:   Thu Nov 5 11:27:14 2026 +0100
   
       Test avoiding homebrew messing up CMake searches
   
   diff --git a/recipe/build.sh b/recipe/build.sh
   index b725cc07..2f924e25 100644
   --- a/recipe/build.sh
   +++ b/recipe/build.sh
   @@ -52,6 +52,11 @@ if [[ "${target_platform}" == "linux-aarch64" ]] || [[ "${target_platform}" == "
        export CMAKE_BUILD_PARALLEL_LEVEL=3
    fi
    
   +# native osx-arm64 runners have Homebrew in /opt/homebrew, which CMake searches by default
   +if [[ "${target_platform}" == "osx-arm64" ]]; then
   +    CMAKE_ARGS="${CMAKE_ARGS} -DCMAKE_IGNORE_PREFIX_PATH=/opt/homebrew"
   +fi
   +
    # IPO produces segfaults in the test suite on macOS x86-64
    if [[ "$target_platform" == "osx-64" ]]; then
        CMAKE_INTERPROCEDURAL_OPTIMIZATION=OFF

   I did use some AI to find what was going on as the logs were clearly not helpful.

   The original log -- Providing CMake module for Findlz4Alt as part of Arrow CMake package seems to be the clue as normally we have the following which fails to find the config (unless homebrew is present) and uses find_package:

   -- Checking for module 'liblz4'
   --   Found liblz4, version 1.10.0
   -- Found lz4Alt: $PREFIX/lib/liblz4.dylib
   

   Apart from those it seems we have an issue were ORC messes up CMAKE_MODULE_PATH on some cases (i.e. this case were the dependency was from homebrew):

   diff --git a/cpp/cmake_modules/FindorcAlt.cmake b/cpp/cmake_modules/FindorcAlt.cmake
   index ce8cd11b4c..38c4a76746 100644
   --- a/cpp/cmake_modules/FindorcAlt.cmake
   +++ b/cpp/cmake_modules/FindorcAlt.cmake
   @@ -26,7 +26,13 @@ endif()
    if(orcAlt_FIND_QUIETLY)
      list(APPEND find_package_args QUIET)
    endif()
   +# orcConfig.cmake overwrites CMAKE_MODULE_PATH and doesn't restore it
   +# when one of its dependencies isn't found because find_dependency()
   +# calls return() in the config file.
   +set(orcAlt_CMAKE_MODULE_PATH_KEEP "${CMAKE_MODULE_PATH}")
    find_package(orc ${find_package_args})
   +set(CMAKE_MODULE_PATH "${orcAlt_CMAKE_MODULE_PATH_KEEP}")
   +unset(orcAlt_CMAKE_MODULE_PATH_KEEP)
    if(orc_FOUND)
      set(orcAlt_FOUND TRUE)
      set(orcAlt_VERSION ${orc_VERSION})

   I've created a follow up commit on that same PR dropping the homebrew fix and applying the above were CMake configure was also successful.

   I think both fixes should be applied independently.
8. github-actions

   assigned

   raulcd

   on Nov 5, 2026