From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1349 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Hello Date: Sun, 22 Jul 2012 22:01:38 -0400 Message-ID: <20120723020138.GE544@brightrain.aerifal.cx> References: <25387.50.0.229.11.1342998565.squirrel@lavabit.com> 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: dough.gmane.org 1343008927 19206 80.91.229.3 (23 Jul 2012 02:02:07 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 23 Jul 2012 02:02:07 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1350-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jul 23 04:02:07 2012 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 1St7yI-0007Ry-06 for gllmg-musl@plane.gmane.org; Mon, 23 Jul 2012 04:02:06 +0200 Original-Received: (qmail 3155 invoked by uid 550); 23 Jul 2012 02:02:05 -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 3147 invoked from network); 23 Jul 2012 02:02:04 -0000 Content-Disposition: inline In-Reply-To: <25387.50.0.229.11.1342998565.squirrel@lavabit.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1349 Archived-At: On Sun, Jul 22, 2012 at 07:09:25PM -0400, idunham@lavabit.com wrote: > I've been getting a little impatient waiting to see if anything happens, > so I started going through orc's patch and revising it. Sorry, I've had fairly little in the way of contiguous blocks of time to work on stuff over the past few weeks. Trying to catch up a bit... I need to look back at the archives but it seems a lot of this patch was about getting glibc binaries to run with musl. Can we break the efforts to integrate it down into 3 steps: 1. Linux API-level stuff musl should be supporting regardless of glibc compatibility. 2. glibc-compatibility symbols that need to be exported to get high-demand binary blobs (like video drivers) working. 3. Additional glibc-compatibility symbols, which may or may not be wanted/needed/desirable in the long term, and which we can at least defer addressing for a while. > 1. It still applies cleanly. Good. :-) > 2. __sigsetjmp is only added on x86(_64). > While looking at arm, I noticed that x86/mips gas uses @function while arm > uses %function...is there a reason for this? I think it's just a difference in the asm syntax rules for different targets. They're all very inconsistent... > 3. splice() is added to fcntl.h with _GNU_SOURCE, but needs (s)size_t; > what I did was add > #ifdef _GNU_SOURCE > #define __NEED_size_t > #define __NEED_ssize_t > #endif > > above where alltypes.h was included. Looks correct. > >> > - rawmemchr() was taken from uClibc > (I'm temporarily dropping that part...) > >> > - ioperm() and iopl() were not necessary to make glxgears work, just > >> > added them because Xorg will want them > >> > Probably you will want to add: > >> > - weak_aliases for __underscores > >> > >> Except most of them should be in the opposite direction. Especially > >> for functions like strxfrm_l where we'll eventually want the ISO C > >> "foo" function to depend on the POSIX "foo_l" function, the latter > >> will need its real name to be the __-prefixed version. > Are there any of these that should not be the other way around? Need to review again... Rich