[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120620152938.6073a08b@sibserver.ru>
Date: Wed, 20 Jun 2012 15:29:38 +0800
From: orc <orc@...server.ru>
To: musl@...ts.openwall.com
Subject: Re: Hello
On Thu, 7 Jun 2012 23:18:31 +0800
orc <orc@...server.ru> wrote:
> On Thu, 07 Jun 2012 15:13:38 +0200
> John Spencer <maillist-musl@...fooze.de> wrote:
>
> > On 06/07/2012 02:01 PM, orc wrote:
> > > I'm not a developer, sorry (I have a basic-to-middle C knowledge
> > > enough to understand why build fails), but still can help in areas
> > > of application compatibility, testing and cross-compiling. Anyone
> > > interested?
> > >
> > hello,
> > as described on the webpage, the most helpful work you can do
> > additionally to what you suggested is
> > - spread the word
> > - file bug reports against upstream software bugtrackers/maillists
> > (such as the missing includes you encountered)
> > - convince people not to use gnulib / gnu autocrap / cmake
> > - you could help sabotage linux to get a proper X11 setup so that
> > one could start to use musl on the desktop
> > see https://github.com/rofl0r/sabotage
> > if you want to look into that, i think its most helpful to look at
> > the buildscripts alpine linux uses.
> > -- JS
>
> Okay, thanks for pointing the direction.
> I already have X11 stuff in my TODO list for the musl-enabled system,
> but now I feel it will just fail without any results with huge error
> logs.
> And I already see the X11 stuff in the sabotage tree. Does it builds
> correctly?
> At this time I think to take an older X release without some stuff I
> don't need. X11R7.6 build requires python and weird xml libs for
> example. Maybe even XFree86 (to test it in qemu for the micro desktop
> system project).
Some news from that point.
I spent some time building the same X11 tree as my host system uses
(X11R76) and now I can say that it works almost unmodified with musl
0.9.1. Some notes about it:
- all libs compiled normally except xcb and Mesa. XCB deals with XML
and python that I did not installed, Mesa depends on g++.
(Unfortunately all X libs have now rpath hardcoded, thanks to
libtool's idiotic behavior. Oh.)
- apps compiled normally (some failed due to unset CFLAGS, was too lazy
to fix the build.sh)
- xorg-server-1.11.2:
- did not linked with musl 0.9.1 (missing ioperm() and iopl()
syscall wrappers, added manually).
- It doesn't wants to build DRI extensions just because dri.pc
does not exist (silly).
- Needs to fix certain glibc-only assumptions, like selecting
fgetln() instead of getline() and fixing nonexistent __uid_t
and __gid_t defines.
Finally, Xfbdev works, Xorg server (vesa) works (but needs some help
with module loading in xorg.conf). There was minor bug in libpciaccess,
it used sscanf() with format string that relied on glibc-specific
behavior.
My goal was not to run Xfbdev server, but (unmodified) original Xorg
server, for use on desktop systems. Now I can confirm that this is
possible with musl.
Requirements:
All the X11 stuff from bloated X11R76 release requires only pkg-config,
fontconfig and it's dependencies, libpng, pixman and intltool (that
required perl for XML-Parser and gettext).
Resulting X11 tree is about 200M in size (after 'strip -pg'), huge as a
whole my test rootfs.
I'll test the rootfs on some real x86_64 machine later, to see if Xorg
server is slow due to missing features or it is just QEMU/kvm issue.
After that I will proceed to see how some gui libraries and apps are
compatible with musl :-)
(If anyone already has X11 with musl, ok, just ignore this message)
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.
