Building packages using Autotools fails for macOS passing detected CMAKE_<LANG>_COMPILER
czoido opened this issue · comments
Hi!
I am encountering an issue when trying to build libcurl, which uses Autotools, with cmake-conan on macOS. The problem appears to be related to the absolute paths detected for the C and C++ compilers. This can be replicated with a simple example, as shown here: https://github.com/czoido/cmake-conan-example
...
checking for path separator... :
checking for sed... /usr/bin/sed
checking for grep... /usr/bin/grep
checking that grep -E works... yes
checking for ar... /usr/bin/ar
checking for a BSD-compatible install... /usr/local/bin/ginstall -c
checking for gcc... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
checking whether the C compiler works... no
configure: error: in `/Users/carlosz/.conan2/p/b/libcue2d65d5f375a7/b/build-release':
configure: error: C compiler cannot create executables
See `config.log' for more details
...
When running this example on macOS, CMAKE_CXX_COMPILER is detected as /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++. This seems to cause the build process for libcurl with Autotools to fail. However, if I manually change the compilers to /usr/bin/g++ and /usr/bin/cc, the build completes without any issues.
Interesting!
I'd have to have a look at that config.log, this should be easy to reproduce outside of cmake-conan either way.
My suspicion is that this executable alone: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ is not properly configured when invoked directly - only when invoked via xcrun does it work properly, presumaly something else gets set up along the way (I think the SDKROOT is what xcrun passes) (note that /usr/bin/g++, /usr/bin/clang/, /usr/bin/cc and similar are all run via xcrun).
CMake most likely derives the compiler flags required for it to work, and thus can bypass xcrun completely.
Will look into this !
Thanks a lot. I can copy the relevant part of the failing log:
configure:4917: checking whether the C compiler works
configure:4939: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -m64 -fPIC -O3 -DNDEBUG -I/Users/carlosz/.conan2/p/b/zlib18a00e431d771/p/include -m64 -L/Users/carlosz/.conan2/p/b/zlib18a00e431d771/p/lib conftest.c -lz >&5
ld: library 'System' not found
clang: error: linker command failed with exit code 1 (use -v to see invocation)
configure:4943: $? = 1
configure:4983: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "curl"
| #define PACKAGE_TARNAME "curl"
| #define PACKAGE_VERSION "-"
| #define PACKAGE_STRING "curl -"
| #define PACKAGE_BUGREPORT "a suitable curl mailing list: https://curl.se/mail/"
| #define PACKAGE_URL ""
| /* end confdefs.h. */
|
| int main (void)
| {
|
| ;
| return 0;
| }
configure:4988: error: in `/Users/carlosz/.conan2/p/b/libcu3262009bef6bc/b/build-release':
configure:4990: error: C compiler cannot create executables
See `config.log' for more details
Versus a succesfull log invoking gcc:
configure:4917: checking whether the C compiler works
configure:4939: gcc -m64 -fPIC -O3 -DNDEBUG -I/Users/carlosz/.conan2/p/b/zlib18a00e431d771/p/include -m64 -L/Users/carlosz/.conan2/p/b/zlib18a00e431d771/p/lib conftest.c -lz >&5
configure:4943: $? = 0
configure:4993: result: yes
Yes, I think that's the cause of the problem, that the gcc shim invokes xcrun and thereby ensures a properly configured environment for the compiler and linker.
Fixed in #592.