
How to compile C apps with musl and Clang - Procedural
https://procedural.github.io/How-to-compile-C-apps-with-musl-and-Clang/
======
vezzy-fnord
The more awareness musl gets, the better. See also Sabotage Linux, a musl-
based distro: [https://github.com/sabotage-
linux/sabotage](https://github.com/sabotage-linux/sabotage)

~~~
raphaelss
There's Alpine Linux too:
[http://www.alpinelinux.org/](http://www.alpinelinux.org/)

~~~
nickpsecurity
I'll check out these distro's in the near future. I at least got a laugh out
of what I saw on alpine's homepage:

"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...

~~~
jzelinskie
The Alpine Linux docker image is only a couple megabytes[0]. There are quite a
few people (including myself) using it as a light-weight OS for their
containers.

[0]: [https://github.com/gliderlabs/docker-
alpine](https://github.com/gliderlabs/docker-alpine)

~~~
nickpsecurity
Now _that_ is more like it!

------
esjeon
I've been digging musl + clang too. Here's my wrapper script that I use to
compile a number of projects: [https://github.com/esjeon/musl-
clang](https://github.com/esjeon/musl-clang)

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.

------
mschuster91
Excuse the noob question, but why are there different libc implementations at
all? I mean, their featureset is defined by standard, so all implementations
should strive for the maximum performance - so where comes the bloat from?

Support for multiple archs is of course a valid source for percieved bloat,
but that should matter only at compile time?

~~~
vezzy-fnord
Here's an article from the musl wiki that explains differences from glibc:
[http://wiki.musl-
libc.org/wiki/Functional_differences_from_g...](http://wiki.musl-
libc.org/wiki/Functional_differences_from_glibc)

All the bugs discovered by musl, and how many are glibc-related:
[http://wiki.musl-libc.org/wiki/Bugs_found_by_musl](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://blog.hostilefork.com/where-printf-rubber-meets-road/)

~~~
nickpsecurity
Omg that was a great article on printf. I had more Wtf's than I've had in a
while despite how many times I've called out C and UNIX implementations for
their complexity. Here's another good one in return:

[http://queue.acm.org/detail.cfm?id=2349257](http://queue.acm.org/detail.cfm?id=2349257)

Makes me wish systems like Oberon got famous instead lol...

~~~
vezzy-fnord
There's still hope for Unix, if DragonFly BSD is any measure. A shame no one
feels the need to follow its lead.

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.

~~~
nickpsecurity
I'll have to update myself on DragonFly in near future. Good that you know
about EROS and Capsicum: ahead of most ;). Check out CheriBSD on CHERI
processor if you like that. Far as software, JX Operating System and GenodeOS
are two clean-slate one's with architectures you might find interesting.
Interesting in terms of foundations to build better stuff on.

~~~
vezzy-fnord
Oh yeah, there was a talk about CheriBSD at this year's BSDcan. Gotta look
more into it. GenodeOS looks fascinating from first glance. I'm aware of the
various JVM-based OSes, but I have no personal interest in them. Thanks
anyway.

------
gct
Must everything be an "app"? Whatever happened to programs or god forbid
unabbreviated applications

~~~
IshKebab
Programs were called apps long before the iphone.

------
stefanmielke
Did someone acessed the website through mobile? I can't go past the title.

Edit: Using an iPad 2.

~~~
aninteger
It works fine on the default "older" web browser on the Samsung S4.

------
justincormack
You will after a bit run into issues using Musl with a wrapper script, in my
experience, and you are better off using a Musl based distro. You can run one
in a chroot, I used to use Sabotage like that quite a bit, or if you use
Docker you can just use "FROM alpine" and everything will be nice and
statically linked, or you can do an install in a VM.

------
fizixer
musl is great, but it would great if there was something at the compiler level
that is better than both gcc and LLVM/Clang.

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.

~~~
koko775
What's wrong with being written in C++? It's a high-level, fast language with
higher-level abstractions and better typesafety than C and decades of
expertise built up around it.

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.

~~~
fizixer
Nothing wrong with C++ per se, if you're a C++ programmer.

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).

~~~
Sanddancer
Part of those 600k lines of code come in the form of various things that tcc
doesn't do -- things like loop unrolling, support for SSE, support for
architectures other than intel-based, support C11, etc. So, you end up with a
compiler that is significantly slower and less useful than the clang suite. So
while there are things the C community wouldn't support, like other languages,
there are quite a few things that the C community would consider vital these
days.

~~~
Solarsail
As a (mostly ignorable) sidenote, TCC does support a couple of non-intel ISAs.
At least 4-5k LOC beween arm-gen.c and C67-gen.c, compiled from an IR
[https://github.com/LuaDist/tcc/blob/master/il-
opcodes.h](https://github.com/LuaDist/tcc/blob/master/il-opcodes.h) If this
repository's anything to go by:
[https://github.com/LuaDist/tcc](https://github.com/LuaDist/tcc)

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.

------
GFK_of_xmaspast
Real classy sample program there.

------
sriku
Seems impossible to read the article on an iphone.

