[LLVMdev] Transitioning build to cmake

[Charles Davis]

On Jul 24, 2013, at 11:11 AM, Jeremy Huddleston Sequoia wrote:

> I recently took a stab at changing the MacPorts llvm-3.4 port from the configure-based build system to the cmake-based build system.
> 
> There are a couple of issues that I still haven't been able to work out yet and would like to know if these are just configuration issues on my side or bugs I should file at bugs.llvm.org:
> 
> 
tl;dr: LLVM CMake support is primarily designed for Windows/Visual Studio (especially in LLVM proper) and Linux (especially in compiler-rt), and needs lots of work to work well on Mac OS X or anywhere else. In particular, it is missing many features that are present in the autotools build. (Though, as the CMake proponents 'round here are quick to point out, the autotools system is itself missing some features that are present in CMake.)


> 1) libclang_rt
> 
> It looks like the cmake build is missing some runtime libraries.  How do I coerce it into building the right ones?
> 
> -./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.10.4.a
> ./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.asan_osx_dynamic.dylib
> -./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.cc_kext.a
> -./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.eprintf.a
> -./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.ios.a
> -./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.osx.a
> -./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.profile_ios.a
> +./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.i386.a
> ./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.profile_osx.a
> ./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.ubsan_osx.a
> +./opt/local/libexec/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.x86_64.a
The CMake support in compiler-rt evolved in a completely different direction from the Makefiles; it was primarily designed originally, IIRC, to support building asan (and later, the other sanitizers), and mostly on Linux at that. Other platforms and configurations were an afterthought. It needs serious work--in particular, the runtime libraries are built with the host compiler (not usually a problem, unless you're building a cross compiler), and (as you've probably noticed by now) it doesn't make fat archives. Patches welcome if you can speak CMake ;).

> 
> 
> 2) Universal
> 
> This looks like a bug in cmake.  I'm unable to build universal when setting CMAKE_OSX_ARCHITECTURES.  cmake errors out because it only set the -arch command line arguments at link time:
> 
>  ...
>  Building C object
>  CMakeFiles/cmTryCompileExec3905760613.dir/testCCompiler.c.o
> 
>  /usr/bin/clang -Os -o
>  CMakeFiles/cmTryCompileExec3905760613.dir/testCCompiler.c.o -c
>  /opt/local/var/macports/build/_Users_jeremy_src_macports_trunk_dports_lang_llvm-3.4/llvm-3.4/work/build/CMakeFiles/CMakeTmp/testCCompiler.c
> 
> 
>  Linking C executable cmTryCompileExec3905760613
> 
>  /opt/local/bin/cmake -E cmake_link_script
>  CMakeFiles/cmTryCompileExec3905760613.dir/link.txt --verbose=1
> 
>  /usr/bin/clang -Os -Wl,-search_paths_first -Wl,-headerpad_max_install_names
>  -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -arch i386
>  CMakeFiles/cmTryCompileExec3905760613.dir/testCCompiler.c.o -o
>  cmTryCompileExec3905760613
> 
>  ld: warning: ignoring file
>  CMakeFiles/cmTryCompileExec3905760613.dir/testCCompiler.c.o, file was built
>  for unsupported file format ( 0xCF 0xFA 0xED 0xFE 0x07 0x00 0x00 0x01 0x03
>  0x00 0x00 0x00 0x01 0x00 0x00 0x00 ) which is not the architecture being
>  linked (i386): CMakeFiles/cmTryCompileExec3905760613.dir/testCCompiler.c.o
> 
>  Undefined symbols for architecture i386:
>  ...
Well that's odd. I have CMake from trunk installed, and I was able to use it to build a very simple project with one C source universal. I was also able to build CMake itself universal. There's no bug in CMake--at least, not anymore. There might, however, be a bug in LLVM's build system that's causing this.
> 
> 
> 3) Shared library
> 
> The build fails if I try to build llvm using BUILD_SHARED_LIBS=ON ... the issue is that when the build tries to use the tools, dyld can't find libllvm-3.4svn.dylib because it's not yet installed.
The CMake build obviously needs to be taught to set the install names to relative paths on Mac OS, like the autotools build does.

Chip