[LLVMdev] r204593 breaks Asan tests on FreeBSD

[Alexey Samsonov]

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>