You might be interested if you...:
-Want to build static binaries for linux on supported architectures
-want a small libc that doesn't break the abi regularly (vs uclibc)
-want full standard conformance, rather than "we pick how much of the standard we follow"

Building it:
There are two options: as a cross-compiler, or migrating the system.
If you migrate, you'll want to read the documentation included. I can supply some details, but that's for a later post.

1. Compile and install musl, preferably from git head (a release is a tag, not a branch, so all fixes are in git).

Code:

git clone git://git.etalabs.net/musl

-Copy config.mak from dist/ and adjust as you want.
You may want to disable the shared library.
(PREFIX defaults to /usr/local/musl, and should not be set to /, /usr, or /usr/local without following the documentation on migrating)

2. Get the linux kernel headers (linux-libc-dev, not the ones for building modules) and put them somewhere (I use /opt/musl/lin)
There should be a linux/ subdirectory in the directory you install the headers in.

3. export CC=musl-gcc; export CFLAGS="-Os -static -fno-stack-protector -I/opt/musl/lin -D_GNU_SOURCE"
Don't forget the -D_GNU_SOURCE - most stuff won't build without that, though some will. -I/... should point to the linux headers.
(Note-the linux headers are needed for OSS and a lot besides)

4. Now run configure and make.

If you want to discuss anything related to musl, feel free to use this thread.

Bookmarked for further reference.
This should be under "Cutting Edge" - interesting stuff here
I haven't tried musl, but I suppose it will compile busybox just fine?_________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

Bookmarked for further reference.
This should be under "Cutting Edge" - interesting stuff here
I haven't tried musl, but I suppose it will compile busybox just fine?

Much of Busybox.
You must install the kernel headers and point it at them (-I/opt/musl/lin)
Also, you need to disable NFS, unless you've built tirpc (RPC support is mandatory for NFS). I remember some other stuff I turned off, too...

Busybox won't build without -D_GNU_SOURCE, IIRC. You might also need -Wl,-z,muldefs -- but probably won't with any recent musl release.

Long story short: I got a static busybox binary that does anything most people need, in ~700 kilobytes. That includes vi, ash, init, and mdev, so you can boot to a shell with no other binaries.

I've also built gcc 3.4 (there were some breakages in gcc 4.x), make 3.81, ncurses 5.9, vim 7.3, m4 from netbsd 4.0, zlib, wireless-tools 30pre9 (which is harder to do...), and a few other packages.

This is my attempt at building dnsmasq as 32-bit executable under 64-bit environment.

1. I installed musl (0.9.0) - I added "-m32" to config.mak as directed. Everything went well. The build is *much much* faster than building uclibc using buildroot.
2. Unpacked dnsmasq, and did the export as indicated in the first post - fail. Looking at the output, I see it called gcc instead musl-gcc - so I passed CC and CFLAGS through make instead:

4. Went smoothly until it tried to compile log.c, then failed - cannot find _PATH_LOG. This is defined in bits/syslog-path.h, but /opt/musl/include/bits doesn't have this. I just add _PATH_LOG to dnsmasq's config.h and compilation continued and finished.
5. But it failed at link step - saying that it skipped libc.a when searching -lc. This would not happened if I compiled for 64-bits, so I added LDFLAGS=-m32 to the make file, which now looks like this:

