Re: Hello

[Rich Felker <dalias@aerifal.cx>]

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