[Slackbuilds-users] Is anybody doing musl?

[Weldon Goree]

On 07/19/2014 02:24 AM, John Vogel wrote:
> 
> I would be interested in seeing what you have. I'm using musl for a project
> right now, so I'd be interested in giving your slackbuild a try.
> 

http://langurwallah.org/slackbuilds/musl.tar.gz

TL;DR: This puts the libs in /usr/$LIBDIR/musl, the inlcudes in
/usr/include/musl, musl-gcc in /usr/bin, and the loader
ld-musl-$ARCH.so.1 in /$LIBDIR with a symlink to it as
/usr/bin/musl-ldd. I could use some advice on /usr/lib vs. /lib for this.

I don't have a 32-bit machine lying around to test this on; in
particular I'm worried about $(ARCH) in musl's Makefile, which gets used
in the name of the ld-musl-$ARCH-so.1 symlink (and which I need to know
to make ldd; see below). If somebody could let me know what it does on
i486/i686 I'd really appreciate that (I have reasoned what it "should"
do, but that's always questionable).

It's currently set for 1.0.3 (the latest version of the stable branch),
but it works with 1.1.2 and 1.1.3 also. I'm talking with the upstream
about the life expectancy of the stable branch and it may be cut off in
the next couple of quarters, so it might be better to stick with the 1.1
branch.

Also, I may have done something the Wrong Way: doinst.sh needs to know
LIBDIRSUFFIX and ARCH in order to link usr/bin/musl-ldd to
lib$LIBDIRSUFFIX/ld-musl-$ARCH.so.1. I've never needed to know those in
a doinst.sh before, so I just copied the relevant lines from the
SlackBuild file. Or maybe I just shouldn't make the musl-ldd link to
begin with, since the upstream doesn't in the install.

Anyways, the big problem with having two C libraries is where to put the
two libc.so's and the system headers. I put them in
/usr/lib$LIBDIRSUFFIX/musl and /usr/include/musl. The musl-gcc.specs
file takes care of gcc finding those (assuming you use the
/usr/bin/musl-gcc wrapper), and the ld-musl* symlink is in
/lib$LIBDIRSUFFIX, so it doesn't take any loader magic to make it work.

(On that note: it's probably Broken and Wrong to have the loader in /lib
linked to the full library in /usr, in case early programs use this.
Should I make the main libdir /lib/musl instead? Or should I put the
loader in /usr/lib/musl? I don't like a slackbuild writing outside of
/usr and /etc by default, personally, but loaders really "want" to be in
/lib...)

Musl users often build a native or cross toolchain for it, too (you'll
need that if you want to use C++ at all, for example), but that takes
enough patching of gcc that it's probably not appropriate for SBo.
Binutils (> 2.23) works fine out of the box; a cross or native musl
binutils might be worth doing a slackbuild for some day.

So, please let me know if this works for you; once I hear back from musl
on the life expectancy I'll pick which branch to default to and submit
this, barring problems. In particular let me know if it craps out and
asks for -fno-toplevel-reorder in CFLAGS (I think that's limited to
cross toolchains, but just in case).

Thanks,
Weldon