[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120723020138.GE544@brightrain.aerifal.cx>
Date: Sun, 22 Jul 2012 22:01:38 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Hello
On Sun, Jul 22, 2012 at 07:09:25PM -0400, idunham@...abit.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
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.
