[llvm-dev] (Thin)LTO llvm build

[Carsten Mattner via llvm-dev]

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.

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