[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140930154635.GB23797@brightrain.aerifal.cx>
Date: Tue, 30 Sep 2014 11:46:35 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: A running list of questions from "porting" Slackware to
musl
On Tue, Sep 30, 2014 at 06:13:37PM +0530, Weldon Goree 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.)
A good source of information, in general, is the patches from Sabotage
Linux and Alpine Linux.
> 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!).
Yes, error.h has been an ongoing topic that wasn't really resolved.
> 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?)
Like glibc, musl supports the gettext API natively. There is no need
for libintl and it should not be installed. libintl.h is just the
header for the gettext API.
I'm not sure what's happening with symbol names in your libintl. I
suspect it was either built incorrectly or has some invalid glibc
assumptions, but I know other users (even Alpine Linux) have used it
successfully with musl in the past, before musl had 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.)
I've seen this but I just ignore it; I never really looked into the
cause.
> 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.
I don't think gcc/ld search /lib when linking, so putting libc.so
there (and not having it in /usr/lib) would probably leave things
broken. If the core issue is that you want the actual file on /, you
could swap the direction of the symlink (make ld-musl the real file)
or make both ld-musl and /usr/lib/libc.so symlinks to /lib/libc.so or
similar.
> (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...)
If you're "porting" the whole system to build against musl, you
shouldn't need the musl-gcc wrapper, and in fact you're going to have
a hard time using it as soon as you try to build C++ software. You
really want a native compiler toolchain that supports musl. See the
musl-cross project for the necessary patches to GCC.
> 4. Is Pth a lost cause?
Yes. But there's a new portable pth (sorry, couldn't resist) in the
works that several projects (iirc gnupg) are eagar to switch to, since
pth is so bad and has no future (it's incompatible with programs that
use real threads, and likely with most/all future systems). It's
API-compatible but based on pthread so it works anywhere. No idea what
the status is, though.
> 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)
Yes, updating gnulib is a good idea. Actually gnulib documents a way
to update in-tree without "ripping out" the old one first, but I don't
recall the details.
> 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.
I'd need more context to know what, if anything, you're doing wrong,
or if the packages you're compiling just insist on using stack
protector. In any case having it on should not break anything, but you
may need libssp_nonshared.a (from a gcc natively targeting musl) for
ssp to link right in shared libraries. libssp.so should not exist, and
libssp.a should be an empty .a file (ar rc libssp.a to make it).
> 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?
Alpine. But there shouldn't be any particular difficulty to dynamic
linking; in fact it's done by default by GCC when possible.
Rich
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.
