Gentoo Archives: gentoo-musl

From: Lei Zhang <zhanglei.april@×××××.com>
To: Luca Barbato <lu_zero@g.o>, gentoo-musl@l.g.o
Subject: [gentoo-musl] [GSoC] _GNU_SOURCE in C++
Date: Tue, 14 Jun 2016 07:44:05
Message-Id: CAOYuCc2iavSmy2Pqy5pv8TOxguSYNMPk7wZCG10_9QghfK6TSA@mail.gmail.com
1 Hi,
2
3 So far the toughest issue with building LLVM against musl is that,
4 LLVM redefines a bunch of non-POSIX symbols, including fopen64,
5 stat64, etc, inside a C++ namespace. The namespace prevents them from
6 clashing with glibc's definitions; but unfortunately, musl defines
7 these symbols as macros, and macros don't respect C++ namespace, thus
8 the clash.
9
10 Here's how it looks in musl:
11
12 #if defined(_LARGEFILE64_SOURCE) || defined(_GNU_SOURCE)
13 #define tmpfile64 tmpfile
14 #define fopen64 fopen
15 ...
16 #endif
17
18 Actually these definitions are protected by _GNU_SOURCE, and LLVM
19 *only* define this macro when glibc is present. So theoretically LLVM
20 should play nice with musl. But an unfortunate truth is that,
21 _GNU_SOURCE is unconditionally defined by g++ and clang++ when
22 compiling any C++ code on Linux, rendering this protection useless.
23
24 I did some googling, and it turns out that libstdc++ heavily relies on
25 _GNU_SOURCE, so g++ always enable this macro for libstdc++ to function
26 correctly. I guess clang++ does the same thing just for compatibility
27 with g++.
28
29 I think the incompatibility between LLVM and musl is probably neither
30 side's fault, but the compiler's. Anyway, at least one of the three
31 should be fixed.
32
33 Thoughts?
34
35 Lei

Replies

Subject Author
Re: [gentoo-musl] [GSoC] _GNU_SOURCE in C++ Felix Janda <felix.janda@××××××.de>