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
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>
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>