From: idunham@lavabit.com
To: musl@lists.openwall.com
Subject: Re: Hello
Date: Fri, 22 Jun 2012 21:43:13 -0400 (EDT) [thread overview]
Message-ID: <38795.132.241.65.253.1340415793.squirrel@lavabit.com> (raw)
In-Reply-To: <20120620152938.6073a08b@sibserver.ru>
> On Thu, 7 Jun 2012 23:18:31 +0800
> orc <orc@sibserver.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.
___________________________________________________________________________
next prev parent reply other threads:[~2012-06-23 1:43 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-07 12:01 Hello orc
2012-06-07 13:13 ` Hello John Spencer
2012-06-07 15:18 ` Hello orc
2012-06-07 16:29 ` Hello John Spencer
2012-06-07 16:19 ` Hello Rich Felker
2012-06-07 17:15 ` Hello orc
2012-06-08 3:31 ` Hello Rich Felker
2012-06-08 5:49 ` Hello Isaac Dunham
2012-06-08 12:28 ` Hello aep
2012-06-08 14:14 ` Hello Rich Felker
2012-06-08 16:17 ` Hello aep
2012-06-08 16:11 ` Hello Rich Felker
2012-06-09 2:05 ` Hello Isaac Dunham
2012-07-05 17:24 ` Hello orc
2012-07-05 23:34 ` Hello Rich Felker
2012-07-06 6:06 ` Hello orc
2012-07-06 6:26 ` Hello Rich Felker
2012-07-06 8:22 ` Hello orc
2012-07-06 23:14 ` Hello idunham
2012-07-07 0:57 ` Hello Rich Felker
2012-07-07 8:07 ` Hello orc
2012-07-07 15:54 ` Hello idunham
2012-07-08 9:09 ` Hello orc
2012-06-07 17:45 ` Hello Christian Neukirchen
2012-06-07 18:03 ` Hello Jens Staal
2012-06-07 19:10 ` Hello John Spencer
2012-06-07 17:33 ` Hello Jens Staal
2012-06-07 17:59 ` Hello orc
2012-06-20 7:29 ` Hello orc
2012-06-23 1:43 ` idunham [this message]
2012-06-23 1:51 ` Hello Rich Felker
2012-06-25 12:09 ` Hello orc
2012-06-25 11:59 ` Hello orc
2012-06-25 13:53 ` Hello idunham
2012-07-22 23:09 Hello idunham
2012-07-23 2:01 ` Hello Rich Felker
2012-07-23 3:49 ` Hello idunham
2012-07-23 21:01 ` Hello Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=38795.132.241.65.253.1340415793.squirrel@lavabit.com \
--to=idunham@lavabit.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).