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 |