Trunk doesn't compile out-of-tree on OpenSuse Linux

[GoogleCodeExporter]

Five problems with current trunk CMakeLists.txt:
- cmake doesn't work because CMakeLists.txt is missing include(FindSubversion) 
so that Subversion_WC_INFO isn't defined
- "-std=c++11" isn't added to the compiler flags but unique_ptr is used. I used 
in the patch -std=c++0x to make it also work for gcc 4.6. One could check which 
compiler flag is supported by check_cxx_accepts_flag but it seems you like to 
keep CMakeLists.txt as simple as possible.
- LLVMBitReader seems to depend on LLVMCore and thus the linker order isn't ok
- on my system the curses lib isn't call libcurses but libncurses (this problem 
is also present in the last release not just trunk). One could use Find* for 
all libraries (dl, pthread, z).
- I needed to add linking of libz because the llvm libraries depend on it

Original issue reported on code.google.com by rol...@rschulz.eu on 28 May 2014 at 11:35

Attachments:

• patch

[GoogleCodeExporter]

Thanks!

Is this for out-of-tree builds? Our in-tree builds seem to work fine, but they 
inherit lots of settings from LLVM and Clang's CMake system.

What platform are you on?

Original comment by kim.gras...@gmail.com on 31 May 2014 at 6:50

[GoogleCodeExporter]

Yes this is out of tree. OpenSuse Linux.

Original comment by rol...@rschulz.eu on 31 May 2014 at 8:05

[GoogleCodeExporter]

Thanks. We should really get some kind of buildbot system up and running to 
catch these things.

I'll try and work through your patch and make sure it doesn't break Windows or 
Ubuntu 14.04. Volodymyr, could you check the patch on your Mac?

Original comment by kim.gras...@gmail.com on 31 May 2014 at 8:25

[GoogleCodeExporter]

A few comments:
- also need to check what happens with IWYU_SVN_REVISION when there are no .svn 
files;
- I think we can use "-std=c++11" because minimum supported GCC version is 4.7 
[1];
- I've rearranged a few other LLVM libraries, haven't checked new order on 
Linux, but seems like it should be the right order.

Patch with my changes is attached.

[1] 
http://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-stan
dard-library

Original comment by vsap...@gmail.com on 31 May 2014 at 3:31

Attachments:

• fix_build.patch

[GoogleCodeExporter]

- I fixed that it also works without svn binary or without .svn folder. 
- Do you want to use Find* for all libraries? 

Original comment by rol...@rschulz.eu on 31 May 2014 at 4:59

Attachments:

• fix_build.patch

[GoogleCodeExporter]

Update title.

Original comment by kim.gras...@gmail.com on 31 May 2014 at 10:12

• Changed title: Trunk doesn't compile out-of-tree on OpenSuse Linux

[GoogleCodeExporter]

  > - I fixed that it also works without svn binary or without .svn folder.
Is it possible to use only CMAKE_SOURCE_DIR or CMAKE_CURRENT_SOURCE_DIR for 
consistency?  Personally I lean towards CMAKE_CURRENT_SOURCE_DIR because it was 
already used.  And I think Subversion_FOUND will be more consistent with 
Subversion_WC_INFO and Subversion_FOUND in llvm/cmake/modules/GetSVN.cmake.

  > - Do you want to use Find* for all libraries?
It depends on variety of *nix operating systems.  I don't know much about them 
and assume that Mac OS X, FreeBSD, and different Linux flavors all have 
libpthread, libz.  Based on this assumption, I don't think we need to use Find* 
for all libraries.  Feel free to debunk my assumption.

Original comment by vsap...@gmail.com on 1 Jun 2014 at 5:17

[GoogleCodeExporter]

I think you are right that z, dl, and pthread should all be always there and 
also most likely in the default library search path. And the headers (which 
could not be there if the user doesn't has the -devel package) are not used 
other than by one test in more_tests, which uses the dlfcn header. Thus it 
should be OK without using Find*.

Fixed the CMAKE_CURRENT_SOURCE_DIR and Subversion_FOUND.

Original comment by rol...@rschulz.eu on 1 Jun 2014 at 6:18

Attachments:

• fix_build_2.patch

[GoogleCodeExporter]

The last patch works on Mac OS X 10.9.2 (in-tree, out-of-tree, without SVN 
files).  But it doesn't work (assertion failure) on Ubuntu 14.04 out-of-tree 
with libclang-3.5-dev version 3.5~svn209708-1~exp1.  I don't know why IWYU 
crashes, maybe I've done something stupid with apt-get and have broken some 
libraries.  Will investigate further.

And one more tiny change in CMakeLists.txt:
    - # Disable RTTI to be compatible with LLVM/Clang libraries.
    + # Disable RTTI, use C++11 to be compatible with LLVM/Clang libraries.

Original comment by vsap...@gmail.com on 2 Jun 2014 at 5:02

[GoogleCodeExporter]

I've tried the patch both in-tree and out-of-tree on Windows. I haven't been 
able to try in my Ubuntu 14.04 environment, I don't have CMake on it and I'm 
not root.

In-tree works perfectly.

Out-of-tree needed some MSVC-specific adjustments (the LLVM binaries from 
http://llvm.org/builds/ are built against the non-default statically linked 
CRT, and IWYU needs to select it too), but I can add those as a separate commit.

For some reason I'm seeing 5 additional test failures with this out-of-tree 
build. It seems to be because the target triple defaults to 
"i686-pc-windows-gnu" (MinGW) for the out-of-tree build, rather than 
"i686-pc-windows-msvc", which causes it to fail to find standard library 
headers. I think the clang built-in headers also need to be copied locally.

All in all, I think the patch looks good to commit! I can get to the other 
Windows out-of-tree problems later.

Original comment by kim.gras...@gmail.com on 2 Jun 2014 at 8:42

[GoogleCodeExporter]

cmake has pre-build binaries on their download page which can be extracted in 
the home directory and run from there. No root permissions required.

Original comment by rol...@rschulz.eu on 2 Jun 2014 at 8:52

[GoogleCodeExporter]

This issue was closed by revision r552.

Original comment by vsap...@gmail.com on 3 Jun 2014 at 9:08

• Changed state: Fixed

[GoogleCodeExporter]

After rebooting my Ubuntu box cannot reproduce assertion failure anymore.  So 
I've committed the patch.  Thanks, Roland for your help.

Original comment by vsap...@gmail.com on 3 Jun 2014 at 9:11