Date: Fri, 22 Jun 2012 21:43:13 -0400 (EDT) From: idunham@...abit.com To: musl@...ts.openwall.com Subject: Re: Hello > On Thu, 7 Jun 2012 23:18:31 +0800 > orc <orc@...server.ru> wrote: >> 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). Are these wrappers available somewhere online (in a git tree or something)? > - It doesn't wants to build DRI extensions just because dri.pc > does not exist (silly). DRI is for HW acceleration, and is provided by Mesa. > - Needs to fix certain glibc-only assumptions, like selecting > fgetln() instead of getline() and fixing nonexistent __uid_t > and __gid_t defines. I've been working (occasionally) on an "uncdef" script to fix this sort of problem. What I'd like to do longterm is provide something that can automatically generate a patch (copy the tree, change, save diff). > 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. Anything X is slow wth Qemu, between the graphics layer and the emulation--I've seen 20-second lag times with twm on netbsd (on kvm, AMD Neo @1.6GHz host), while a PIII @800 MHz is reasonably usable. Try using the VNC interface, it's much faster (but still slow). > After that I will proceed to see how some gui libraries and apps are > compatible with musl :-) Snowflake Linux has GTK2 + Xfce, I've heard of GTK1.2, I know meh, jwm, mupdf, mtpaint, etc. build (not sure about patches, just saw sizes listed). > (If anyone already has X11 with musl, ok, just ignore this message) Only Xfbdev/Xnest yet AFAICT. ___________________________________________________________________________
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.