ELLCC is a compilation tool chain based on clang/LLVM, libc++ and the musl standard C library for Linux. Recently I was asked if ELLCC pre-built binaries could be used to build clang/LLVM TOT. It turns out that it can with some simple patches. This is a simple way to bootstrap clang/LLVM on an arbitrary Linux system that either doesn't have GCC or has a version of GCC that is too old to build clang/LLVM. ELLCC pre-build binaries are available for ARM 32 and 64, Mips, PowerPC, and x86 32 and 64. They are statically linked so shared library versions don't matter on the Linux host.
Information on building clang/LLVM with ELLCC is here: http://ellcc.org/blog/?p=26397
-Rich
It turns out that it can with some simple patches.
This sounds really cool. I think we should seriously consider putting
these patches into LLVM mainline.
Information on building clang/LLVM with ELLCC is here:
http://ellcc.org/blog/?p=26397
Here are some of my thoughts on the patch there, with a view to upstreaming:
* Large sections of the patch seem to be Makefile changes. Given
that we're deprecating autoconf, a CMake equivalent will be needed.
* Unconditionally #defining _BSD_SOURCE doesn't feel right.
* #undefining libc symbols based on __ELCC__. This looks like a musl
issue rather than just elcc. I'm actually rarther suspicious of musl
here too: neither C99 nor C++11 reserve (e.g.) fopen64. That said,
we've put in worse hacks to support broken platforms (see
-fms-compatibility).
* sys/time.h: not sure this exists on all systems. What are we using
that depends on it and what guards does that source have?
* "and" as an operator? I know C allows it, but it's highly
unidiomatic. </tiniest nit in the world>
Cheers.
Tim.
(Fixed the cfe email address)
It turns out that it can with some simple patches.
This sounds really cool. I think we should seriously consider putting
these patches into LLVM mainline.
Information on building clang/LLVM with ELLCC is here:
http://ellcc.org/blog/?p=26397
Here are some of my thoughts on the patch there, with a view to upstreaming:
* Large sections of the patch seem to be Makefile changes. Given
that we're deprecating autoconf, a CMake equivalent will be needed.
I know. I'm scared to death of cmake, but I plan on moving there soon.
* Unconditionally #defining _BSD_SOURCE doesn't feel right.
I agree. I'll find a better way.
* #undefining libc symbols based on __ELCC__. This looks like a musl
issue rather than just elcc. I'm actually rarther suspicious of musl
here too: neither C99 nor C++11 reserve (e.g.) fopen64. That said,
we've put in worse hacks to support broken platforms (see
-fms-compatibility).
I'll talk to the musl guys about this. I don't think they like the idea of being referred to as a "broken platform".
* sys/time.h: not sure this exists on all systems. What are we using
that depends on it and what guards does that source have?
I'll verify why this was added. It was a while ago.
* "and" as an operator? I know C allows it, but it's highly
unidiomatic. </tiniest nit in the world>
I just copied what was already there. </tiniest rationalization in the
-Rich
Yeah, that was probably excessively harsh. But people could have
legitimate reasons for #including <stdio.h> (presumably) but making
use of "fopen64". You should see the hoops libc++ jumps through to
avoid such mishaps.
Cheers.
Tim.
Yeah, that was probably excessively harsh. But people could have
legitimate reasons for #including <stdio.h> (presumably) but making
use of "fopen64". You should see the hoops libc++ jumps through to
avoid such mishaps.
Looks like Musl's own definitions are protected by
"_LARGEFILE64_SOURCE || _GNU_SOURCE". My guess is that we end up
defining _GNU_SOURCE for whatever reason, which would make the #undefs
entirely logical in that regime. (Completely unchecked, of course).
Cheers.
Tim.
What are they trying to do -- provide header compatibility for broken
Linux sources that want to use the silly fopen64 and co? For that just
define a second prototype and use __asm__("fopen") or so to rename it.
No need for a macro.
Joerg
Thanks for bringing this up, Rich!
If these patches or something like them are accepted, maybe it makes sense to update docs/GettingStarted “getting a modern host c++ toolchain” to include ecc?