Gentoo Archives: gentoo-musl

From: Felix Janda <felix.janda@××××××.de>
To: Lei Zhang <zhanglei.april@×××××.com>
Cc: Luca Barbato <lu_zero@g.o>, soc-admins@g.o, gentoo-musl@l.g.o
Subject: Re: [gentoo-musl] Re: [GSoC] native-clang: daily report 06/29
Date: Fri, 01 Jul 2016 05:03:36
Message-Id: 20160701050139.GA310@nyan
In Reply to: [gentoo-musl] Re: [GSoC] native-clang: daily report 06/29 by Lei Zhang
1 Lei Zhang wrote:
2 > 2016-06-30 23:50 GMT+08:00 Luca Barbato <lu_zero@g.o>:
3 > > On 30/06/16 17:40, Lei Zhang wrote:
4 > >> I also noticed that gcc's sanitizer doesn't work on the musl based
5 > >> system, so is it forgivable to not support clang's sanitizer either?
6 > >> (clang's sanitizer is implemented in compiler-rt)
7 > >
8 > > package mask the useflag for now, it is less important.
9 > >
10 > > Make sure to open a bug about it on llvm and gcc.
11 >
12 > compiler-rt's sanitizer uses some non-POSIX features like <obstack.h>;
13 > I guess gcc's situation is similar. It's not necessarily a bug though.
14 >
15 > Actually compiler-rt uses stuff like "#if __linux__ && !__ANDROID__"
16 > to protect code that uses GNU extensions. The fix is simple: replace
17 > it with "#ifdef __GLIBC__". But I'm not sure if this fix has unwanted
18 > impact on other libc like uclibc. It looks uclibc supports certain GNU
19 > extensions that are absent in musl, like <obstack.h>.
20
21 uclibc defines also __GLIBC__. So changing from
22 "#if __linux__ && !__ANDROID__" to "#ifdef __GLIBC__" doesn't mean any
23 change for uclibc. (Code not working on uclibc would need to use
24 "#if __GLIBC__ && !__UCLIBC__".) However notice that there are non-linux
25 systems using glibc (kFreeBSD & Hurd), so (if they are relevant here)
26 the test might need to be "#if __linux__ && __GLIBC__".
27
28 Felix