[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 Sep 2014 18:13:37 +0530
From: Weldon Goree <weldon@...gurwallah.org>
To: musl@...ts.openwall.com
Subject: A running list of questions from "porting" Slackware to musl
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
