[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120706062614.GS544@brightrain.aerifal.cx>
Date: Fri, 6 Jul 2012 02:26:14 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Hello
On Fri, Jul 06, 2012 at 02:06:01PM +0800, orc wrote:
> Here a patch, attached. It contains both missing syscalls and weak
> aliases. It does not contain glibc-specific stuff (if you want, I can
> send it too, but it looks ugly, intended only for 'run it
> successfully'). Some notes about:
> - rawmemchr() was taken from uClibc
> - ioperm() and iopl() were not necessary to make glxgears work, just
> added them because Xorg will want them
> - I don't think libc even needs xattr stuff, but glibc includes them.
> On many systems they are usually duplicated, libattr provides same
> interface
> - It seems that every function in src/locale needs it's __underscore
> alias, to match glibc api
> - there some ugly __funcname_internal aliases, don't know why glibc
> defines them in that way
I think most of this is an artifact of some hacks they do in the glibc
headers for inlining/optimization and/or _FORTIFY_SOURCE support.
The functions it creates references to are not (AFAIK) in the LSB ABI
and thus binaries using them are non-LSB-conforming...
> 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.
> - weak_aliases __funcname_internal
These are rather ugly and stupid, but seem harmless.
> - rawmemchr() (probably your own implementation, not uClibc one)
Indeed, I'll want to copy the existing fast code from strchr.
> - some missing syscalls (I really misguessed number of needed syscalls,
> seems that this was a number of aliases, not syscalls)
These look mostly fine, but the header changes are all wrong (the
declarations are not under _GNU_SOURCE control).
> glibc-specific functions and objects required to make glxgears work:
> - dlvsym() (wrapper around dlsym(), we don't need ugly symvers)
Ugly because it needs to be written in asm and adds a useless per-arch
asm function. Perhaps we could just have dlvsym be a weak alias to
dlsym in the existing asm files...
> - gnu_get_libc_*()
return "not glibc";
> - malloc_usable_size() (returns 0 always, probably there is no code in
> musl to make it work. Definition in eglibc was cryptic for me, but it
> clearly seems to be the glibc/ptmalloc feature)
return (*((size_t *)ptr - 1) & -2) - 2*sizeof(size_t);
> - 4 function-wrappers in math code: __isnan(), __isnanf(), __isinf(),
> __isinff()
Reasonable to add; perhaps even more efficient than the current
approach.
There's also that function named "finite" whose name violates the
namespace and thus it cannot be in a common source file with other
stuff that could be needed by conformant code.
> - __xmknod()
Ugly but this should be added; it's analogous to the __xstat junk.
> - _IO_2_1_stdout_ -> stdout
Very ugly, but shouldn't break anything...
> gtk2 will not work that way, I checked. One library in chain requires
> libstdc++, libstdc++ defines 'unique' symbols (see manual page of
> binutils nm) which musl linker cannot handle. Additionally, there is
> much more missing symbols including missing functions. But plain X11
> apps worked (I checked xfontsel and xlogo).
Have you looked into building the apps/libs natively against musl
except for the nvidia binary blob, to see if the blob works under that
usage? I think that's a usage case that's a lot more applicable to
real-world usage of musl, and in fact it's probably the first real
reason anybody would be interested in having musl work with code that
was built against glibc...
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.
