[Slackbuilds-users] Is anybody doing musl?

[John Vogel]

On Sat, 19 Jul 2014 10:51:04 +0530
Weldon Goree <weldon at langurwallah.org> wrote:

> 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.
A good point. I have avoided this issue in my current work by only using
the static library.
> 
> 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).
You might like to take a look at musl's configure script. It uses i?86)
case string value to convert all included to i386.
> 
> 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.
I have been following the 1.1.x branch, so I'm a bit biased on this point.
> 
> 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.
I'm not sure about right and wrong here, but I think the danger of breaking
the toolchain or even the system by getting the two c libraries intermixed
is an important concern. This is why I prefer to use static linking for
musl binaries on builds where the system is glibc based. I usually install
to /opt/musl.
> 
> 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...)
I agree that having the loader symlink placed in /lib$LIBDIRSUFFIX and
pointing into a possible mount point is not a good plan. I also think that
running system shared binaries that are not based on the base system's
main c library a too fine line to walk for my taste. I walk on enough thin
ice often enough to know better than to jump up and down on the cracks.
> 
> 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).
Have you tried using musl-cross (https://bitbucket.org/GregorR/musl-cross)?
That might be another approach and might be a safer installation.
> 
> Thanks,
> Weldon
> 
> 
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - http://slackbuilds.org/faq/
>