From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6215 Path: news.gmane.org!not-for-mail From: Weldon Goree Newsgroups: gmane.linux.lib.musl.general Subject: A running list of questions from "porting" Slackware to musl Date: Tue, 30 Sep 2014 18:13:37 +0530 Message-ID: <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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1412081104 32703 80.91.229.3 (30 Sep 2014 12:45:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Sep 2014 12:45:04 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6228-gllmg-musl=m.gmane.org@lists.openwall.com Tue Sep 30 14:44:59 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 1XYwna-00049y-NT for gllmg-musl@plane.gmane.org; Tue, 30 Sep 2014 14:44:58 +0200 Original-Received: (qmail 25888 invoked by uid 550); 30 Sep 2014 12:44:56 -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 25880 invoked from network); 30 Sep 2014 12:44:56 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.8.0 Xref: news.gmane.org gmane.linux.lib.musl.general:6215 Archived-At: 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