[Toybox] tcc and pcc. Was: The new gcc 9 bug you pointed out.

[scsijon]

Thanks for the reply Rob, I hadn't realized it had changed over, that 
means when I next build a Quirky Puppy I should be able to include it as 
part of the standard set of packages, not as an extra, hooray!

I'm currently working on moving Quirky to use llvm / rust / clang as a 
necessary step for some packages now appearing / updating requiring rust 
and I want to build at least once with llvm/clang. I plan to build 
cutdowns with tcc and pcc instead of gcc / glib / glibc when I am happy 
with stability.

And, in case anyone is interested.

For tcc i've been looking at https://github.com/cosmo-ray/tcc, with the 
mail thread at 
http://lists.nongnu.org/archive/html/tinycc-devel/2019-05/threads.html. 
Matthias Gatto is leading / working it, so it's being seriously looked 
at by at least one of the kernel group. I'll have a look at yours, but I 
suspect i'll stay with his, sorry :-).

For pcc i've been working from ftp://pcc.ludd.ltu.se/pub/ for both pcc 
and pcc-libs as well as extras. The doc's and the rest aren't in the 
main, anywhere near up to date, but problems notified are quickly fixed 
and help is at hand if asked for.

On 09/05/19 08:44, Rob Landley wrote:
> On 5/8/19 5:12 PM, scsijon wrote:
>> So we can expect toybox to be fully llvm/clang compatable soon, or is it already
>> so now.
> 
> Fully for a while now. Android's been building it with llvm for years now, and
> the Android NDK I've been testing with has been llvm for as long as I've had it
> working.
> 
> Android started using clang something like 2013, and switched to building
> _everything_ with clang in the "N" release. That was a release or two back now:
> 
> https://blog.linuxplumbersconf.org/2016/ocw/system/presentations/3681/original/LPC16%20-%20AOSP%27s%20switch%20to%20Clang(2).pdf
> 
>> I also want to try some of the smaller ones like pcc and tcc with
>> toybox,
> 
> I was trying both of those for a while, but I stopped.
> 
> I was maintaining my own tcc fork to try to teach it to build real things,
> including (at the time) busybox and the kernel. It doesn't do dead code
> elimination, without which it'll at _best_ suck in the whole of lib/*.c even for
> "true". (Grischka is a windows developer, he doesn't care about Linux much that
> I've seen. He told me he didn't understand my todo items, and I'm unaware of any
> of the stuff I was working on making any progress since
> http://landley.net/code/tinycc/ .)
> 
> Feel free to poke at pcc. I'm still subscribed to their mailing list but it's
> like 3 posts/month...
> 
>> for me gcc is getting too big and complicated for a compiler, it's time
>> they considered archiving out some of it to an external component.
> 
> Richard Stallman explicitly rejected that approach 20 years ago.
> 
>    https://gcc.gnu.org/ml/gcc/2000-01/msg00572.html
> 
> GCC being a giant tangled hairball was a DESIGN GOAL to prevent it from becoming
> modular so the front-end and back-end could be decoupled and replaced with code
> under a different license. (Which is how llvm was initially developed anyway:
> there was a gcc front-end and then clang was written to replace it. So
> stallman's policy hurt gcc without preventing what he was afraid of.)
> 
> Note that llvm development started when gcc went gplv3. Just like Apple wrote
> its own samba replacement when samba went gplv3. There's no such thing as "the
> GPL" anymore and the fragmented pieces seem unlikely to outlive the generation
> of developers that grew up using it back when there _was_ a single unified GPL.
> 
> But in the meantime, we've gotta suffer through maintaining or interfacing with
> legacy software until y2k or y2038 or whatever knocks it out...
> 
> Rob
> 
> (I do wonder if y2038 will be an excuse to replace a lot of legacy GPL software
> the same way Y2K was an excuse to replace so much legacy cobol. If so, what's
> replacing the Linux kernel? 19 years left to figure that out, I suppose...)
> 
And Algol, Plan, Modula2 and most of the fortran around then, ....

regards to all
scsijon