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
_______________________________________________
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
