Closed mathiasi closed 4 years ago
I can confirm that I am also experiencing this issue in 0.14
Hi @EricFalkenberg
Could you please confirm your output is the same as the above pasted by @mathiasi ?
I mean the error with #include_next <string.h>
.
Also, does this happen with the simplest CMakeLists.txt you could have? I don't have OSX right now to test, maybe @czoido could try to reproduce the issue.
@memsharded I tested with a simple CMakeLists.txt and the same issue appears:
cmake_minimum_required(VERSION 3.14)
project(untitled)
set(CMAKE_CXX_STANDARD 14)
if(NOT EXISTS "${CMAKE_BINARY_DIR}/conan.cmake")
message(STATUS "Downloading conan.cmake from https://github.com/conan-io/cmake-conan")
file(DOWNLOAD "https://github.com/conan-io/cmake-conan/raw/v0.14/conan.cmake"
"${CMAKE_BINARY_DIR}/conan.cmake")
endif()
include(${CMAKE_BINARY_DIR}/conan.cmake)
conan_cmake_run(REQUIRES Hello/0.1@memsharded/testing
BASIC_SETUP
BUILD missing)
add_executable(untitled main.cpp)
target_link_libraries(untitled ${CONAN_LIBS})
Hi @mathiasi
I think that this issue could be related to the CMP0025
policy in CMake:
https://cmake.org/cmake/help/latest/policy/CMP0025.html
Could you try to set the policy to NEW
in the CMakeLists.txt
?
cmake_policy(SET CMP0025 NEW)
Hope this helps. Please tell me if that fixes the issue
@czoido Thanks, it appears to have fixed the invalid settings.compiler.version value - I'm still seeing the #include_next <string.h>
error however it does appear to be blocking anything. Not sure of the significance/implications of this error.
Hi @mathiasi
I think that maybe CMake is no being able to find the MacOs SDK sysroot.
You could try to set the SDKROOT
environment variable to see if it can determine it that way.
Something like:
export SDKROOT=$(xcodebuild -version -sdk macosx Path)
Hope this helps :)
Hi @czoido
Bingo! After setting SDKROOT the error no longer appears :) Thanks a lot!
Closing this but I'm not sure if any changes is still needed for cmake-conan to handle this.
It seems that the SDKROOT is a pure cmake OSX issue, that is, not related to conan, would you get the same even if not using conan? I think so. Cmake-conan is just a wrapper to call Conan with the right arguments, but those arguments do not have anything related to the SDK. I'd say we can leave this as closed. Thanks for all the feedback!
I think I have to reopen this issue again. Upon further inspection this seems to be still an issue if used in conjunction with add_subdirectory in CMake.
Consider this structure:
Root
|--App
| |--CMakeLists.txt
| |--...
|--Lib
| |--CMakeLists.txt
| |--...
|--CMakeLists.txt
For testing I have set cmake_policy(SET CMP0025 NEW)
in all CMakeLists.txt. It does work if I go inside App and do a manual build but not if I try from the root level. I have attached a very basic sample: Conan-cmake-mac.zip
Hi @mathiasi
I think that maybe the problem could be related with your CMakeLists.txt
Have you tried to declare the name of the project in the CMakeLists.txt
that is in the root folder?
Something like: project(SomeName)
Let me know if that works. :)
Hi @czoido - Fantastic, that appears to have done the trick :) Thanks!
I had to use export SDKROOT=$(xcrun --show-sdk-path)
, otherwise, it works.
When I updated my Conan CMake file (which was old) and then I got the string error too. I did trace it back a couple of releases, but I don’t have the details on me :)
Note that I didn’t have the compiler issue, just the string include error
You can test it in the project below on Mac, just go back a couple of versions on the conan.cmake file (download from the website) and the string include error disappears. Note that it doesn’t seem to matter, things seem to work even if the error is printed. https://github.com/patricia-gallardo/heap_history_viewer/tree/make_windows_and_mac_run
Hi @patricia-gallardo,
I was not able to reproduce the issue with the project above. Did you set the SDKROOT
environment variable? The message is probably related to this: https://cmake.org/cmake/help/latest/variable/CMAKE_OSX_SYSROOT.html#variable:CMAKE_OSX_SYSROOT and not to Conan itself.
Hope this helps. Please let me know if the issue still happens.
I did not, because I didn’t have to before, the project works with a previous version of the conan file.
On Sat, 23 Nov 2019 at 09:42, Carlos Zoido notifications@github.com wrote:
Hi @patricia-gallardo https://github.com/patricia-gallardo, I was not able to reproduce the issue with the project above. Did you set the SDKROOT environment variable? The message is probably related to this: https://cmake.org/cmake/help/latest/variable/CMAKE_OSX_SYSROOT.html#variable:CMAKE_OSX_SYSROOT and not to Conan itself. Hope this helps. Please let me know if the issue still happens.
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/conan-io/cmake-conan/issues/159?email_source=notifications&email_token=AGABXMI5H3B2NQAUUY3RYB3QVDUIRA5CNFSM4IFDPE32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEE7QSIA#issuecomment-557779232, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGABXMJI56AGNOSECAOILOTQVDUIRANCNFSM4IFDPE3Q .
Hi @patricia-gallardo, Could you please check which XCode version you have and which is the SDK path?
xcodebuild -version
xcodebuild -version -sdk macosx Path
Which macOS version are you using? Maybe I can get some more clues to reproduce the problem :) Thanks a lot!
xcodebuild -version
Xcode 11.2.1
Build version 11B500
xcodebuild -version -sdk macosx Path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
env | grep SDKROOT
SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
-- Conan: Automatic detection of conan settings from cmake
-- Conan: Settings= -s;build_type=Debug;-s;compiler=apple-clang;-s;compiler.version=11.0;-s;compiler.libcxx=libc++
-- Conan executing: conan install /Users/<USER>/<PROJECT>/conanfile.txt -s build_type=Debug -s compiler=apple-clang -s compiler.version=11.0 -s compiler.libcxx=libc++ -g=cmake --build=missing
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug
compiler=apple-clang
compiler.libcxx=libc++
compiler.version=11.0
os=Macos
os_build=Macos
[options]
[build_requires]
[env]
conanfile.txt: Installing package
Requirements
fmt/6.0.0@bincrafters/stable from 'conan-center' - Cache
spdlog/1.4.2@bincrafters/stable from 'conan-center' - Cache
Packages
fmt/6.0.0@bincrafters/stable:5fed66895e5b85fca4af6ac05bb157e1ffecb806 - Cache
spdlog/1.4.2@bincrafters/stable:a382e60df586335ead063548817fbe5555ff08b7 - Cache
Hi @sergeyklay,
Could you please tell me if the path
"/usr/include/sys/types.h"
exists in your computer ?
Thanks a lot.
$ ls /usr/include/sys/types.h
ls: /usr/include/sys/types.h: No such file or directory
$ ls /usr/include
ls: /usr/include: No such file or directory
$ find /usr -type f -name types.h -print
/usr/local/lib/node_modules/hint/node_modules/iltorb/brotli/c/include/brotli/types.h
/usr/local/Cellar/gcc/9.2.0_2/include/c++/9.2.0/parallel/types.h
/usr/local/Cellar/webp/1.0.3/include/webp/types.h
/usr/local/Cellar/criterion/2.3.3/include/criterion/types.h
/usr/local/Cellar/graphviz/2.42.2/include/graphviz/types.h
/usr/local/Cellar/gcc@8/8.3.0_1/include/c++/8.3.0/parallel/types.h
$ echo | clang -Wp,-v -stdlib=libc++ -x c++ - -fsyntax-only
clang -cc1 version 11.0.0 (clang-1100.0.33.12) default target x86_64-apple-darwin18.7.0
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include/c++/v1"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/local/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/usr/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Frameworks (framework directory)
$ find /Applications -type f -name types.h -print | wc -l
43
The problem is gone using https://github.com/conan-io/cmake-conan/raw/v0.13/conan.cmake (instead of v0.14)
FYI:
$ ls $(xcodebuild -version -sdk macosx Path)/usr/include | grep string 130 ↵
bitstring.h
string.h
stringlist.h
strings.h
$ ls -lah /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
total 0
drwxr-xr-x 5 root wheel 160B Nov 21 10:00 .
drwxr-xr-x 6 root wheel 192B Nov 21 10:00 ..
drwxr-xr-x 4 root wheel 128B Nov 21 10:00 DriverKit19.0.sdk
drwxr-xr-x 8 root wheel 256B Nov 21 10:00 MacOSX.sdk
lrwxr-xr-x 1 root wheel 10B Nov 1 18:09 MacOSX10.15.sdk -> MacOSX.sdk
Hi @sergeyklay, thanks a lot for all the information, It's being very useful to outline the issue.
Status update.
Setting CMP0025
at the main CMakeLists.txt
cmake_policy(SET CMP0025 NEW)
echo "::set-env name=SDKROOT::$(xcodebuild -version -sdk macosx Path)"
Fixes the issue at GitHub Action. But note:
Sorry to intervene, but I believe I have something to add here. I hit that problem too with 0.15 and it looks like cmake is actually properly detects a path to SDK, but it doesn't set it in SDKROOT
but it rather passes it as a -isysroot <path>
argument to the compiler. try_compile
, for example, compiles this "#include <string>"
piece without an error.
I'm trying to find the best way to perform this test without asking user to set additional environment variables. But I though that information might be useful and someone could do it faster than me. :)
Issue #225 also relates to the 'string.h' file not found
error, and includes a pull request with a proposed fix.
This error should be fixed by: https://github.com/conan-io/cmake-conan/pull/226 to be merged in v0.16
Seems like this has been discussed before: https://github.com/conan-io/cmake-conan/issues/52 , https://github.com/conan-io/cmake-conan/issues/33
Even though they have been marked as resolved, it's still happening to me right now on version 0.14. Let me know if you need other information and I will happily provide to resolve this issue! :)