[LLVMdev] Transitioning build to cmake

[Alexey Samsonov]

On Thu, Jul 25, 2013 at 1:18 AM, Charles Davis <cdavis5x at gmail.com> wrote:

>
> 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 ;).
>

FWIW, we use CMake to build fat ASan runtime on Mac OS X, and it works
pretty well for us. I think that support for at least some of another
compiler-rt runtime libraries on Mac may be added with a reasonable effort
- there just wasn't any demand for that recently. I'm ready to review
patches or add some build rules myself, but as I work primarily on Linux
and don't know Clang use cases in the Mac world, I'll have problems testing
these changes.


>
> >
> >
> > 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
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 
Alexey Samsonov, MSK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130802/5608de6c/attachment.html>