Hi Ivan, On Fri, Mar 28, 2014 at 3:21 PM, Ivan A. Kosarev <ivan at ivan-labs.com> wrote:> Hi Alexey, > > > On 03/27/2014 04:35 PM, Alexey Samsonov wrote: > > Here's the reason why I've made this change: > > http://llvm.1065342.n5.nabble.com/compiler-rt-CMake-build-ignores-CMAKE-CXX-FLAGS-tp67022.html > > > OK, thanks. > > BTW, should we CC this conversation to Konstantin or some other people as > well? >+llvmdev Oh, sure. Please cc' llvmdev mailing list for the discussion of sanitizers, especially when discussing portability issues, as more people might be interested in that or share their experience.> 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 rules :) Let 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).> > 1) Different compilers. Is bulding llvm with gcc still supported? Is there > a chance llvm (including sanitizers) will support building with MSVC as the > host compiler? What if one will need to add an option that should only be > applied to the llvm components themselves (that is, not the sanitizers > tests)? What if clang and the host compiler have different command-line > interfaces? > > 2) Different targets (the point you have mentioned). What if I build llvm > on a 64-bit system and I want to pass some 64-bit specific options to be > applied to the llvm components and not the sanitizers tests? What should I > do to add an option that should only be applied to i386 tests? > > Consider this: on x86_64 FreeBSD--both 9.2 and 10.0--when build something > in 32-bit mode (-m32) with gcc you have to add -B/usr/lib32 in order to let > the compiler know where it should search for the libs. As of today, it is > recognized as a defect in the FreeBSD community. However, it appears there > will be no fix available anytime soon due to various complications with how > gcc lookups for libraries. For this reason building LLVM on FreeBSD with > gcc and enabled sanitizers will not be supported. > > In general, it looks to me that adding several variables is not just a > question of more fine-grained control over the build process, but it also > removes unnatural connections between things to be used to build a clang > executable and things to be used to build other pieces with this > executable. I agree that there may be options that are common to both the > cases, but do we really want to force them to be exactly same? > > > This setting looks like a hack to me - where do you get new libstdc++ > from? > > > It's the one from gcc 4.8 distribution. > > > Why is it enough to just change the include paths, but not change the > path to the library location? > > > Once the library is installed, its location must be added to > /etc/libmap.conf . > > > Is it possible to install newer version of libstdc++ in the system, so > that it's picked up at configure time w/o the need for additional flags? > > > I'm going to spend some more time on digging this matter. Will let you > know. > > Thanks, > > -- > >-- Alexey Samsonov, MSK -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140331/a33b1271/attachment.html>
Hi Alexey, On 03/31/2014 09:58 PM, Alexey Samsonov wrote:> 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 rules :) Let > 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. Thanks. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140401/39daf46e/attachment.html>
On Tue, Apr 1, 2014 at 1:23 PM, Ivan A. Kosarev <ivan at ivan-labs.com> wrote:> Hi Alexey, > > > On 03/31/2014 09:58 PM, Alexey Samsonov wrote: > > 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 rules :) Let 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).> > Thanks. > > -- > >-- Alexey Samsonov, MSK -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140401/b83ee8b0/attachment.html>
Possibly Parallel Threads
- [LLVMdev] r204593 breaks Asan tests on FreeBSD
- [LLVMdev] compiler-rt CMake build ignores CMAKE_CXX_FLAGS
- [LLVMdev] compiler-rt CMake build ignores CMAKE_CXX_FLAGS
- [LLVMdev] r204593 breaks Asan tests on FreeBSD
- [LLVMdev] CMake does not propagate flags to build