-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Comments
Discussion in #30937 suggests that Conda is probably also passing edit: learned from #44368 that CMAKE_LIBTOOL is used for MSVC builds. I'll do the same in my PR.
|
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.
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.
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>
Issue resolved by pull request 44385 |
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:There is some logic in BuildUtils.cmake to locate libtool for bundling using
find_program(libtool HINTS /usr/bin ...)
, which then fails: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 ifLIBTOOL
is set in the environment, that BuildUtils.cmake ought to use it instead of callingfind_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++
The text was updated successfully, but these errors were encountered: