[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <38795.132.241.65.253.1340415793.squirrel@lavabit.com>
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.