This is where I stopped. grep -Ril capset /opt/musl/* told me there is a definition of capset in bits/syscall.h, but there is none in the libs.

EDIT:
7. I edited dnsmasq.c to remove all references to capset and capget, and the compile ended successfully. I ended up with 172k stripped dnsmasq static 32-bit binary that runs successfully within my 64-bit system - but now I need to test it that my removal of capset/capget doesn't upset it too much . The size compares favorably, my stripped *dynamic* 64-bit dnsmasq is 176k

EDIT: It works.

This capset/capget thing seems to be linux specific, and the POSIX version of the same stuff is implemented in libcap, however it can also be found in glibc (at least it seems to, I may be wrong).

Questions:
1. I'm sure the above is not the only one, so the general question is: as I understand it musl strives to be POSIX-compliant (not Linux compliant), however it also strives to be a glibc replacement. musl already implements _GNU_SOURCE, what about compatibilities at this level? Unfortunately, compatibility support == bloat

2. Assuming:
- not trying to cross-compile (not as above)
- not trying to migrate the whole system
- building a static binary
How does libs compiled with musl co-operate with libs compiled with glibc? Let's say I already have a libxxxx compiled with glibc (let say openssl's libssl). Will this work with musl - i.e. if I use musl-gcc and include does -lssl (pointing to the appropriate -L) - will this work? Probably not, I suppose.
If not, then I need to compile openssl again and install it on, say, /opt/musl/openssl, and make sure that all my compiles use that version of libgtk+, no?_________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

4. Went smoothly until it tried to compile log.c, then failed - cannot find _PATH_LOG. This is defined in bits/syslog-path.h, but /opt/musl/include/bits doesn't have this. I just add _PATH_LOG to dnsmasq's config.h and compilation continued and finished.
...
6. All went well - except that ld cannot find capset/capget.

This is where I stopped. grep -Ril capset /opt/musl/* told me there is a definition of capset in bits/syscall.h, but there is none in the libs.

EDIT:
7. I edited dnsmasq.c to remove all references to capset and capget, and the compile ended successfully. I ended up with 172k stripped dnsmasq static 32-bit binary that runs successfully within my 64-bit system - but now I need to test it that my removal of capset/capget doesn't upset it too much .
Questions:
1. musl already implements _GNU_SOURCE, what about compatibilities at this level? Unfortunately, compatibility support == bloat

2. Assuming:
- not trying to cross-compile (not as above)
- not trying to migrate the whole system
- building a static binary
How does libs compiled with musl co-operate with libs compiled with glibc? Let's say I already have a libxxxx compiled with glibc (let say openssl's libssl). Will this work with musl - i.e. if I use musl-gcc and include does -lssl (pointing to the appropriate -L) - will this work? Probably not, I suppose.
If not, then I need to compile openssl again and install it on, say, /opt/musl/openssl, and make sure that all my compiles use that version of libgtk+, no?

Removing capset/capget is most likely to be a security issue--they allow checking and dropping permissions in a more grnular way than setuid/seteuid.
Don't use grep -Ril --you will be very thoroughly fooled, until you actually look at the file. Here it's only SYS_capset and _NR_capset that are defined.
Currently musl is NOT ABI compatible with glibc; you will have to recompile everything. Substantial chunks of glibc headers are nonstandard, and aren't defined in musl yet.

If you report a missing function that breaks some program to the musl mailing list (refer to http://www.etalabs.net/musl/community.html), it may well be added, occasionally even the same day. This is what I mean by "responsive". I'd use a subject like
"Compatability: cap{set,get} needed for dnsmasq"
(identify that the issue is compatability, name functions, and name the program you're trying to build.)
The goal seems to be "enough glibc compatability for most software to work".

The "appropriate" -L is likely to be -L/usr/include, which will massively break everything.
I presume the "libgtk+" was a typo?
You can install in any prefix where there aren't glibc-based libraries.
In other words, if the musl prefix is /opt/musl, you can use that as the prefix for all the libraries, and musl-gcc will find them all.

I've confirmed this, sent an email to the musl mail-list with patches for the first two issues (missing header, add _PATH_LOG to syslog.h when _(GNU|BSD)_SOURCE is defined)
And the patches are committed in the bsd branch of my repo (github.com/idunham/musl).

Removing capset/capget is most likely to be a security issue--they allow checking and dropping permissions in a more grnular way than setuid/seteuid.

Yes.

Quote:

Don't use grep -Ril --you will be very thoroughly fooled, until you actually look at the file. Here it's only SYS_capset and _NR_capset that are defined.

That's just a quick way to check stuff; if grep -Ril returns negative the the symbol is definitely not there. But you are right; I did check the file afterward.

Quote:

Currently musl is NOT ABI compatible with glibc; you will have to recompile everything. Substantial chunks of glibc headers are nonstandard, and aren't defined in musl yet.

Yes, I must not be thinking when I asked this question. When libs are compiled they include constants and symbols and pointer offsets etc that come from the libc; and these will be different between glibc and musl. So everything must be re-compiled (and stored elsewhere) even if all I want to do is making a static binary out of it.

Quote:

If you report a missing function that breaks some program to the musl mailing list (refer to http://www.etalabs.net/musl/community.html), it may well be added, occasionally even the same day. This is what I mean by "responsive". I'd use a subject like
"Compatability: cap{set,get} needed for dnsmasq"
(identify that the issue is compatability, name functions, and name the program you're trying to build.)
The goal seems to be "enough glibc compatability for most software to work".

Superb !

Quote:

The "appropriate" -L is likely to be -L/usr/include, which will massively break everything.

Which I tried and as you said - breaks everything (didn't even compile).

Quote:

I presume the "libgtk+" was a typo?

Yes - was using libgtk+ for example, then changed my mind and change to libssl, but obviously I didn't replace all the references.

Quote:

You can install in any prefix where there aren't glibc-based libraries.
In other words, if the musl prefix is /opt/musl, you can use that as the prefix for all the libraries, and musl-gcc will find them all.

Thank you, this is what I need to know. I want to avoid appending extra -L and -I unless it's really necessary. I suppose this will also work with packages using pkg-config? I probably have to append /opt/musl to PKG_CONFIG_PATH?

I will try to compile a few others and see how far I get.

EDIT: removed comment about in_systm.h, I see you have raised that on the mailing list too.

pkg-config seems designed to break cross-compiles.
if you use it, any packages missing for the cross-compiler and present for the host will get picked up...again, instant breakage.

I guess you need PKG_CONFIG_LIBDIR; set it to the directory containing .pc files in /opt/musl (probably /opt/musl/lib/pkgconfig, but some packages use oddball directories...)

capset & capget apparently belong in libcap; it seems glibc supports the symbols for backwards compatibility, and hasn't had it in headers since 1999 or so.. Rich doesn't think much of the "capabilities" approach, says it's mostly a false sense of security.

_PATH_LOG is used for some insane workaround for broken syslog daemons; looks like there should be an easy patch, though (change the SUN/ANDROID check to add !defined(_PATH_LOG).

I'm considering building a musl snapshot "SDK" of sorts.
Basically, it would have whatever's needed to start building against musl, installed in /opt/musl-09 .
Right now I think these would be what I'd start with:

musl
linux-libc-dev
ncurses (pdcurses is also an alternative, but I don't see a reason)
zlib
openssl
libcurl
libbz2
liblzma
libcap
libtirpc
libnl3

perl would be provided by the host, as would gcc and binutils (though I could just use pcc...); all parts except the Linux headers (which Torvalds appears to consider PD once sanitized) and libnl3 (LGPL) are PD, MIT, or BSD licensed, so strictly speaking don't require source (though I'd have that available).
But, OTOH, I'd be publishing the build-scripts and any patches...

I presume you mean github.com/idunham/musl ?
Probably not that one--I'm thinking of something more like /usr/src is on certain systems.
*If* I do an SDK, it would have a repo for the build environment, and then I'd have a binary download also available from that repo.
There's no good reason to build a musl libc binary package, without an environment--it takes maybe 2 minutes to build on an Atom, you need updates and bugfixes, and so on.
But if I distribute libnl3/pam, I need to distribute sources anyhow...

I was thinking along you'd post a build script on github.com/idunham/musl that will download source packages (the ones you've listed) and relevant patches to make it compile with musl; and compile it to some location (/opt/musl-09 is good) _________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

You guys feel free to invite the developers to join our forum. Explain to them how useful Puppy could be to a developer.

Most of them already have their own projects/distros ...
I'm aware of about 20 people using it, though there may be more.
I also know of at least 3 small distros that use it (jhuntwork's LightOS, Sabotage Linux which has as many git repos as users, bootstrap-linux which may not be commonly used, but can recompile itself with only 6 packages)
Openwall GNU/*/Linux is going to switch to musl at some point.

musl has an IRC channel (#musl on freenode) and a mailing list.
Also, I'm not sure the Puppy way/philosophy is acceptable to many of them...

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum