[llvm-dev] (Thin)LTO llvm build

[Kostya Serebryany via llvm-dev]

On Tue, Dec 27, 2016 at 8:49 AM, Teresa Johnson <tejohnson at google.com>
wrote:

>
>
> On Tue, Dec 27, 2016 at 8:30 AM, Carsten Mattner <carstenmattner at gmail.com
> > wrote:
>
>> On Tue, Dec 27, 2016 at 4:13 PM, Teresa Johnson <tejohnson at google.com>
>> wrote:
>> >
>> > On Tue, Dec 27, 2016 at 5:23 AM, Carsten Mattner <
>> carstenmattner at gmail.com> wrote:
>> >>
>> >> After figuring out the fault in the configuration step and rebuilding,
>> >> and then rebuilding again by forcing it with `ninja -k 16`, I managed
>> to
>> >> build everything but 12 ninja targets.
>> >>
>> >> I have to sift through them before I can report more, and I don't
>> >> don't know if it's small enough to post here, but some of the more
>> >> interesting errors are:
>> >>
>> >> llvm/projects/compiler-rt/lib/tsan/dd/dd_interceptors.cc:226:20:
>> >> error: redefinition of 'realpath'
>> >> INTERCEPTOR(char*, realpath, const char *path, char *resolved_path) {
>> >>                    ^
>> >> /usr/include/bits/stdlib.h:37:8: note: previous definition is here
>> >> __NTH (realpath (const char *__restrict __name, char *__restrict
>> __resolved))
>> >
>> >
>> > I've never seen this before. Looks like bits/stdlib.h gets pulled in
>> only
>> > when _FORTIFY_SOURCE is enabled (which causes
>> > __USE_FORTIFY_LEVEL > 0). Do you have _FORTIFY_SOURCE
>> > set somewhere?
>>
>> I do, it's by default a part of hardening flags on most Linux distros,
>> and I'm just following what the distro packages are built with.
>>
>> > Can you try with that not set?
>>
>> I can try, but I would prefer not to since it's a wide-spread default
>> in Linux distro
>> as part of stack-protector use. I would use SafeStack but that's limited
>> in
>> applicability right now. If I did we would still have the libomp
>> duplicate symbol
>> error.
>>
>
> Confirmed that when I build dd_interceptors.cc at head it normally builds
> fine, but when I add -D_FORTIFY_SOURCE=2 I get the same error. I poked
> around a little and saw that the sanitizers are not supported with
> FORTIFY_SOURCE (although the reasons given are different):
> https://sourceware.org/bugzilla/show_bug.cgi?id=20422. Looks like there
> was a patch proposed to emit a warning when they are both on (not sure if
> it went in).
>
> So possibly building the tsan library itself is not tested/supported with
> FORTIFY_SOURCE. kcc at google.com is probably the best person to ask, added
> him.
>

mixing -D_FORTIFY_SOURCE=2 with the sanitizers may be confusing as
mentioned above.
building the sanitizers themselves with -D_FORTIFY_SOURCE=2 is not expected
to work at all.


>
> Teresa
>
>
>> Since 3.9.0 built fine with that macro, I'd blame either gcc or glibc
>> headers or
>> compiler-rt 3.9.1.
>>
>> Arch Linux's 3.9.1 recipe applies the following patch:
>>
>> https://git.archlinux.org/svntogit/packages.git/tree/trunk/m
>> san-prevent-initialization-failure-with-newer-glibc.patch?h=packages/llvm
>>
>> all the files
>> https://git.archlinux.org/svntogit/packages.git/tree/trunk?h
>> =packages/llvm&id=a7dd5d50ec82d6a35a99f9bf92b074d4aeab1f50
>>
>
>
>
> --
> Teresa Johnson |  Software Engineer |  tejohnson at google.com |
> 408-460-2413 <(408)%20460-2413>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161227/edf176e1/attachment.html>