Hi Ivan,
Hi Alexey,
(Ed Maste added to CC.) Well, since the buildbot is running v9.2: lab.llvm.org:8011/builders/sanitizer_x86_64-freeBSD9.2 it does indeed prevent us from enabling the bot. (Note is that D3031 was supposed to be the last change to commit to enable the buildbot.) Otherwise, I don’t see any problems with waiting for the changes–given it won’t take unreasonably long–as soon as I can do whatever local changes I need to make things build correctly. Thanks. –
Hi Alexey,
On FreeBSD 9.2 I add a couple custom options to CMAKE_CXX_FLAGS in order
to let clang know which header set it should use, like that:CC=clang CXX=clang++ cmake \
-DLLVM_TARGETS_TO_BUILD=X86 \
-DCMAKE_CXX_FLAGS="-I/usr/include/c++/4.8.1
-I/usr/include/c++/4.8.1/x86_64-unknown-freebsd9.2"That seems unfortunate - you add x86_64- headers to CMAKE_CXX_FLAGS,
while sanitizers tests are built in i386 mode.Not just that. There are several differences between building llvm and
sanitizers tests that I believe should be taken into account:Correct. Yes, LLVM (and compiler-rt) can be built with gcc and with
MSVC. Blindly passing CMAKE_CXX_FLAGS
to Clang when building sanitizer unit tests is... wrong. For now we get
away with this (and I decided to commit the mentioned change),
as sanitizer unit tests are built only on unix with GCC/Clang.Hopefully this will soon change, and by default we will build all
compiler-rt libraries and test suites with just-built Clang. This will
allow us to be very specific about command-line flags. Of course
"just-built Clang" will still need to use system headers and (for unit
tests) even system libraries, so _some_ flags must remain configurable by
the user. But I'd rather work on the bright future than fix the existing
and ugly clang_compile, clang_link etc. set of rulesLet me know if
you're OK with this, or you are in desperate need of the short-term fix (it
prevents you from setting up a buildbot, or smth. like that).(Ed Maste added to CC.)
Well, since the buildbot is running v9.2:
lab.llvm.org:8011/builders/sanitizer_x86_64-freeBSD9.2
it does indeed prevent us from enabling the bot. (Note is that D3031 was
supposed to be the last change to commit to enable the buildbot.)
Otherwise, I don't see any problems with waiting for the changes--given it
won't take unreasonably long--as soon as I can do whatever local changes I
need to make things build correctly.
Just curious: is it possible to revert the change locally on the buildbot
and keep it running? Or, alternatively, we can temporarily disable ASan
unit tests for FreeBSD 9.2, but still build sanitizer runtimes and run lit
tests (which would give us a pretty good coverage).
Alexey,
Yes, I think we can leave Asan tests disabled for now and let the buildbot do its work. I will check it once more if the current revisions build and work as expected on FreeBSD 9.2 and then let you know.
Hello Alexey,
I just worked out the config for the FreeBSD 9.2 buildbot (follows below). One important thing about this config is that the C++11 headers are set up at the /usr/include/c++/v1 directory--it's where clang expects them to be on FreeBSD, so no need for the "-I" options in the CMAKE_CXX_FLAGS variable. Unfortunately, clang (both v3.3 used to be the default compiler on FreeBSD 9.2 and recent revisions) do not add the libcxxrt run-time lib to ld options what means we have to ask cmake to add it for us (see the cmake invocation at the end of the config list). This approach let us build and run the common sanitizers tests with no unexpected failures. The only issue is that the HAVE_UNIT64_T & Co. tests fail to link due to omitted reference to libcxxrt. The quick fix is trivial:
Hi Ivan,
Hello Alexey,
I just worked out the config for the FreeBSD 9.2 buildbot (follows below).
One important thing about this config is that the C++11 headers are set up
at the /usr/include/c++/v1 directory--it's where clang expects them to be
on FreeBSD, so no need for the "-I" options in the CMAKE_CXX_FLAGS
variable. Unfortunately, clang (both v3.3 used to be the default compiler
on FreeBSD 9.2 and recent revisions) do not add the libcxxrt run-time lib
to ld options what means we have to ask cmake to add it for us (see the
cmake invocation at the end of the config list). This approach let us build
and run the common sanitizers tests with no unexpected failures. The only
issue is that the HAVE_UNIT64_T & Co. tests fail to link due to omitted
reference to libcxxrt. The quick fix is trivial:---
Index: cmake/config-ix.cmake--- cmake/config-ix.cmake (revision 205543)
+++ cmake/config-ix.cmake (working copy)
@@ -17,6 +17,7 @@
# Used by check_symbol_exists:
set(CMAKE_REQUIRED_LIBRARIES m)
endif()
+list(APPEND CMAKE_REQUIRED_LIBRARIES ${LLVM_CONFIG_TEST_LIBRARIES})# Helper macros and functions
macro(add_cxx_include result files)
---Do you think this fix would make sense for building llvm on other
platforms? I mean, do you think it looks acceptable to be sent for review
and commit? Please let me know.
Personally, I think it's fine to just add "cxxrt" to
CMAKE_REQUIRED_LIBRARIES in config-ix.cmake on the platforms that require
it (FreeBSD 9.2?).
Also, I believe I should prepare a patch that adds the -lcxxrt option for
a linker on FreeBSD so one day we can build llvm on FreeBSD without all
these tricky things.
Yes, please!
The config is this:
---
# The proposed buildbot config for FreeBSD 9.2# we have to install these from ports as the packages versions are too old
cd /usr/ports/devel/subversion
sudo make BATCH=1 install cleancd /usr/ports/devel/libc++
sudo make BATCH=1
sudo make PREFIX=/usr install cleancd /usr/src/lib/libcxxrt
sudo make
sudo make install cleancd /usr/ports/shells/bash
sudo make BATCH=1 install cleancd /usr/ports/textproc/gnugrep
sudo make BATCH=1 install cleanwget -c ftp://ftp.gnu.org/gnu/binutils/binutils-2.24.tar.gz
./configure --prefix=/usr --enable-language=c,c++
gmake
sudo gmake install# these are necessary to pass LLVM :: BugPoint/compile-custom.ll
sudo pkg install gcc
sudo pkg install pythonCC=clang CXX=clang++ cmake \
-DCMAKE_CXX_FLAGS="-std=c++11 -stdlib=libc++" \
-DCMAKE_CXX_COMPILER_WORKS=1 \
^^^
Why do you need this line?
Hello Alexey,
Without this line we fail on: – Check for working CXX compiler: /usr/bin/clang++ – broken The reason is that the [built-in] check doesn’t propagate CMAKE_EXE_LINKER_FLAGS to a linker when build the test. In fact, we probably should define CMAKE_CXX_COMPILER_FORCED instead of CMAKE_CXX_COMPILER_WORKS as the latter seems to be an internal variable. –