[llvm-dev] (Thin)LTO llvm build

[Teresa Johnson via llvm-dev]

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.

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/
> msan-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/b9c310f7/attachment.html>