Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 30 Sep 2014 21:35:57 +0530
From: Weldon Goree <>
Subject: Re: A running list of questions from "porting" Slackware to

On 09/30/2014 09:16 PM, Rich Felker wrote:
> 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.

Nor I, but I've tried it with all the permutations of older gettext 
versions and no gettext versions, and several GNU programs fail to link 
if they aren't told to --disable-nls. I'm not a programmer, just a 
sysadmin, and I'm interested in musl because it might make my life 
easier in the future, but I'm in no place (yet) to figure out what I've 
done wrong.

> I don't think gcc/ld search /lib when linking, so putting
> 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/ symlinks to /lib/ or
> similar.

When I cross-compile a native gcc it "wants" the linker to be in /lib 
(or I should say, Gregor's patches tell it to look for the symlink in 
/lib, and my being a sysadmin tells me that whatever /lib/ld-foo links 
to should not be in /usr because I do have to boot my server occasionally).

> 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.

Granted: my slackware port doesn't use musl-gcc, but I'm maintaining the 
community port of musl for slackware-gnu users too.

>> 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.

I'll look into it. xorg was happy with the stub lib they wrote years ago 
so I haven't looked past that because it did what I needed; that was 
more out of curiosity.

> 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. should not exist, and
> libssp.a should be an empty .a file (ar rc libssp.a to make it).

RPM is the candidate this time; I only need it to build rpm2cpio to get 
the linuxdoc sources (I found a workaround), but it also took some 
finagling to get Perl to stop "helping" me by adding -f-stack-protector. 
This was again a point of curiosity.


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.