[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 1 Oct 2014 09:29:29 +0300
From: Timo Teras <timo.teras@....fi>
To: Weldon Goree <weldon@...gurwallah.org>
Cc: musl@...ts.openwall.com
Subject: Re: A running list of questions from "porting" Slackware to
musl
Hi,
I'm writing on behalf of Alpine Linux, as I did most of the integration
work for musl there.
On Tue, 30 Sep 2014 18:13:37 +0530
Weldon Goree <weldon@...gurwallah.org> wrote:
> 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!).
We generally have patched these out. Would probably be nice to have this
in musl, or as an add-on library. Then again, some projects seem to
have stopped using error.h because of portability issues to BSD and
other OSes.
> 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?)
gettext can be compiled in two modes: "use libc gettext" or
"ship libintl gettext".
In musl 1.0 we removed gettext from musl. Currently we just remove
libintl.h from musl-dev and use libintl's version when needed. We build
only specific set against libintl-dev; so most packages in Alpine do not
get nls enabled due to missing libintl.h.
We plan to start using musl's libintl.h and remove gettext's libintl
later.
> 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.)
This is due to gnulib. It does this if it does not find glibc. We did
not bother to fix gnulib, but are just removing it manually before
packaging. Would probably be good to fix gnulib.
> 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...)
Like Rich mentioned the option in other mail, it is done in Alpine
Linux. The direction of the libc.so and symlink is changed. ld-musl is
the real file, and libc.so is the symlink.
IIRC, the primary reason was to keep libc.so and libc.a both
in /usr/lib, and have ld-musl in /lib. If the .so and .a are in
different paths we got trouble with gcc. I think glibc this works
because the libc.so in /lib is versioned (as-in libc.so.1.2.3) and
libc.so symlink to that is in /usr/lib or similar.
> 4. Is Pth a lost cause?
Yes. It's evil, don't spend time on it. Only gpg 2.0.x uses that, and
they remove it for gpg 2.1.x. It'll use npth. npth is slightly ugly too
but at least that works.
> 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)
It's because findutils has ancient gnulib. Seems gnulib is causing more
trouble then fixing with musl. The most unintrusive patch we came with
is at:
http://git.alpinelinux.org/cgit/aports/tree/main/findutils/fix-gnulib-freadahead.patch
Seems upgrading gnulib is tedious. Though, we had to do it one package
(or possibly two) and the diffs are huge.
> 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
tmu> 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.
Alpine ships libssp_nonshared.a:
http://git.alpinelinux.org/cgit/aports/tree/main/musl/APKBUILD#n66
Doing it like this means you also need to compile gcc with libssp
disabled. See:
http://git.alpinelinux.org/cgit/aports/tree/main/gcc/APKBUILD#n272
IIRC, Gcc's libssp is supposed to provide that normally, but it breaks
horrible because it does not properly detect libssp in musl and has
glibc specific hacks. As musl has full libssp functionality (in terms
what gcc code generation requires) with the exception of this
libssp_nonshared.a, it felt simplest to add it to Alpine's musl
packaging for the time being.
IIRC, this is architecture dependant if it's really needed or not. We
had long discussion and the end result was that gcc should really ship
that function in linkonce section and not depend on external library.
> 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?
As mentioned before, we build almost all in Alpine dynamically linked.
Feel free to look at what we do.
/Timo
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.
