[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 6 Jul 2012 14:06:01 +0800
From: orc <orc@...server.ru>
To: musl@...ts.openwall.com
Subject: Re: Hello
On Thu, 5 Jul 2012 19:34:57 -0400
Rich Felker <dalias@...ifal.cx> wrote:
> On Fri, Jul 06, 2012 at 01:24:17AM +0800, orc wrote:
> > On Thu, 7 Jun 2012 23:31:41 -0400
> > Rich Felker <dalias@...ifal.cx> wrote:
> >
> > > > So there is a question: will musl support this configs? Or I
> > > > will need patchelf and 'libc6-legacy' for them?
> > >
> > > It's intended to work, but I don't know whether it does yet.
> >
> > Did some research there last days: for, example, one that
> > proprietary drivers that nvidia ships it was required about 30
> > missing symbols, half of them are one-liners system calls, 5 were
> > glibc-specific functions that were easy to add (one of them is
> > gnu_get_libc_version() that is designed to return a plain string),
> > 4 were missing math functions that already defined as a macros in
> > math.h, rest is a forest of weak aliases around already existed
> > functions (plus two aliases to objects). That allowed me to run
> > plain unmodified X11 applications (not even gtk2 ones) and
> > accelerated glxgears without errors (The gtk2 or qt or other such
> > libraries compiled against glibc is not my target, just to prove
> > that userspace nvidia could be run with musl). If you interested, I
> > can put a patch that adds such forest of weak_alias'es to improve
> > (partly) glibc compatibility. And separate patch for missing
> > syscall wrappers.
>
> I'm very interested in this. I'm surprised it was that easy to make it
> work, and just curious about all the aliases that were involved and
> whether they make since or whether they're hacks. Post patches or a
> report in whatever form you prefer; I'll review it and hopefully it
> can be committed without much additional fuss.
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
Probably you will want to add:
- weak_aliases for __underscores
- weak_aliases __funcname_internal
- rawmemchr() (probably your own implementation, not uClibc one)
- some missing syscalls (I really misguessed number of needed syscalls,
seems that this was a number of aliases, not syscalls)
glibc-specific functions and objects required to make glxgears work:
- dlvsym() (wrapper around dlsym(), we don't need ugly symvers)
- gnu_get_libc_*()
- 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)
- 4 function-wrappers in math code: __isnan(), __isnanf(), __isinf(),
__isinff()
- __xmknod()
- _IO_2_1_stdout_ -> stdout
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).
>
> Rich
Download attachment "musl-0.9.2-misc-symbols.patch" of type "application/octet-stream" (15832 bytes)
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.
