How to compile C apps with musl and Clang
procedural.github.io
procedural.github.io
"Simple. Small. Secure." right next to "ISO 298MB."
I know I'm getting old when people think a 298MB system is simple, small, or secure. Lol...
One thing minifs does is that it has a 'cross linker' took that jettisons every piece of code/library that is not actively linked by executable; also, instead of installing everyone's crap everywhere, I build the distro the other way around, and 'pick and chose' the bits that packages need until they work.
This isn't perfect, but kinda works (even with autoconf). I also tried to add musl support into LLVM/clang, but I've been too busy recently, and won't be able to work on it for a while.
A side note: Clang is such a beauty whose structure is so easy to understand yet very extendible. There are actually few things to be done on clang to support musl. Just implement a proper frontend, and you're mostly done. But it's kinda difficult to patch codes which assume glibc, and the fact that musl refuses to export __MUSL__ macro makes the job even harder.
Support for multiple archs is of course a valid source for percieved bloat, but that should matter only at compile time?
Historically, the biggest reasons for alternate libcs have been to make tradeoffs for use on embedded systems (uClibc) or political/license differences.
And also the toxic maintainership of glibc in the Drepper era.
All the bugs discovered by musl, and how many are glibc-related: http://wiki.musl-libc.org/wiki/Bugs_found_by_musl
If you want to know why someone would want to replace glibc, then I give you a challenge: figure out how glibc implements printf(3). Good luck.
The answer is: http://blog.hostilefork.com/where-printf-rubber-meets-road/
http://queue.acm.org/detail.cfm?id=2349257
Makes me wish systems like Oberon got famous instead lol...
And yes, that PHK op ed is well known. It's been posted here before, though if I have to be honest PHK messes up his nomenclature, even if his points are mostly correct.
No Oberon, but maybe we can at least get some good capabilities like EROS if the work on Capsicum goes through.
So yeah, there's still hope for UNIX. Looks like that hope goes two ways:
1. UNIX variants like DragonFly that intentionally break things or get rid of crud to better themselves over time.
2. People on such projects who stumble onto superior architectures while looking for improvements and start building a better non-UNIX.
I'll keep checking up on it to see what happens.
It has maintained strict ABI compatibility since glibc 2.0, released in 1996; a lot of functions have multiple different implementations with versioned symbols, just so existing binaries built against older versions continue to run.
Naturally all of this compatibility gunk does not lend itself to simple and maintainable code; perhaps call all of that accidental complexity "the tax of the UNIX philosophy".
In practice, the only platforms that really use it are GNU/Linux and GNU/Hurd. Even Android uses Bionic libc. Though I guess there's also novelty projects like GNU/kFreeBSD.
perhaps call all of that accidental complexity "the tax of the UNIX philosophy".
I don't know why anyone would call it that.
Edit: here's the list of supported platforms, from the 1.09 tarball:
alpha-dec-osf1
i386-bsd4.3
i386-force_cpu386-none
i386-gnu (for Hurd development only)
i386-isc2.2
i386-isc3
i386-sco3.2
i386-sco3.2v4
i386-sequent-bsd
i386-sysv
i386-sysv4
i960-nindy960-none
m68k-hp-bsd4.3
m68k-mvme135-none
m68k-mvme136-none
m68k-sony-newsos3
m68k-sony-newsos4
m68k-sun-sunos4
mips-dec-ultrix4
mips-sgi-irix4
sparc-sun-solaris2
sparc-sun-sunos4
It was a tongue in cheek remark, given how projects that don't want to pay that tax get accused of being in violation of said philosophy :-)
The BASIC, Pascal, Modula-2, and Ada code looked much less hacked together even when it was portable or old. Still looked weird & dated but more readable. So, like one commenter said, it's also because of C. It's design and culture lead people on the path of much dirty hackery to... implement a printf statement.
Note: Situations like this argue for real macros and metaprogramming like in LISP. A pseudo code of what each aspect does plus its implementation would make it more comprehensible.
The /other/ problem is that most of the time spent fixing build issues is never fixing actual code; most of the time is spent trying to go around these autocrap tools failing to work as intended, and as the article describes, it's a nightmare.
All the while, with a bit of care, you can build most programs with a half page makefile, with very little problems; in fact, very often when I've banged my head for a while trying to fix an autotool nigthmare, that's exactly what I do!
All the bugs discovered by musl, and how many are glibc-related:
The page doesn't say how they were found. By building test suites during the creation of musl? Do conformance suites not already exist?? Or were these (hypothesized) tests just more rigorous?
musl's printf is more clean than glibc's, no question, but it does less though. Only because I've wasted time to look at many of them, it doesn't look bad, but it just doesn't look great either. glibc's is really ugly for 2 big reasons, it has extra sweeteners and then it does some exotic looking shit to try and be fast. I'd probably grok musl's faster but I'd not want to jump in and hack on either of them or debug them.
Some non-canonical constants, stdout instead of STDOUT.. It's a nit, but I remember at least 2 major TLS holes in the last 18 months that were pretty much a result of non-canonical C style; it's a dangerous thing when you do it and start to collaborate.
It looks clean enough from 10,000 feet, and I do admire the competition and welcome it, but it's just another collection of relatively undocumented stuff that implements some mildly exotic performance optimizations, just like glibc, only it doesn't support nearly as many platforms. It means everything in the world if you've run into a glibc bug, I get that, but it's amazing how few people have done that. Both could really benefit from a detailed and complete set of "how and why" documentation...
Edit: Using an iPad 2.
LLVM/Clang is a step in the right direction but it's quite bloated because of support for C++, Objective-C etc (for C standards at least); not to mention it's written in C++.
Being a Python/C hybrid enthusiast, I looked into taking something like Eli Bendersky's pycparser and making it featureful (preprocesser parsing at the minimum), but haven't done anything in that direction. Maybe some way of combining pycparser and tcc.
Sure, that means it has some legacy bits that need to be supported, but to some degree that's the price of having a mature codebase.
Having compiled LLVM and rooted through its internals trying to implement a plugin, it looks pretty well-architected and internally consistent. Codebases that cover as much as LLVM+Clang do being that clean is a rare sight, IMO. And it's not slow.
Many C devs love to hate C++. I guess is something like some C++ devs love to hate Java. It's a bit of a heritage issue :)
C++ does the job for me... it's is almost as powerful as it is complicated but I find that a fair trade off (YMMV)
First, I assume this is a musl thread, so I'm assuming C++ people might not be interested in it in the first place (I'd be surprised if C++ communities discuss the bloat of glibc let alone seeking its minimal C alternatives like musl instead of going for C++ solutions like boost and what not).
Second, having hung around people who discuss the bloat of glibc, and strive for white-box and minimalism, of which musl is a result (this includes, but not limited to, communities like suckless, and cat-v.org), speaking of musl and clang in the same line would be odd at the least, considering clang is ~600k+ lines of C/C++, when there is a C-only tcc compiler at ~60k+, so it's likely clang is doing something (a lot of things) that C programmers have no interest in.
Although I should admit these minimalist C communities might not have a good opinion of Python either (that's one of my personal interests).
I'm not sure how well maintained those backends are, and I've read TCC isn't really stable enough to use in production, between the incomplete x64 backend and just general bugs... Solving those may yet push TCC a fair bit beyond 60k LOC.
OpenBSD decided against it.