[llvm-bugs] [Bug 35280] New: compiler-rt cannot be built with gcc on Mac OS X
via llvm-bugs
llvm-bugs at lists.llvm.org
Sun Nov 12 12:06:56 PST 2017
https://bugs.llvm.org/show_bug.cgi?id=35280
Bug ID: 35280
Summary: compiler-rt cannot be built with gcc on Mac OS X
Product: compiler-rt
Version: unspecified
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: compiler-rt
Assignee: unassignedbugs at nondot.org
Reporter: ro at gcc.gnu.org
CC: llvm-bugs at lists.llvm.org
To establish a baseline for a fix for https://reviews.llvm.org/D39888, I tried
building llvm trunk on Mac OS X 10.7/Darwin 11 and macOS 10.13/Darwin 17 with
gcc.
On Darwin 11, gcc is the only choice since llvm documentation states you need
at
least gcc 4.8 and the gcc included in Xcode 4.3.2 is based on gcc 4.2.1.
Therefore, I used self-compiled versions of gcc 5.1.0 on Darwin 11 resp. gcc
7.1.0
on Darwin 17.
There are so many problems that I'm just reporting them here without attempting
to provide proper patches.
* lib/builtins/atomic_flag_clear.c and several other atomic_*.c files fail to
compile
with gcc:
/vol/gcc/src/llvm/llvm/dist/projects/compiler-rt/lib/builtins/atomic_flag_clear.c:
In function 'atomic_flag_clear':
/vol/gcc/src/llvm/llvm/dist/projects/compiler-rt/lib/builtins/atomic_flag_clear.c:24:3:
warning: implicit declaration of function '__c11_atomic_store'; did you mean
'__atomic_store'? [-Wimplicit-function-declaration]
__c11_atomic_store(&(object)->_Value, 0, __ATOMIC_SEQ_CST);
^~~~~~~~~~~~~~~~~~
__atomic_store
/vol/gcc/src/llvm/llvm/dist/projects/compiler-rt/lib/builtins/atomic_flag_clear.c:24:31:
error: 'atomic_flag {aka _Atomic volatile struct <anonymous>}' has no member
named '_Value'
__c11_atomic_store(&(object)->_Value, 0, __ATOMIC_SEQ_CST);
__c11_atomic_* only exists in clang <stdatomic.h> on Darwin, but gcc
comes with its own header which lacks those functions.
I hacked around this by disabling the atomic_* files in
lib/builtins/CMakeLists.txt.
One could either check for this or test for __CLANG_STDATOMIC_H in the
affected files.
* Many files in lib/builtins fail to compile:
gcc: error: this compiler does not support x86_64h
Strangely, the cmake output shows
-- OSX supported arches: i386;x86_64;x86_64h
-- Builtin supported architectures: i386;x86_64;x86_64h
while CMakeFiles/CmakeError.log clearly shows that gcc rejects -arch x86_64h:
Testing compiler for supporting osx-x86_64h:
Change Dir: /var/gcc.apfs/llvm/dist/CMakeFiles/CMakeTmp
Run Build Command:"/vol/gcc/bin/make" "cmTC_e88a6/fast"
/vol/gcc/bin/make -f CMakeFiles/cmTC_e88a6.dir/build.make
CMakeFiles/cmTC_e88a6.dir/build
make[1]: Entering directory
'/private/var/gcc.apfs/llvm/dist/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_e88a6.dir/src.c.o
/vol/gcc-7/bin/gcc -fPIC -Werror=date-time -Wall -W -Wno-unused-parameter
-Wwrite-strings -Wno-missing-field-initializers -pedantic -Wno-long-long
-Wno-comment -v -arch x86_64h -stdlib=libc++ -mmacosx-version-min=10.9
-isysroot / -o CMakeFiles/cmTC_e88a6.dir/src.c.o -c
/var/gcc.apfs/llvm/dist/CMakeFiles/src.c
gcc: error: this compiler does not support x86_64h
Using built-in specs.
COLLECT_GCC=/vol/gcc-7/bin/gcc
gcc: error: unrecognized command line option '-stdlib=libc++'
Target: x86_64-apple-darwin16.6.0
Configured with: /vol/gcc/src/gcc/gcc-7.1.0/configure --prefix=/vol/gcc-7
--enable-objc-gc --with-gmp-include=/vol/gcc/include
--with-gmp-lib=/vol/gcc/lib/amd64 --with-mpfr-include=/vol/gcc/include
--with-mpfr-lib=/vol/gcc/lib/amd64 --with-mpc-include=/vol/gcc/include
--with-mpc-lib=/vol/gcc/lib/amd64
--enable-languages=c,ada,c++,fortran,objc,obj-c++
--with-target-bdw-gc-include=/vol/gcc/include
--with-target-bdw-gc-lib=/vol/gcc/lib/amd64,i386=/vol/gcc/lib
Thread model: posix
gcc version 7.1.0 (GCC)
make[1]: *** [CMakeFiles/cmTC_e88a6.dir/build.make:66:
CMakeFiles/cmTC_e88a6.dir/src.c.o] Error 1
make[1]: Leaving directory
'/private/var/gcc.apfs/llvm/dist/CMakeFiles/CMakeTmp'
make: *** [Makefile:126: cmTC_e88a6/fast] Error 2
I hacked around this with cmake -DDARWIN_osx_ARCHS='i386;x86_64'.
* Many files in lib/builtins produce gcc/g++ errors:
gcc: error: unrecognized command line option '-stdlib=libc++'
g++: error: unrecognized command line option '-stdlib=libc++'
which is no wonder since g++ doesn't support libc++ and the -stdlib flag.
Again, I hacked around by disabling DARWIN_COMMON_CFLAGS,
DARWIN_COMMON_LINK_FLAGS in cmake/config-ix.cmake.
* libclang_rt.stats_osx_dynamic.dylib fails to link:
Undefined symbols for architecture x86_64:
"___cxa_demangle", referenced from:
__sanitizer::DemangleCXXABI(char const*) in
sanitizer_symbolizer_posix_libcdep.cc.o
__sanitizer::DemangleSwiftAndCXX(char const*) in
sanitizer_symbolizer_posix_libcdep.cc.o
__sanitizer::Symbolizer::PlatformDemangle(char const*) in
sanitizer_symbolizer_posix_libcdep.cc.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[2]: ***
[projects/compiler-rt/lib/stats/CMakeFiles/clang_rt.stats_osx_dynamic.dir/build.make:199:
lib/clang/6.0.0/lib/darwin/libclang_rt.stats_osx_dynamic.dylib] Error 1
which is weird since those functions are defined in
lib/sanitizer_common/sanitizer_symbolizer_posix_libcdep.cc.
* some files in lib/{asan, lsan, tsan} fail to compile:
/vol/gcc/src/llvm/llvm/dist/projects/compiler-rt/lib/asan/asan_mac.cc:253:47:
error: expected ')' before '^' token
void dispatch_async(dispatch_queue_t dq, void(^work)(void));
^
which is no wonder given gcc doesn't support the blocks extension. While
the uses in asan and lsan are wrapped in !MISSING_BLOCKS_SUPPORT, that macro
isn't defined anywhere (only in gcc's libsanitizer). Besides, there are
several unconditional uses in lib/tsan/rtl/tsan_interceptors_mac.cc and
some others.
* Last, there's a compilation failure:
/vol/gcc/src/llvm/llvm/dist/projects/compiler-rt/lib/safestack/safestack.cc:215:23:
error: constructor priorities are not supported
void __safestack_init() {
^j
Overall, this has been a nightmarish experience. Either this needs to be fixed
or clearly documented that llvm can only be self-compiled. If the latter, gcc
should be rejected early on to save others the trouble.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20171112/32f6259f/attachment.html>
More information about the llvm-bugs
mailing list