From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6218 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: A running list of questions from "porting" Slackware to musl Date: Tue, 30 Sep 2014 11:46:35 -0400 Message-ID: <20140930154635.GB23797@brightrain.aerifal.cx> References: <542AA579.2040304@langurwallah.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1412092017 23694 80.91.229.3 (30 Sep 2014 15:46:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Sep 2014 15:46:57 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6231-gllmg-musl=m.gmane.org@lists.openwall.com Tue Sep 30 17:46:53 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XYzdZ-0000sM-Dq for gllmg-musl@plane.gmane.org; Tue, 30 Sep 2014 17:46:49 +0200 Original-Received: (qmail 3342 invoked by uid 550); 30 Sep 2014 15:46:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 3333 invoked from network); 30 Sep 2014 15:46:48 -0000 Content-Disposition: inline In-Reply-To: <542AA579.2040304@langurwallah.org> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6218 Archived-At: 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