From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6225 Path: news.gmane.org!not-for-mail From: Timo Teras Newsgroups: gmane.linux.lib.musl.general Subject: Re: A running list of questions from "porting" Slackware to musl Date: Wed, 1 Oct 2014 09:29:29 +0300 Message-ID: <20141001092929.37c9e16c@vostro> 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 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1412145012 18217 80.91.229.3 (1 Oct 2014 06:30:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Oct 2014 06:30:12 +0000 (UTC) Cc: musl@lists.openwall.com To: Weldon Goree Original-X-From: musl-return-6238-gllmg-musl=m.gmane.org@lists.openwall.com Wed Oct 01 08:30:07 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 1XZDQN-0004dm-04 for gllmg-musl@plane.gmane.org; Wed, 01 Oct 2014 08:30:07 +0200 Original-Received: (qmail 5817 invoked by uid 550); 1 Oct 2014 06:30:06 -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 5809 invoked from network); 1 Oct 2014 06:30:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=QqKC6gVLOPsYji9kuYy5hQhJKEJD+L9md7md7WVSJeU=; b=Y/JwqKvIN+oUNhwI6LondbZas3tLuoFTLVlZbNnaIu5iGllMT0r4o8p36EBiwr+L25 vXgM90RPRw6tGvTxQG5ewhQ+JOi0DJNOqIgES+wxP7Fw4vortkldLJUyOkwQ7SmpKwo/ IyW9Q17oPLDnpKyU1BqoUEqsXdF+NybQTGf4Gn+K/3GTNyukkXekUALu4tfNi/VgrGq5 1iaXBO2+JosIzgQYMUD5lsO1EmmEZPh5HZf4I26wI3JIhpma6NIwCxDdVYELqiPAiRRg 3nQWMwioQt0NC5DP1Aj296cCfomK27IrtjfdN8pt2GWIxpLiu2oX0o2kzcSUekBFN0t/ kocw== X-Received: by 10.153.6.11 with SMTP id cq11mr17688250lad.55.1412144995028; Tue, 30 Sep 2014 23:29:55 -0700 (PDT) Original-Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= In-Reply-To: <542AA579.2040304@langurwallah.org> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.23; x86_64-alpine-linux-musl) Xref: news.gmane.org gmane.linux.lib.musl.general:6225 Archived-At: 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 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