Notes
(0038809) Brad King (manager) 2015-05-28 11:07	The -arch and -isysroot flags have been on OS X in their GNU compiler port since long before Clang even existed. CMAKE_OSX_SYSROOT and CMAKE_OSX_ARCHITECTURES were created back then. We now have CMAKE_SYSROOT: http://www.cmake.org/cmake/help/v3.2/variable/CMAKE_SYSROOT.html [^] instead. CMAKE_OSX_ARCHITECTURES is for OS X universal binaries where the toolchains and loaders natively support storing multiple architectures in single binary files. Does Clang support this elsewhere? Otherwise the -arch flag can simply be specified explicitly like any other compiler flag.

(0038812) Chris Bieneman (reporter) 2015-05-28 12:12	The CMAKE_SYSROOT flag controls --sysroot, wheras the CMAKE_OSX_SYSROOT flag controls -isysroot. These two flags behave differently. Clang passes --sysroot through to the linker as the library root, and uses -isysroot as the header root. If you set -isysroot and not --sysroot it implies setting --sysroot to the value of -isysroot. If it is intended to work universally, it needs to control -isysroot for clang. If it did that then it could replace the CMAKE_OSX_SYSROOT flag entirely. The history of the CMAKE_OSX flags makes sense. Clang only supports generation of fat binaries on Darwin, so I can see a case for leaving the ARCHITECTURES flag as-is. Eventually clang will likely support fat elf binaries as well, in which case a more-general flag will be warranted.

(0038818) Brad King (manager) 2015-05-29 09:33	Re 0015591:0038812: Right, I forgot about the difference between --sysroot and -isysroot. The CMAKE_OSX_SYSROOT was created for -isysroot originally because the option was at one time required on OS X just to compile a simple program as a universal binary. Also it allows us to set the parameter correctly in the Xcode generator without having to parse -isysroot out of user-provided flags. For other platforms with Clang is there any reason a dedicated option is needed instead of adding -isysroot to the flags normally?

(0038822) Chris Bieneman (reporter) 2015-05-29 13:35	At this point what I'm really asking for is a cleanup and merge of the CMAKE_OSX_SYSROOT flag and the CMAKE_SYSROOT flag. There are two reasons for that. (1) is consistency, and the other is the entire justification for the CMAKE_SYSROOT flag in the first place. From a consistency perspective: I would like to see a single sysroot flag that works across a variety of toolchains so that when generating build files for cross-compiling we don't have to hack around this for every target platform and all supported tools variants. For example. Today if you are on darwin with clang cross-targeting iOS, Android, or Linux it is trivial, you just set CMAKE_OSX_SYSROOT to point at your SYSROOT, and use a toolchain file to setup linkers and low-level tools and it is actually quite clean. If you're on Linux the story is quite different if you are using GCC vs Clang. For GCC the CMAKE_SYSROOT flag works, but for clang that flag behaves quite oddly, so you need to hack around and add appropriate isysroot. If you're on Windows it gets even odder because you might be using GCC, or Clang (native or through cygwin), or MSVC. This all requires special handling. While we can do special handling of this in our project (and we do), it would be nice if some of this logic were built into CMake. On the other side, when talking about the CMAKE_SYSROOT flag, it is worth noting, from looking at the revision history the CMAKE_SYSROOT flag was added (de4da66) and reverted (0416c94) before being added again (7cd65c9). The reason for the revert was so the flag could be merged with the CMAKE_OSX_SYSROOT flag, a merging that didn't happen. The most important bit from the commit WRT why CMAKE_SYSROOT is an important concept outside a compiler flag is: "The contents of this variable is passed to supporting compilers as --sysroot. It is also accounted for when processing implicit link directories reported by the compiler, and when generating RPATH information."

(0038826) Stephen Kelly (developer) 2015-05-30 15:05	For reference, this relates to llvm bug 21562 https://llvm.org/bugs/show_bug.cgi?id=21562 [^] http://thread.gmane.org/gmane.comp.compilers.llvm.devel/86248 [^] We discussed related issues here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7294 [^] http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8363/focus=8621 [^] The most up to date information I have about cross compiling with Clang and CMake is http://thread.gmane.org/gmane.comp.compilers.clang.devel/33435 [^] so it would be useful to update http://www.cmake.org/cmake/help/v3.2/manual/cmake-toolchains.7.html#cross-compiling-using-clang [^] if there is a further outcome from this.

(0038827) Stephen Kelly (developer) 2015-05-30 16:08	Further context: http://thread.gmane.org/gmane.comp.compilers.llvm.devel/82036/focus=83424 [^] Chris, you can probably use set(CMAKE_C_COMPILE_OPTIONS_SYSROOT -isysroot) set(CMAKE_CXX_COMPILE_OPTIONS_SYSROOT -isysroot) after the project() command to get the options you want.

(0038869) Chris Bieneman (reporter) 2015-06-01 12:54	Stephen, Thank you, I wasn't aware of the CMAKE_${lang_COMPILE_OPTIONS_SYSROOT. I think I can accomplish what I need with that. Also to provide some extra context, there are instructions for cross-compiling LLVM for iOS with CMake here: http://llvm.org/docs/GettingStarted.html#cross-compiling-llvm [^] I know Stephen is aware of what we're trying to do, but for anyone else following along, the big complication with our bug (https://llvm.org/bugs/show_bug.cgi?id=21562 [^]), is that the compiler-rt project is inherently a cross-compile. When you build a full clang toolchain you can select a set of target architectures to build support for. After clang is built if you are building compiler-rt (our version of libgcc), you need to use the just-built clang to cross-compile the runtime library for each target architecture. Today we hack around this and don't actually treat it as a cross-compile. For us to obsolete our autotools build system we need to address a number of limitations in our current CMake system, and my plan for how to do that is to treat compiler-rt builds as a proper cross-compile.

(0038870) Brad King (manager) 2015-06-01 13:02	Re 0015591:0038869: Thanks for the info. FYI, CMAKE_<LANG>_COMPILE_OPTIONS_SYSROOT is an undocumented internal variable that is supposed to be filled out by the compiler information modules for the current toolchain if it has such a flag. Setting it as Steve mentioned in 0015591:0038827 will override/workaround the builtin default but is not a first-class solution. Further work/discussion/design will be needed to consolidate all these sysroot options.

(0042785) Kitware Robot (administrator) 2016-06-10 14:29	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2015-05-28 10:56	Chris Bieneman	New Issue
2015-05-28 11:07	Brad King	Note Added: 0038809
2015-05-28 12:12	Chris Bieneman	Note Added: 0038812
2015-05-29 09:33	Brad King	Note Added: 0038818
2015-05-29 13:35	Chris Bieneman	Note Added: 0038822
2015-05-30 15:05	Stephen Kelly	Note Added: 0038826
2015-05-30 16:08	Stephen Kelly	Note Added: 0038827
2015-06-01 12:54	Chris Bieneman	Note Added: 0038869
2015-06-01 13:02	Brad King	Note Added: 0038870
2016-06-10 14:29	Kitware Robot	Note Added: 0042785
2016-06-10 14:29	Kitware Robot	Status	new => resolved
2016-06-10 14:29	Kitware Robot	Resolution	open => moved
2016-06-10 14:29	Kitware Robot	Assigned To	=> Kitware Robot
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Relationships