Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[C++] Bundled Mac C++ build fails when /usr/bin/libtool is an invalid libtool #44384

Closed
tomjakubowski opened this issue Oct 11, 2024 · 2 comments
Assignees
Milestone

Comments

@tomjakubowski
Copy link
Contributor

tomjakubowski commented Oct 11, 2024

Describe the bug, including details regarding any error messages, version, and platform.

I am supporting a bundled build of libarrow in perspective's conda-forge feedstock. On the conda-forge arm64 cross-compiling builders, /usr/bin/libtool is broken due to some SDK issues (full logs). Here is the (stderr?) output of /usr/bin/libtool from our build logs:

  xcodebuild: error: SDK "/Applications/Xcode_15.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk" cannot be located.
  libtool: error: sh -c '/Applications/Xcode_15.2.app/Contents/Developer/usr/bin/xcodebuild -sdk /Applications/Xcode_15.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk -find libtool 2> /dev/null' failed with exit code 16384: (null) (errno=No such file or directory)
  xcode-select: Failed to locate 'libtool', requesting installation of command line developer tools.

There is some logic in BuildUtils.cmake to locate libtool for bundling using find_program(libtool HINTS /usr/bin ...), which then fails:

  CMake Error at /Users/runner/miniforge3/conda-bld/perspective_1728519868797/work/rust/target/aarch64-apple-darwin/release/build/perspective-server-a7d183a58ee31af1/out/build/arrow-src/cpp/cmake_modules/BuildUtils.cmake:116 (message):
    libtool found appears to be the incompatible GNU libtool: /usr/bin/libtool

In this build environment, the LIBTOOL environment variable is set by conda to the name of a suitable Apple libtool on the PATH. I would propose that if LIBTOOL is set in the environment, that BuildUtils.cmake ought to use it instead of calling find_program.

To unblock us, I made this commit on top of 17.0.0 ProspectiveCo@273a228. I'll use that as the basis for a PR to close this issue. I am new to both conda-build and arrow's build system and would be glad to hear better ideas of how to address this.

Component(s)

C++

@tomjakubowski
Copy link
Contributor Author

tomjakubowski commented Oct 11, 2024

Discussion in #30937 suggests that Conda is probably also passing -DCMAKE_LIBTOOL=/path/to/or/name/of/some-suitable-apple-libtool (which perspective would forward on in its ExternalProject build of Arrow). Maybe it would better to check that cmake variable than an environment variable.

edit: learned from #44368 that CMAKE_LIBTOOL is used for MSVC builds. I'll do the same in my PR.

    if(CMAKE_LIBTOOL)
      set(BUNDLE_TOOL ${CMAKE_LIBTOOL})
    else()
      find_program(BUNDLE_TOOL lib 

tomjakubowski added a commit to tomjakubowski/arrow that referenced this issue Oct 11, 2024
When a builder sets `CMAKE_LIBTOOL`, use that as the program to bundle
dependencies.  This matches the behavior of the Windows build.

Also make a nitpicky minor update to the error message when a non-Apple
libtool is detected.
@amoeba amoeba changed the title Bundled Mac C++ build fails when /usr/bin/libtool is an invalid libtool [C++] Bundled Mac C++ build fails when /usr/bin/libtool is an invalid libtool Oct 13, 2024
tomjakubowski added a commit to tomjakubowski/arrow that referenced this issue Oct 14, 2024
When a builder sets `CMAKE_LIBTOOL`, use that as the program to bundle
dependencies.  This matches the behavior of the Windows build.

Also make a nitpicky minor update to the error message when a non-Apple
libtool is detected.
kou pushed a commit that referenced this issue Oct 16, 2024
When a builder sets `CMAKE_LIBTOOL`, use that as the program to bundle dependencies.  This matches the behavior of the Windows build.

Also make a nitpicky minor update to the error message when a non-Apple libtool is detected.

### Are these changes tested?

I did not add a test case for this build configuration. I confirmed the behavior when `CMAKE_LIBTOOL` is set, using this script on a Mac.  It creates an ad-hoc libtool wrapper and then passes it as `CMAKE_LIBTOOL`.

```
#!/bin/bash

mylibtool=$(mktemp -d)/libtool.sh
cat << 'EOF' > "$mylibtool"
#!/bin/bash
say -v Tom -- "voice-enhanced libtool:" "$@"
/usr/bin/libtool "$@"
EOF
chmod +x "$mylibtool"

cmake -GNinja -DARROW_DEPENDENCY_SOURCE=BUNDLED -DCMAKE_LIBTOOL="$mylibtool" -S cpp -B build/
cmake --build build/
```

I am not sure how to best add a test for this to the repository.

### Are there any user-facing changes?

This changes how bundled builds behave when an Apple build-user sets `CMAKE_LIBTOOL` in their CMake invocation. I think the change is a sensible one and wouldn't be surprising to users, but it may break existing builds in environments where /usr/bin/libtool is Apple's libtool, and `CMAKE_LIBTOOL` is set to a non-Apple one.
* GitHub Issue: #44384

Authored-by: Tom Jakubowski <tom@prospective.dev>
Signed-off-by: Sutou Kouhei <kou@clear-code.com>
@kou kou added this to the 19.0.0 milestone Oct 16, 2024
@kou
Copy link
Member

kou commented Oct 16, 2024

Issue resolved by pull request 44385
#44385

@kou kou closed this as completed Oct 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants