top | item 9791709

How to compile C apps with musl and Clang

79 points| Procedural | 10 years ago |procedural.github.io | reply

49 comments

order
[+] vezzy-fnord|10 years ago|reply
The more awareness musl gets, the better. See also Sabotage Linux, a musl-based distro: https://github.com/sabotage-linux/sabotage
[+] buserror|10 years ago|reply
There is also my own 'minifs' https://github.com/buserror/minifs ; it's targeted at embedded, but it works fine on x86s too. Haven't ported it to musl yet (mostly due to the fact that musl wasn't yet merged into crosstool-NG) but that's high on my list.

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.

[+] andolanra|10 years ago|reply
There's also Void Linux, which has musl and glibc versions of packages and offers both musl-based and glibc-based download images: http://www.voidlinux.eu/
[+] esjeon|10 years ago|reply
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

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|10 years ago|reply
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?

[+] wtallis|10 years ago|reply
I think you'd be surprised at how much variation there is in the feature set. libc isn't just the C standard library as defined by the language standard. It's the OS standard library too, and includes POSIX stuff and some de facto standard stuff and some OS-specific stuff. The musl author has a comparison table: http://www.etalabs.net/compare_libcs.html

Historically, the biggest reasons for alternate libcs have been to make tradeoffs for use on embedded systems (uClibc) or political/license differences.

[+] vezzy-fnord|10 years ago|reply
Here's an article from the musl wiki that explains differences from glibc: http://wiki.musl-libc.org/wiki/Functional_differences_from_g...

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/

[+] laichzeit0|10 years ago|reply
One use case is embedded systems. The code space available can vary from a few kilobytes to a few mbs as well as memory overhead. Sometimes you won't even pull an entire library with even though it's small, you'll statically link in only the functions you used.
[+] gct|10 years ago|reply
Must everything be an "app"? Whatever happened to programs or god forbid unabbreviated applications
[+] IshKebab|10 years ago|reply
Programs were called apps long before the iphone.
[+] stefanmielke|10 years ago|reply
Did someone acessed the website through mobile? I can't go past the title.

Edit: Using an iPad 2.

[+] aninteger|10 years ago|reply
It works fine on the default "older" web browser on the Samsung S4.
[+] justincormack|10 years ago|reply
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|10 years ago|reply
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|10 years ago|reply
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.

[+] aninteger|10 years ago|reply
There is pcc which looked like it had a chance for a while. There was at least a lot of excitement from the OpenBSD and NetBSD communities a while ago. I know it was imported but then I think it was removed. Development continues on but at a slower pace.
[+] ksherlock|10 years ago|reply
Have you tried using the plan 9 [from user space] c compiler?
[+] sriku|10 years ago|reply
Seems impossible to read the article on an iphone.