[libcxx] r243574 - Recommit r243503 "[libcxx] Cleanup CMake configuration and integrate with LLVM"

[Eric Fiselier]

Hi Alexey,

I have an updated patch that does not include
"HandleLLVMOptions.cmake" . This file was giving us most of the
trouble. I have already confirmed that this works around the TSAN
issue pointed out earlier. Could you test this patch to see if you run
into any more problems?

On Wed, Jul 29, 2015 at 10:58 PM, Eric Fiselier <eric at efcs.ca> wrote:
>> Eric, what part of your change caused this behavior change? Probably, after you've started to execute LLVM CMake modules,
>> you've modified link flags used to build shared objects, and now they are required to have no unresolved symbols?
>
> This is exactly what is happening. HandleLLVMOptions.cmake adds
> "-Wl,-z,defs" on linux when LLVM_USE_SANITIZER is not specified.
> We also pick up -ffunction-sections and -fdata-sections. What effect
> do those have on building with sanitizers?
>
>
> One of the main reasons for this patch was to make it easier for
> libc++ to support sanitizer configurations.
> I would like the libc++ build to support each sanitizer configuration.
> Currently it seems like compiler-rt is better at
> building libc++ with sanitizers than libc++ is.
>
> Would anybody be willing to help with:
> A) Figuring out the proper flags for building and linking libc++ with
> each sanitizer.
> B) Moving some of the compiler-rt CMake logic for building libc++ into
> libc++ if applicable.
>
> /Eric
>
> On Wed, Jul 29, 2015 at 8:54 PM, Alexey Samsonov <vonosmas at gmail.com> wrote:
>> I've submitted r243599 that slightly improves things: now libcxx can be
>> configured with "Clang+TSan", but the build fails with a bunch of
>>   "undefined reference to `__tsan_read8'"
>> errors when we are trying to link libc++.so.
>>
>> Generally, we *don't* link in TSan runtime into shared objects - it should
>> only be linked into the executable, and __tsan_* symbols should be
>> left unresolved. Eric, what part of your change caused this behavior change?
>> Probably, after you've started to execute LLVM CMake modules,
>> you've modified link flags used to build shared objects, and now they are
>> required to have no unresolved symbols?
>>
>> On Wed, Jul 29, 2015 at 5:21 PM, Alexey Samsonov <vonosmas at gmail.com> wrote:
>>>
>>> I think I've found the "problem", causing CMake identification of Clang
>>> version. I will submit it shortly.
>>>
>>> On Wed, Jul 29, 2015 at 4:50 PM, Kostya Serebryany <kcc at google.com> wrote:
>>>>
>>>> Thanks, check-msan works for me again.
>>>>
>>>>
>>>>
>>>> On Wed, Jul 29, 2015 at 4:47 PM, Eric Fiselier <eric at efcs.ca> wrote:
>>>>>
>>>>> Reverted as r243593.
>>>
>>>
>>>
>>>
>>> --
>>> Alexey Samsonov
>>> vonosmas at gmail.com
>>
>>
>>
>>
>> --
>> Alexey Samsonov
>> vonosmas at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmake.patch
Type: application/octet-stream
Size: 44240 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150729/cdc8b927/attachment.obj>