| 1 |
Lei Zhang wrote: |
| 2 |
> Hi, |
| 3 |
> |
| 4 |
> So far the toughest issue with building LLVM against musl is that, |
| 5 |
> LLVM redefines a bunch of non-POSIX symbols, including fopen64, |
| 6 |
> stat64, etc, inside a C++ namespace. The namespace prevents them from |
| 7 |
> clashing with glibc's definitions; but unfortunately, musl defines |
| 8 |
> these symbols as macros, and macros don't respect C++ namespace, thus |
| 9 |
> the clash. |
| 10 |
> |
| 11 |
> Here's how it looks in musl: |
| 12 |
> |
| 13 |
> #if defined(_LARGEFILE64_SOURCE) || defined(_GNU_SOURCE) |
| 14 |
> #define tmpfile64 tmpfile |
| 15 |
> #define fopen64 fopen |
| 16 |
> ... |
| 17 |
> #endif |
| 18 |
> |
| 19 |
> Actually these definitions are protected by _GNU_SOURCE, and LLVM |
| 20 |
> *only* define this macro when glibc is present. So theoretically LLVM |
| 21 |
> should play nice with musl. But an unfortunate truth is that, |
| 22 |
> _GNU_SOURCE is unconditionally defined by g++ and clang++ when |
| 23 |
> compiling any C++ code on Linux, rendering this protection useless. |
| 24 |
> |
| 25 |
> I did some googling, and it turns out that libstdc++ heavily relies on |
| 26 |
> _GNU_SOURCE, so g++ always enable this macro for libstdc++ to function |
| 27 |
> correctly. I guess clang++ does the same thing just for compatibility |
| 28 |
> with g++. |
| 29 |
> |
| 30 |
> I think the incompatibility between LLVM and musl is probably neither |
| 31 |
> side's fault, but the compiler's. Anyway, at least one of the three |
| 32 |
> should be fixed. |
| 33 |
> |
| 34 |
> Thoughts? |
| 35 |
|
| 36 |
Take a look at the discussion at |
| 37 |
|
| 38 |
http://www.openwall.com/lists/musl/2014/04/15/3 |
| 39 |
|
| 40 |
Felix |
Archives