llvm dev - Dec 2015 - Bootstrapping clang/LLVM with ELLCC

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

On 18 December 2015 at 19:15, Richard Pennington via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 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)

On 12/18/2015 09:34 PM, Tim Northover wrote:
> On 18 December 2015 at 19:15, Richard Pennington via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> 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 
world>

-Rich
>
> Cheers.
>
> Tim.
>