Weldon, i actually started building my own lfs with musl and i am currently contemplating my own distribution centered around my experiences in the IT field. Do you have a good source for building out a complete system capable of compiling? Im currently working on a minimal build environment using Busybox, Bash, Linux-Headers, Musl, Make, Binutils, Glibc (with dependent math libs)  And i am capable of building a working system however when you test it the compiled files (a.out) are not working even after verifying they are executable (chmod +x)

any thoughts?

On Tue, Sep 30, 2014 at 8:43 AM, Weldon Goree <weldon@langurwallah.org> wrote:
Hi all,

I added the quotation marks of shame because it's not a "port" in a real sense. But still: I've had this side project[1] for a while of porting Slackware to use Musl and it's Nearly There (tm), but I was hoping for some advice on some persistent irritations I have. (Sorry for the length.)

1. error.h. I've worked around most uses of this (where I didn't decide to simply delete the "else" branch) with a stub liberror (another list user suggested an actually functional musl-friendly liberror which I should probably integrate at some point). Still, I'd always like to hear other ideas. Kbd in particular remains problematic, though it at least compiles (which means it ships!).

2. NLS. Yeah, NLS. I realize this is still currently a moving target (and a very impressive one so far) on musl, so I've been adding --disable-nls or --with-gettext=no or whatever to the build scripts as a matter of course, but I'd like to hear what progress other musl users have made on this front. Can someone who "gets" this explain to a simpleton why gettext linked against musl doesn't present a libintl.so that behaves like client applications expect? (In particular the symbol 'libintl_gettext' seems to not exist. Bonus points: why does libintl.h belong to the C library rather than gettext?)

2a. ${LIBDIR}/charset.alias. GNU software seems to love to make this file, and it only seems to be made when gettext is unhappy (though gettext devs seem to blame this on iconv, which I don't even use). It's similar to /usr/share/info/dir, in that subsequent packages are supposed to append to it, but appending is the bane of package management. I've altered my makepkg script to just delete it when it's found, but I'm curious if anybody knows a way to tell GNU tools they really don't have to make it. (This isn't really about musl, but other musl users have probably run into this.)

3. Is there a set of configure options for musl that would let me have libc.so in libdir, ld-musl-${ARCH}.so.1 in syslibdir, and *crt* in $(something else)? I would ideally like libc.so in /lib, the loader in /lib, and the crt files in /usr/lib, but a general solution would be appreciated. (Particularly one that "talks to" musl-gcc.specs, though I don't use that for this project). (This is literally just about my laziness in packaging gcc, so I won't be hurt if nobody suggests anything...)

4. Is Pth a lost cause?

5. Not meaning to start another round of spam against the gnulib team: I seem to have had good luck with findutils by simply ripping out their gnulib dir and updating it from the beta find. Does anybody have any caveats from having done this? (Bonus points: what in particular about fseeko makes it so difficult?) The only other option seems to be sabotage's "we will shoot gnulib files in the face" method, which I admit is emotionally satisfying. (../../../gnulibfix lib/ > cflags FTW)

6. Stack protection. This one really puzzles me. Stack protection is as alien to glibc as it is to musl, but I keep running into this. 90% of the problems can be avoided with adding -fno-stack-protector appropriately, but libtool is very "helpful" on matters like this and seems to find a way to put it back. I've actually not found an unworkable problem yet (though several very annoying ones); I guess I'm just curious what the real state of ssp on musl is (I'm not a fan of the concept, personally, but I know a lot of people are), and whether there's a general solution to just telling software to trust the ****ing stack.

7. Dynamic linking. In assembling muslack I've been leaning a lot on the shoulders of the giants who came before me. But in all that I keep running into static linking. Snowflake does some dynamic linking, and Sabotage submits to it when necessary (perl, etc.) but I don't know of a musl-based distro that dynamically links like "normal" people do. Does anybody know of one I can shamelessly steal from?

8. Finally: thanks to everybody on this project and on this list; I've really enjoyed the year since I read about musl on a random reddit comment.

Any thoughts would be appreciated,
Weldon

[1] http://muslack.org