Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 204755 - app-emulation/emul-linux-x86-xlibs-20071230 opengl crashes X with Intel 965GM chipset
Summary: app-emulation/emul-linux-x86-xlibs-20071230 opengl crashes X with Intel 965GM...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: AMD64 Linux
: High normal with 1 vote (vote)
Assignee: AMD64 Project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: emul-tracker 208904
  Show dependency tree
 
Reported: 2008-01-07 14:35 UTC by Mark Glines
Modified: 2009-12-27 10:41 UTC (History)
14 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Mesa ebuild multilib build support (mesa.ebuild.diff,4.14 KB, patch)
2008-05-28 00:22 UTC, Steven Newbury
Details | Diff
Mesa ebuild patch to enable multilib build support (mesa.ebuild.diff,3.99 KB, patch)
2008-05-28 23:49 UTC, Steven Newbury
Details | Diff
Mesa ebuild patch to enable multilib build support (fixed) (mesa.ebuild.diff,4.09 KB, patch)
2008-05-29 00:10 UTC, Steven Newbury
Details | Diff
Mesa ebuild patch to enable multilib build support (really fixed and cleaned up) (mesa.ebuild.diff,4.08 KB, patch)
2008-05-29 04:37 UTC, Steven Newbury
Details | Diff
Mesa live ebuild drop in replacement for the x11 overlay mesa (mesa-9999.ebuild,9.09 KB, text/plain)
2008-05-29 04:40 UTC, Steven Newbury
Details
Mesa ebuild patch to enable multilib build support (mesa.ebuild.diff,4.93 KB, patch)
2008-05-29 12:45 UTC, Steven Newbury
Details | Diff
Mesa ebuild patch to enable multilib build support (mesa.ebuild.diff,4.96 KB, patch)
2008-05-29 12:51 UTC, Steven Newbury
Details | Diff
Mesa live ebuild drop in replacement for the x11 overlay (mesa-9999.ebuild,9.72 KB, text/plain)
2008-05-29 22:15 UTC, Steven Newbury
Details
libdrm multi-lib ebuild (libdrm-9999.ebuild,3.70 KB, text/plain)
2008-06-28 14:09 UTC, Steven Newbury
Details
multilib libdrm 2.3.1 (libdrm-2.3.1-r1.ebuild,3.83 KB, text/plain)
2008-09-08 13:41 UTC, Bernd Buschinski
Details
multilib mesa 7.1 (mesa-7.1-r1.ebuild,9.81 KB, text/plain)
2008-09-08 13:42 UTC, Bernd Buschinski
Details
multilib libdrm-2.4.1 (libdrm-2.4.1.ebuild,3.93 KB, text/plain)
2008-11-12 21:34 UTC, Bernd Buschinski
Details
multilib mesa-7.2 (mesa-7.2.ebuild,9.90 KB, text/plain)
2008-11-12 21:36 UTC, Bernd Buschinski
Details
multilib mesa-9999 (i810 -> intel) (mesa-9999.ebuild,9.76 KB, text/plain)
2008-11-25 16:40 UTC, Bernd Buschinski
Details
fix epatch (mesa-9999.ebuild,9.76 KB, text/plain)
2008-12-01 22:56 UTC, Bernd Buschinski
Details
multilib mesa-9999 (check for broken overlay) (mesa-9999.ebuild,9.84 KB, text/plain)
2009-01-02 13:42 UTC, Bernd Buschinski
Details
multilib mesa-7.3 (mesa-7.3.ebuild,9.80 KB, text/plain)
2009-02-13 13:36 UTC, Bernd Buschinski
Details
multilib libdrm-2.4.4 (libdrm-2.4.4.ebuild,3.78 KB, text/plain)
2009-02-13 13:38 UTC, Bernd Buschinski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Glines 2008-01-07 14:35:04 UTC
32-bit applications which use opengl crash my X server horribly, with the following error in Xorg.0.log:

Error in I830WaitLpRing(), timeout for 2 seconds
pgetbl_ctl: 0x3ff80001 pgetbl_err: 0x0
ipeir: 0 iphdr: 80200004
LP ring tail: e9b0 head: 4028 len: 1f001 start 0
Err ID (eir): 0 Err Status (esr): 1 Err Mask (emr): ffffffdf
instdone: ffe5fafd instdone_1: fffff
instpm: 0
memmode: 0 instps: 8001e022
HW Status mask (hwstam): fffecffe
IRQ enable (ier): 82 imr: fffe0000 iir: 1040
acthd: 1000ce08 dma_fadd_p: 1000cf00
ecoskpd: 307 excc: 0
cache_mode: 6800/180
mi_arb_state: 44
IA_VERTICES_COUNT_QW 0/0
IA_PRIMITIVES_COUNT_QW 0/0
VS_INVOCATION_COUNT_QW 0/0
GS_INVOCATION_COUNT_QW 0/0
GS_PRIMITIVES_COUNT_QW 0/0
CL_INVOCATION_COUNT_QW 0/0
CL_PRIMITIVES_COUNT_QW 0/0
PS_INVOCATION_COUNT_QW 0/0
PS_DEPTH_COUNT_QW 0/0
WIZ_CTL 0
TS_CTL 0  TS_DEBUG_DATA fdd3f7dd
TD_CTL 0 / 0
space: 87664 wanted 131064

FatalError re-entered, aborting
lockup


X then gets stuck in a loop of crashing, restarting, crashing again.  A hard reset is required at this point.

When I downgrade to emul-linux-x86-xlibs-10.1, opengl works.  (Some other apps break because of a missing libexpat.so.0, but that's unrelated.)  When I upgrade back to emul-linux-x86-xlibs-20071230, the crashes occur again.  So I believe it to be a bug in one of the libraries contained in 20071230.

To reproduce, run a 32-bit app which makes heavy use of opengl, on an amd64 machine with an i965GM chipset.  The main Darwinia screen crashes it, so does googleearth (after a few seconds), so does warzone2100 (once you convince it to compile, it needs a 32-bit libphysfs), and so does xscreensaver's "glschool" when you compile that with gcc -m32.

It is very consistent - glschool (-m32) runs perfectly 5 times in a row with emul-linux-x86-xlibs-10.1, and crashes horribly 5 times in a row with emul-linux-x86-xlibs-20071230.  glschool compiled natively runs fine.  If it helps, native glschool links against the following libs:

media-libs/mesa-7.0.2
sys-libs/glibc-2.7-r1
x11-libs/libdrm-2.3.0
x11-libs/libICE-1.0.4
x11-libs/libSM-1.0.3
x11-libs/libX11-1.1.3
x11-libs/libXau-1.0.3
x11-libs/libXdamage-1.1.1
x11-libs/libXdmcp-1.0.2
x11-libs/libXext-1.0.3
x11-libs/libXfixes-4.0.3
x11-libs/libXmu-1.0.3
x11-libs/libXt-1.0.5
x11-libs/libXxf86vm-1.0.1

I'm having difficulty finding reliable information on the net about this.  It is related to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432110 and http://bugs.freedesktop.org/show_bug.cgi?id=9415#c7 and http://forums.gentoo.org/viewtopic-p-4603379.html?sid=1f323c67190dc1b1af4ed288293cb604 , but in my case, it only happens when I start a 32-bit opengl app.  (And then it happens quite quickly).  I tried playing with xorg.conf and xf86-video-intel versions, with no effect.  Downgrading emul-linux-x86-xlibs is the only thing I could find that made a difference.


Portage 2.1.4_rc14 (default-linux/amd64/2007.0, gcc-4.2.2, glibc-2.7-r1, 2.6.23.12 x86_64)
=================================================================
System uname: 2.6.23.12 x86_64 Intel(R) Core(TM)2 Duo CPU T7100 @ 1.80GHz
Timestamp of tree: Mon, 07 Jan 2008 01:30:01 +0000
ccache version 2.4 [enabled]
app-shells/bash:     3.2_p33
dev-java/java-config: 1.3.7, 2.1.3
dev-lang/python:     2.4.3-r4, 2.5.1-r4
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.4-r7
sys-apps/baselayout: 1.12.10-r5
sys-apps/sandbox:    1.2.18.1-r2
sys-devel/autoconf:  2.13, 2.61-r1
sys-devel/automake:  1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.18-r1
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool:   1.5.24
virtual/os-headers:  2.6.23-r3
ACCEPT_KEYWORDS="amd64 ~amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=nocona -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/udev/rules.d"
CXXFLAGS="-march=nocona -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="ccache distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="http://gentoo.osuosl.org/"
LANG="en_US.UTF-8"
LINGUAS="en"
MAKEOPTS="-j4"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /usr/local/portage-overlay/layman/catalystframework /usr/local/portage-overlay/layman/gentoo-de /usr/local/portage-overlay/layman/zugaina /usr/local/portage-overlay/layman/sunrise /usr/local/portage-overlay/layman/philantrop"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X a52 aac acl acpi adns agg aio akode alsa amd64 amr ansi aotuv apache2 arts asyncns atlas avahi avi bash-completion berkdb bitmap-fonts bluetooth bzip2 cdda cddb cdinstall cdio cdparanoia clamav cli cpanplus cpudetection cracklib crypt cups curl dbus dga divx4linux dri dts dv dvb dvd dvdnav dvdread effects emerald enca encode esd ethereal exif exscalibar fbcon fbdev ffmpeg fftw firefox flac flash foomaticdb fortran gcc4 gdbm gif gimp glib glitz glut gnome gphoto2 gpm gps gstreamer gtk gtk2 gvim hal hou hpn httpd iconv id3 id3tag ifp imap ipod ipv6 ipw4965 isdnlog ithreads jpeg jpeg2k kerberos kqemu kvm lame libcaca libgda libsamplerate lirc live lzo mad madwifi matroska md5sum mdnsresponder-compat midi mikmod mjpeg mmx mmxext mng mod modperl modplug mono mozdevelop mozilla moznoirc mozsvg mp2 mp3 mp3id3 mp4 mpeg mplayer mpm-worker mtp mudflap musepack musicbrainz nativecode ncurses netjack network nfsv4 normalize nptl nptlonly offensive ofx ogg oggvorbis openal opengl openmp pam pcmcia pcre pdf perl plugins png pnm pnp ppds pppd pulseaudio python qemu quicktime quotes readline reflection rsync rtc rtp rtsp ruby samba scanner scim sdl server session shout skins slp sndfile sockets sou spamassassin speex spell spl sqlite sqlite3 srt sse sse2 ssl startup-notification stream subtitles svg swf tcltk tcpd theora threads tiff tordns truetype truetype-fonts type1-fonts uim unicode upnp usb v4l v4l2 vcd vdr vhosts vorbis vorbis-psy wavpack x264 xanim xcomposite xine xinerama xml xml2 xorg xpm xv xvid xvmc zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" LIRC_DEVICES="devinput" USERLAND="GNU" VIDEO_CARDS="i810"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 1 Mark Glines 2008-01-07 17:36:53 UTC
Quick update: if I install emul-linux-x86-xlibs-20071230 and then copy in the /usr/lib32/dri/i965_dri.so from emul-linux-x86-xlibs-10.1, everything works.  The crash I was getting is somehow triggered by this library.
Comment 2 Mark Wagner 2008-01-30 03:39:18 UTC
(In reply to comment #1)
> Quick update: if I install emul-linux-x86-xlibs-20071230 and then copy in the
> /usr/lib32/dri/i965_dri.so from emul-linux-x86-xlibs-10.1, everything works. 
> The crash I was getting is somehow triggered by this library.

Is the bug report at https://bugs.freedesktop.org/show_bug.cgi?id=14130 related?
Comment 3 Mark Glines 2008-02-05 14:23:06 UTC
(In reply to comment #2)
> (In reply to comment #1)
> 
> Is the bug report at https://bugs.freedesktop.org/show_bug.cgi?id=14130
> related?

The Xorg.log trace looks the same, but the method of reproduction is different.   To reproduce it here, all I have to do is start a 32-bit opengl app and wait for a few seconds - no extra steps are necessary.

I just tried, and I cannot reproduce a crash using 64-bit "mplayer -vo gl" and hiding it behind another "always on top" window, the way they described (in comment #3 of that bug).
Comment 4 Peter Tworek 2008-04-02 11:55:20 UTC
I can confirm this bug. On my amd64 laptop with intel i965 GPU xorg will crash when using any opengl application (even glxgears). Upgrading to:
x11-base/xorg-server-1.4.0.90
media-libs/mesa-7.0.2
x11-drivers/xf86-video-intel-2.2.1
fixed the problem with 64bit opengl apps. 32bit apps with app-emulation/emul-linux-x86-xlibs-20080316 still crash xorg. The only solution I've found so far, is to compile my own 32bit mesa-7.0.2 and replace /usr/lib32/dri/i965_dri.
Comment 5 Steven Newbury 2008-05-27 15:26:59 UTC
(In reply to comment #4)
> I can confirm this bug. On my amd64 laptop with intel i965 GPU xorg will crash
> when using any opengl application (even glxgears). Upgrading to:
> x11-base/xorg-server-1.4.0.90
> media-libs/mesa-7.0.2
> x11-drivers/xf86-video-intel-2.2.1
> fixed the problem with 64bit opengl apps. 32bit apps with
> app-emulation/emul-linux-x86-xlibs-20080316 still crash xorg. The only solution
> I've found so far, is to compile my own 32bit mesa-7.0.2 and replace
> /usr/lib32/dri/i965_dri.
> 
Wouldn't it be better if the mesa ebuild built the 32bit drivers anyway rather than including them in emul-linux-x86-xlib?  That way they would be kept in sync with the mesa/xorg stack.
Comment 6 Mark Glines 2008-05-27 15:49:39 UTC
(In reply to comment #5)
> Wouldn't it be better if the mesa ebuild built the 32bit drivers anyway rather
> than including them in emul-linux-x86-xlib?  That way they would be kept in
> sync with the mesa/xorg stack.

I don't know.  Is mesa any different from any other library, in this regard?

The problem we seem to be having is, the versions contained within emul-linux-x86-xlibs do not match my USE flags or KEYWORDS.  It looks like the 20080316 package was built on a KEYWORDS=x86 platform, and thus, it got mesa-6.5.2-r1... mesa-7.0.2 is marked as ~x86.  And I cannot choose the 7.x version via package.keywords; the emul-linux-* package does not give me a choice.

Now, if there was an emul-linux-~x86-xlibs package, with KEYWORDS=~x86 versions of the libraries contained within, we could install that instead and the problem would be solved. :)

As it stands, it seems like the way to solve this is to get mesa-7.0.x marked as stable on x86, and then reissue the emul-linux-x86-xlibs package.

Mark
Comment 7 Steven Newbury 2008-05-27 16:56:03 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Wouldn't it be better if the mesa ebuild built the 32bit drivers anyway rather
> > than including them in emul-linux-x86-xlib?  That way they would be kept in
> > sync with the mesa/xorg stack.
> 
> I don't know.  Is mesa any different from any other library, in this regard?

I think it is.  The dri drivers are very dependent on the versions of other components, drm, xserver etc.  Really the 32bit and 64bit versions should be in sync with each other, otherwise there are no guarantees it's going to work, the ABIs do change fairly frequently.

The Mesa build machinery already supports --enable-32-bit and enable-64-bit as configure options so it would be very easy to do.  Actually, I'll implement a proof-of-concept and see how it goes...

> 
> The problem we seem to be having is, the versions contained within
> emul-linux-x86-xlibs do not match my USE flags or KEYWORDS.  It looks like the
> 20080316 package was built on a KEYWORDS=x86 platform, and thus, it got
> mesa-6.5.2-r1... mesa-7.0.2 is marked as ~x86.  And I cannot choose the 7.x
> version via package.keywords; the emul-linux-* package does not give me a
> choice.
This will keep happening, and it will get worse as new technologies are implemented, TTM, GEM, DRM modesetting etc.

> 
> Now, if there was an emul-linux-~x86-xlibs package, with KEYWORDS=~x86 versions
> of the libraries contained within, we could install that instead and the
> problem would be solved. :)
> 
> As it stands, it seems like the way to solve this is to get mesa-7.0.x marked
> as stable on x86, and then reissue the emul-linux-x86-xlibs package.
Yes, this will work until the ABIs change again...
Comment 8 Steven Newbury 2008-05-28 00:22:34 UTC
Created attachment 154545 [details, diff]
Mesa ebuild multilib build support

I've attached the changes I've made to get the mesa ebuild to build for both 32bit and 64bit ABIs.  Obviously this currently collides with emul-linux-x86-xlibs.
Comment 9 Steven Newbury 2008-05-28 00:35:01 UTC
(In reply to comment #8)
> Created an attachment (id=154545) [edit]
> Mesa ebuild multilib build support
> 
> I've attached the changes I've made to get the mesa ebuild to build for both
> 32bit and 64bit ABIs.  Obviously this currently collides with
> emul-linux-x86-xlibs.
> 
I've not added ppc64 support, but that's obviously very easy to do, since the ABI support is very generic (inspired by glibc's ebuild).  Any comments?

I do strongly feel this is the correct approach.  It certainly makes my life much easier since follow mesa/xorg development very closely.
Comment 10 Steven Newbury 2008-05-28 00:38:24 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > Created an attachment (id=154545) [edit]
> > Mesa ebuild multilib build support
> > 
> > I've attached the changes I've made to get the mesa ebuild to build for both
> > 32bit and 64bit ABIs.  Obviously this currently collides with
> > emul-linux-x86-xlibs.
> > 
> I've not added ppc64 support, but that's obviously very easy to do, since the
> ABI support is very generic (inspired by glibc's ebuild).  Any comments?
> 
> I do strongly feel this is the correct approach.  It certainly makes my life
> much easier since follow mesa/xorg development very closely.
> 
I've tested a few 32bit GL apps, they appear to work perfectly now.
Comment 11 Steven Newbury 2008-05-28 23:49:47 UTC
Created attachment 154653 [details, diff]
Mesa ebuild patch to enable multilib build support

The first version failed to install libGL.la, I've attached a new diff with this issue fixed.
Comment 12 Steven Newbury 2008-05-29 00:04:17 UTC
Sorry, that last diff is broken.  I'll post a new version in a few minutes.
Comment 13 Steven Newbury 2008-05-29 00:10:26 UTC
Created attachment 154655 [details, diff]
Mesa ebuild patch to enable multilib build support (fixed)
Comment 14 Steven Newbury 2008-05-29 00:13:58 UTC
(In reply to comment #13)
> Created an attachment (id=154655) [edit]
> Mesa ebuild patch to enable multilib build support (fixed)
> 

I'm so sorry about spamming this bug.  It still isn't fixed, I'll be more careful before I try again...
Comment 15 Steven Newbury 2008-05-29 01:51:19 UTC
Can someone help me out here?  I have cleaned up the patch since those attached to this bug, the second diff attached is closest to correct but like my current version merging fails with:

injecting /usr/lib32/libGL.so.1 into /var/tmp/portage/media-libs/mesa-9999/image/
Traceback (most recent call last):
  File "/usr/bin/ebuild", line 182, in <module>
    debug=debug, tree=mytree)
  File "/usr/lib64/portage/pym/portage/__init__.py", line 5143, in doebuild
    vartree=vartree, prev_mtimes=prev_mtimes)
  File "/usr/lib64/portage/pym/portage/__init__.py", line 5349, in merge
    mydbapi=mydbapi, prev_mtimes=prev_mtimes)
  File "/usr/lib64/portage/pym/portage/dbapi/vartree.py", line 2746, in merge
    mydbapi=mydbapi, prev_mtimes=prev_mtimes)
  File "/usr/lib64/portage/pym/portage/dbapi/vartree.py", line 2754, in _merge
    cleanup=cleanup, mydbapi=mydbapi, prev_mtimes=prev_mtimes)
  File "/usr/lib64/portage/pym/portage/dbapi/vartree.py", line 2116, in treewalk
    self._preserve_libs(srcroot, destroot, myfilelist+mylinklist, counter, inforoot)
  File "/usr/lib64/portage/pym/portage/dbapi/vartree.py", line 1790, in _preserve_libs
    for x in candidates:
RuntimeError: Set changed size during iteration

Why is portage trying to inject an invalid symlink into the image?  What am I doing wrong?
Comment 16 Steven Newbury 2008-05-29 02:06:11 UTC
Never mind.  It was because portage was trying to preserve the incorrect symlink from the previous broken installation.  The second diff above should work ok, but I'll attach a cleaned up version once I've tested everything is working.
Comment 17 Steven Newbury 2008-05-29 04:37:19 UTC
Created attachment 154661 [details, diff]
Mesa ebuild patch to enable multilib build support (really fixed and cleaned up)

Okay.  Final working version of the diff to the mesa ebuild is attached.  Note that I have it installing the libGL*.la files for both ABIs correcting the libdir in each case.  This should mean the fix to #67729 is now obsolete.

In the end the Mesa build system really didn't want to cooperate so I had to create a seperate build tree for each ABI.
Comment 18 Steven Newbury 2008-05-29 04:40:08 UTC
Created attachment 154663 [details]
Mesa live ebuild drop in replacement for the x11 overlay mesa
Comment 19 Steven Newbury 2008-05-29 12:45:21 UTC
Created attachment 154695 [details, diff]
Mesa ebuild patch to enable multilib build support

After feedback from Dan Nicholson on the xorg list I've changed the ebuild to not use --enable-32-bit and --enable-64-bit, but instead set the CHOST and CFLAGS to appropriate values manually instead.  Is powerpc- and powerpc64- correct for 32bit and 64bit ppc?
Comment 20 Steven Newbury 2008-05-29 12:51:36 UTC
Created attachment 154697 [details, diff]
Mesa ebuild patch to enable multilib build support

Missed CXXFLAGS
Comment 21 Mark Glines 2008-05-29 18:35:46 UTC
(In reply to comment #18)
> Created an attachment (id=154663) [edit]
> Mesa live ebuild drop in replacement for the x11 overlay mesa

This builds and runs fine for me.  I am able to run a 32-bit glschool (from the xscreensaver project) successfully, looks good, no crashes.

Mark
Comment 22 Steven Newbury 2008-05-29 22:15:57 UTC
Created attachment 154763 [details]
Mesa live ebuild drop in replacement for the x11 overlay
Comment 23 Steven Newbury 2008-05-29 22:16:55 UTC
Updated the attached ebuild to be in sync with the patch.
Comment 24 Steven Newbury 2008-05-30 12:05:06 UTC
As I alluded to above there has been a parallel discussion ongoing on the xorg mailing list:

On Thu, 2008-05-29 at 20:37 -0700, Donnie Berkholz posted to the xorg list:
> This is getting a little too Gentoo-specific, so I'd like to take any 
> further discussion to the bug. The basic idea is that we don't want to 
> build all the ABIs at once, because that requires specialized hacks in 
> every ebuild. We want to add support to Portage to build for arbitrary 
> ABIs and have them all installed simultaneously.
Has any work been done in that direction?  As we stand now, many amd64 users (most? what are the proportions between those running amd64, ~amd64 and live ebuilds? DRM versions?) systems will be broken at any one time when it comes to running 32bit GL software.  The ABIs that the Mesa drivers are anything but stable between versions.  There needs to be something done in the interim even if there is a long term goal to address multi-ABI systems from portage directly.

I have to admit I'm having trouble imagining how such support can be added to portage, we already have the multilib eclass which provides the necessary functions to make multilib ebuilds fairly trivial (standardising something like the src_compile() and src_install() functions I borrowed from the glibc ebuild would be a very useful addition), the only problem being lack of multilib awareness in the build systems of the software itself necessitating at worst the creation of shadow source trees (most autoconf software allows a separate objdir making this much easier).  I don't see portage wide support would address this issue - or are you suggesting keeping a separate portage pkg db for each ABI and working out some way of avoiding the conflicts? Personnaly I don't think it's much burden for ebuild maintainers of core libraries to have this support in place, especially if the multilib eclass is extended to make it easier and more transparent.
Comment 25 Mike Doty (RETIRED) gentoo-dev 2008-05-31 21:44:33 UTC
emul-* packages only contain stable versions, hence the version mismatch that was originally reported.

Xorg team: is this something you want to support?
Comment 26 Donnie Berkholz (RETIRED) gentoo-dev 2008-06-04 06:23:40 UTC
(In reply to comment #25)
> emul-* packages only contain stable versions, hence the version mismatch that
> was originally reported.
> 
> Xorg team: is this something you want to support?

I'm not very enthusiastic about these emul libraries, and I'd rather not get too close to them for fear of being infected. =)

If people are mixing stable and ~arch, I don't support that. It's unfortunate that no ~arch emul xlibs exists, so I'd encourage anyone interested to build it.
Comment 27 Steven Newbury 2008-06-28 14:09:10 UTC
Created attachment 158747 [details]
libdrm multi-lib ebuild

With changes made recently to the DRM ABI, libdrm also needs to be build for multilib.  Fortunately in this case autoconf sucessfully creates a configure that handles an separate objdir.
Comment 28 Mike Doty (RETIRED) gentoo-dev 2008-08-10 21:24:50 UTC
new emul-xlibs in the tree, it might help.
Comment 29 Mark Glines 2008-08-10 23:26:35 UTC
(In reply to comment #28)
> new emul-xlibs in the tree, it might help.

Hi!  Thanks for the update.  I just tried it, and unfortunately the crash is still there.

The new emul-xlibs package still contains mesa 6.5.2-r1.  I don't think this will be fixed until mesa-7.x is marked as stable on x86 (and an emul-xlibs update is issued which contains that version).
Comment 30 Steven Newbury 2008-08-12 12:05:42 UTC
(In reply to comment #29)
> (In reply to comment #28)
> > new emul-xlibs in the tree, it might help.
> 
> Hi!  Thanks for the update.  I just tried it, and unfortunately the crash is
> still there.
> 
> The new emul-xlibs package still contains mesa 6.5.2-r1.  I don't think this
> will be fixed until mesa-7.x is marked as stable on x86 (and an emul-xlibs
> update is issued which contains that version).
> 
This is always going to be a problem while the development rate of mesa/DRM is higher than the Gentoo stablisation process.  It's always going to be out of sync.  GEM has just hit the freedesktop.org git master branches for the intel driver, so that's going to be the next thing.
Comment 31 fow 2008-09-08 02:07:48 UTC
I've been following this bug for a while now, hoping for some resolution to these problems. For a while I haven't had too many problems, but there's one in particular I've encountered recently which I'm sure an experienced Gentoo dev could whip up a hack for it fairly easily. Every once in a while, I'll update the mesa-9999 and libdrm-9999 to try and keep up with the changes. Now in updates I have a recurring error when emerging mesa-9999. It stops during the configure with the message:

checking for DRI2PROTO... configure: error: Package requirements (dri2proto >= 1.99.1) were not met:

Reproducible: Always
Steps to reproduce:
1. emerge dri2proto, libdrm, and mesa using the ebuilds from this bug.
2. mesa will die at ebuild.sh, line 513: Called die

emerge --info:
http://rafb.net/p/y9FgYO83.html
Comment 32 Bernd Buschinski 2008-09-08 13:41:46 UTC
Created attachment 164909 [details]
multilib libdrm 2.3.1

mesa 7.1 is testing in portage so I needed a new 32bit mesa, but dealing around with git was too painful so I used the relases.
I hope this ebuilds can help someone :)
Comment 33 Bernd Buschinski 2008-09-08 13:42:20 UTC
Created attachment 164910 [details]
multilib mesa 7.1
Comment 34 Steven Newbury 2008-09-08 14:03:58 UTC
(In reply to comment #31)
> I've been following this bug for a while now, hoping for some resolution to
> these problems. For a while I haven't had too many problems, but there's one in
> particular I've encountered recently which I'm sure an experienced Gentoo dev
> could whip up a hack for it fairly easily. Every once in a while, I'll update
> the mesa-9999 and libdrm-9999 to try and keep up with the changes. Now in
> updates I have a recurring error when emerging mesa-9999. It stops during the
> configure with the message:
> 
> checking for DRI2PROTO... configure: error: Package requirements (dri2proto >=
> 1.99.1) were not met:
> 
> Reproducible: Always
> Steps to reproduce:
> 1. emerge dri2proto, libdrm, and mesa using the ebuilds from this bug.
> 2. mesa will die at ebuild.sh, line 513: Called die
> 
> emerge --info:
> http://rafb.net/p/y9FgYO83.html
> 

You need the latest git version of dri2proto since DRI2 has been re-worked since TTM was dropped.
Comment 35 fow 2008-09-08 19:37:10 UTC
(In reply to comment #34)
>
> You need the latest git version of dri2proto since DRI2 has been re-worked
> since TTM was dropped.
> 

I figured that might be what's needed, but there isn't currently a dri2proto git ebuild.
Comment 36 Donnie Berkholz (RETIRED) gentoo-dev 2008-09-08 21:45:21 UTC
(In reply to comment #35)
> I figured that might be what's needed, but there isn't currently a dri2proto
> git ebuild.

http://git.overlays.gentoo.org/gitweb/?p=proj/x11.git;a=tree;f=x11-proto/dri2proto;h=66663b2c0401ae66eff6d6c22771ecd19f1da763;hb=HEAD

Unmask it when you're using the x11 overlay.
Comment 37 fow 2008-09-10 06:06:00 UTC
(In reply to comment #36)
> (In reply to comment #35)
> > I figured that might be what's needed, but there isn't currently a dri2proto
> > git ebuild.
> 
> http://git.overlays.gentoo.org/gitweb/?p=proj/x11.git;a=tree;f=x11-proto/dri2proto;h=66663b2c0401ae66eff6d6c22771ecd19f1da763;hb=HEAD
> 
> Unmask it when you're using the x11 overlay.
> 

Thank you. :)
Comment 38 Henning Fleddermann 2008-09-18 14:08:51 UTC
Just thought I'd mention this "bug" was also affecting me (I've got a ATi card that only support 3d with mesa >=7.1, and thus I had no 3d-acceleration in wine and with 32bit binaries). I strongly feel the mesa and libdrm-ebuilds should "officialy" support a multilib use-flag.

And thanks to the authors of this ebuilds. They worked like a charm for me. :)
Comment 39 fow 2008-09-29 11:51:24 UTC
This bug hasn't had any comments in a while, and I wanted to update it with info on why it will be a while before it can be resolved, in case it wasn't too clear.

The current problem is that the GPU driver's memory management---for Intel GPU's---is being transported from the underdeveloped TTM memory management to the newer GEM memory management. In a nutshell, GEM is being focused on, as it's tailored for Intel drivers. Little advancement can be made on the drivers without integration of a proper implementation.

My explanation is surely containing errors of the issue as I'm no expert, so  I'll post a few of links detailing the issue.

Concerns regarding TTM: http://www.phoronix.com/scan.php?page=news_item&px=NjQ3NQ

GEM vs TTM: http://lwn.net/Articles/283793/

Intel's GEM Driver Enters Mainline Code:
http://www.phoronix.com/scan.php?page=news_item&px=NjY0Nw

The Phoronix links have several links with more information.
Comment 40 Henning Fleddermann 2008-09-30 09:29:16 UTC
@fow: Im pretty sure you're not understanding the bug. Well, atleast afaik it's not about gem or ttm, but simply about the fact that the mesa-ebuild only builds amd64 binaries on 64-bit-systems and the binarys in emul-linux-xlibs are outdated, so 32-programms often lack some 3d-features or have no 3d-accel at all.
Comment 41 Alexander Huemer 2008-10-26 18:37:44 UTC
this situation applies to me too.
unfortunately the provided "mesa-7.1-r1.ebuild" doesn't work for me.
http://xx.vu/~ahuemer/build.log
does anybody know why my libX11 is incompatible?

as far as i understand at the moment there is no benefit from having a emul-linux-x86-xlibs, since the mesa drivers can be built on the local machine in both 32 and 64 bit incarnations, or am i missing something?
the "mesa-7.1-r1.ebuild" posted here is actually a live ebuild. this is not necessary (at least for me, but surely for many others too), the main concern is to get 32bit 3D apps working on 64bit machines with xorg/mesa drivers.
could someone with experience create an normal 7.2 ebuild that builds both a 32bit and a 64bit version?
Comment 42 Alexander Huemer 2008-10-26 18:45:57 UTC
i just noticed that the ebuild actually can be used for fixed versions too.
unfortunately it procuces the same error as mesa-7.2.ebuild.
any ideas?
Comment 43 Steven Newbury 2008-10-27 02:15:40 UTC
(In reply to comment #42)
> i just noticed that the ebuild actually can be used for fixed versions too.
> unfortunately it procuces the same error as mesa-7.2.ebuild.
> any ideas?
> 

The x11-proto dependencies really need updating in the ebuild.  Make sure you have sufficiently recent versions.  Also you'll need an up to date multilib libdrm.  If you still have problems get back to me.
Comment 44 Alexander Huemer 2008-10-28 12:28:14 UTC
steven,

thanks for your reply.
i have a up-to-date ~ system.
i just installed a multilib-drm from the ebuild of this bug (libdrm-2.3.1-r1.ebuild renamed to libdrm-2.4.0.ebuild). that worked normally after unmerging emul-linux-x86-xlibs, because of the known file collisions.
then trying to emerge mesa-7.2 (renamed mesa-7.1-r1.ebuild from this bug), but this failed again. http://xx.vu/~ahuemer/build.log
i simply don't know why linking against libX11 fails.
any ideas welcome.
thanks again.
Comment 45 Alexander Huemer 2008-10-28 17:02:52 UTC
i did some research on the internet and found out that this is most likely because i do not have a 32-bit version of libX11, which means that just an other ebuild has to be made multilib capable to make all of this work.
the ebuild of libX11 is currently very short, but unfortunately i don't have any clue where to start. and i am afraid similar linking problems will show up in the compile process of mesa, once this is fixed, since this error occurs in a quite early stage of compiling.
Comment 46 Bernd Buschinski 2008-11-12 21:34:27 UTC
Created attachment 171577 [details]
multilib libdrm-2.4.1

also needs
/usr/portage/x11-libs/libdrm/files/2.4.1-intel-Restart-on-interrupt-of-bo_wait_rendering-ins.patch
Comment 47 Bernd Buschinski 2008-11-12 21:36:18 UTC
Created attachment 171578 [details]
multilib mesa-7.2
Comment 48 Henning Fleddermann 2008-11-14 19:58:45 UTC
(In reply to comment #46)
> Created an attachment (id=171577) [edit]
> multilib libdrm-2.4.1
(In reply to comment #47)
> Created an attachment (id=171578) [edit]
> multilib mesa-7.2
> 

Both working fine for me, thanks. :)
I was previously using the mesa-9999 and libdrm-9999 ebuilds provided here but at some point 3d stopped working in wine. This seemed to be a upstream bug though and might even be already fixed in mesa-git, but i'll stick to mesa-7.2 for a while since everythings working great. :D
Comment 49 brot 2008-11-15 08:35:40 UTC
First, thanks everyone for their help here, its great to see that everything seems to work with the provided ebuilds.

What i am asking myself right now is if and when this is going to be fixed in portage. Someone knows that maybe ?

Have a nice day everyone :)

Comment 50 Bernd Buschinski 2008-11-25 16:40:18 UTC
Created attachment 173365 [details]
multilib mesa-9999 (i810 -> intel)

mesa master should now also work,
I fixed one 64bit bug, which caused a crash at X start, that is already in git
+ updated the mesa ebuild i810 -> intel
Comment 51 Steven Newbury 2008-12-01 22:21:00 UTC
(In reply to comment #50)
> Created an attachment (id=173365) [edit]
> multilib mesa-9999 (i810 -> intel)
> 
> mesa master should now also work,
> I fixed one 64bit bug, which caused a crash at X start, that is already in git
> + updated the mesa ebuild i810 -> intel
> 

Thanks for keeping the ebuilds up-to-date, I've been somewhat distracted by real-world events just lately. :)
Comment 52 Bernd Buschinski 2008-12-01 22:56:06 UTC
Created attachment 174019 [details]
fix epatch

and just now I noticed that I attached the wrong ebuild with a custom epatch in it :/
Comment 53 brot 2008-12-29 15:43:46 UTC
Hello. I am using the mesa-9999 ebuild from this page, and i have a problem with the libGL.la

For example x11-libs/cairo-1.8.6 fails to build with the following error:


libtool: link: `/usr/lib64/libGL.la' is not a valid libtool archive                                                                                                                
make[3]: *** [libcairo.la] Error 1  

The libGl.la belongs to the mesa package:

brotscheibe brot # paludis -o libGL.la
* libGL.la
    media-libs/mesa-9999::installed
        /usr/lib32/opengl/xorg-x11/lib/libGL.la
        /usr/lib64/opengl/xorg-x11/lib/libGL.la

But those libs are a bit small here:

brotscheibe brot # du -hs /usr/lib*/opengl/xorg-x11/lib/libGL.la
0       /usr/lib32/opengl/xorg-x11/lib/libGL.la
0       /usr/lib64/opengl/xorg-x11/lib/libGL.la
0       /usr/lib/opengl/xorg-x11/lib/libGL.la

Even after a reemerge of mesa, those libs are not getting bigger.

Thanks for the ebuilds by the way!
Comment 54 Bernd Buschinski 2009-01-02 13:42:39 UTC
Created attachment 177093 [details]
multilib mesa-9999 (check for broken overlay)

You probably just forget to copy /usr/portage/media-libs/mesa/files/lib/ to you overlay
Comment 55 brot 2009-01-02 15:11:19 UTC
(In reply to comment #54)
> Created an attachment (id=177093) [edit]
> multilib mesa-9999 (check for broken overlay)
> 
> You probably just forget to copy /usr/portage/media-libs/mesa/files/lib/ to you
> overlay
> 

Yes, i did. Thank you, i couldnt update some packages of my system since some weeks because of that ;)
Comment 56 fow 2009-01-30 12:32:15 UTC
Will this bug fix ever reach stable Portage, or is this depending on the mainstream Xorg bug fix?
Comment 57 Pacho Ramos gentoo-dev 2009-02-07 09:15:38 UTC
I dubt emul-linux-x86-xlibs will include >=mesa-7.2 until it's marked stable I think :-|
Comment 58 bb 2009-02-07 18:14:40 UTC
the mesa 7.2 ebuild gives me:

checking for DRIGL... yes
checking expat.h usability... no
checking expat.h presence... no
checking for expat.h... no
configure: error: Expat required for DRI.

Comment 59 Bernd Buschinski 2009-02-13 13:36:26 UTC
Created attachment 181869 [details]
multilib mesa-7.3

(In reply to comment #58)
> the mesa 7.2 ebuild gives me:
> 
> checking for DRIGL... yes
> checking expat.h usability... no
> checking expat.h presence... no
> checking for expat.h... no
> configure: error: Expat required for DRI.
> 

mesa-7.2 and 7.3 have
dev-libs/expat
as depency, try recompiling/reemerging expat
Comment 60 Bernd Buschinski 2009-02-13 13:38:05 UTC
Created attachment 181870 [details]
multilib libdrm-2.4.4
Comment 61 Alexander Huemer 2009-02-13 13:53:35 UTC
i think i have something that could be of interest.
a buddy from the forums and i created a eclass and modified ebuild for all the needed packages to make the xlibs multilib capable. since we have an eclass for all that the needed modifications to the ebuilds are minimal.
in my setup (amd64 installation, open source ati driver) i can use 64bit and 32bit applications in the same way. everything is working nicely, e.g. google earth.
there is just one little problem left. a modified libGLU.la has to be copied in the right places. maybe somebody here knows how to fix that.
here is the list of packages:

media-libs/fontconfig
media-libs/freeglut
media-libs/freetype
media-libs/mesa
x11-libs/libICE
x11-libs/libSM
x11-libs/libX11
x11-libs/libXScrnSaver
x11-libs/libXau
x11-libs/libXaw
x11-libs/libXcomposite
x11-libs/libXcursor
x11-libs/libXdamage
x11-libs/libXdmcp
x11-libs/libXext
x11-libs/libXfixes
x11-libs/libXft
x11-libs/libXi
x11-libs/libXinerama
x11-libs/libXmu
x11-libs/libXp
x11-libs/libXpm
x11-libs/libXrandr
x11-libs/libXrender
x11-libs/libXt
x11-libs/libXtst
x11-libs/libXv
x11-libs/libXvMC
x11-libs/libXxf86dga
x11-libs/libXxf86vm
x11-libs/libdrm
x11-libs/libview
x11-libs/libxcb
x11-libs/pixman
x11-proto/dri2proto

a metapackage is available too.
if anybody is interested i can make all that available.
Comment 62 bb 2009-02-13 13:58:14 UTC
(In reply to comment #61)
> i think i have something that could be of interest.
> a buddy from the forums and i created a eclass and modified ebuild for all the
> needed packages to make the xlibs multilib capable. since we have an eclass for
> all that the needed modifications to the ebuilds are minimal.
> in my setup (amd64 installation, open source ati driver) i can use 64bit and
> 32bit applications in the same way. everything is working nicely, e.g. google
> earth.
> there is just one little problem left. a modified libGLU.la has to be copied in
> the right places. maybe somebody here knows how to fix that.
> here is the list of packages:
> 
> media-libs/fontconfig
> media-libs/freeglut
> media-libs/freetype
> media-libs/mesa
> x11-libs/libICE
> x11-libs/libSM
> x11-libs/libX11
> x11-libs/libXScrnSaver
> x11-libs/libXau
> x11-libs/libXaw
> x11-libs/libXcomposite
> x11-libs/libXcursor
> x11-libs/libXdamage
> x11-libs/libXdmcp
> x11-libs/libXext
> x11-libs/libXfixes
> x11-libs/libXft
> x11-libs/libXi
> x11-libs/libXinerama
> x11-libs/libXmu
> x11-libs/libXp
> x11-libs/libXpm
> x11-libs/libXrandr
> x11-libs/libXrender
> x11-libs/libXt
> x11-libs/libXtst
> x11-libs/libXv
> x11-libs/libXvMC
> x11-libs/libXxf86dga
> x11-libs/libXxf86vm
> x11-libs/libdrm
> x11-libs/libview
> x11-libs/libxcb
> x11-libs/pixman
> x11-proto/dri2proto
> 
> a metapackage is available too.
> if anybody is interested i can make all that available.
> 

pls
Comment 63 bb 2009-02-13 14:02:32 UTC
> mesa-7.2 and 7.3 have
> dev-libs/expat
> as depency, try recompiling/reemerging expat
> 

configure:8324: checking for XML_ParserCreate in -lexpat
configure:8359: i686-pc-linux-gnu-gcc -o conftest -O2 -pipe -ffast-math -m32 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing  -Wl,-O1 conftest.c -lexpat   >&5
/usr/libexec/gcc/i686-pc-linux-gnu/ld: cannot find -lexpat

do you have some multilib expat?
Comment 64 Alexander Huemer 2009-02-14 00:46:50 UTC
http://xx.vu/~ahuemer/multilib-xlibs.tgz
this archive contains the current ~ ebuilds, maybe some older ones.
as i already said, someone please fix the libGLU.la problem and annoy the gentoo devs to take a look at this.
the meta ebuild is in the forums post http://forums.gentoo.org/viewtopic-t-712511.html
Comment 65 bb 2009-02-14 02:05:47 UTC
(In reply to comment #59)
> Created an attachment (id=181869) [edit]
> multilib mesa-7.3
> 
> (In reply to comment #58)
> > the mesa 7.2 ebuild gives me:
> > 
> > checking for DRIGL... yes
> > checking expat.h usability... no
> > checking expat.h presence... no
> > checking for expat.h... no
> > configure: error: Expat required for DRI.
> > 
> 
> mesa-7.2 and 7.3 have
> dev-libs/expat
> as depency, try recompiling/reemerging expat
> 

seems that my crossdev env is broken, had to add
CPPFLAGS="-I/usr/include" LDFLAGS="-L/usr/lib32" to the emerge command
Comment 66 Alexander Huemer 2009-02-26 10:42:28 UTC
i just created a new tarball with updated versions of the just released ebuilds libdrm-2.4.5, libXi-1.2.1 and pixman-0.14.0.
http://xx.vu/~ahuemer/multilib-xlibs-20090226.tgz
as actually anybody using this? some feedback would be useful.
Comment 67 Cesar Garcia 2009-03-03 23:25:09 UTC
(In reply to comment #66)
> i just created a new tarball with updated versions of the just released ebuilds
> libdrm-2.4.5, libXi-1.2.1 and pixman-0.14.0.
> http://xx.vu/~ahuemer/multilib-xlibs-20090226.tgz
> as actually anybody using this? some feedback would be useful.
> 

I am still using it (i am the buddy form the forums, i was AFK big time from the forums). And yes, the updated ebuild still works ok (i made a big system update today) except libdrm-2.4.5 who now has a implicit depend on cairo and dont want to compile probably until i convert the cairo ebuild to multilib (maybe u dont noticed because you had the emul-linux-x86-gtklibs package, iunno).

Sorry for my english.
Comment 68 Steven Newbury 2009-03-05 17:40:00 UTC
(In reply to comment #66)
> i just created a new tarball with updated versions of the just released ebuilds
> libdrm-2.4.5, libXi-1.2.1 and pixman-0.14.0.
> http://xx.vu/~ahuemer/multilib-xlibs-20090226.tgz
> as actually anybody using this? some feedback would be useful.
> 

I'm the original contributor so naturally, I'm still using it! :) I've been maintaining my own version locally though.  I'll check out your updates out and merge anything worthwhile.

It would be nice to get a resolution into portage (or at least the x11 overlay), I'm sure pretty every 64bit Gentoo user involved with xorg development/testing has run into this bug.
Comment 69 Steven Newbury 2009-03-05 17:46:08 UTC
(In reply to comment #66)
> i just created a new tarball with updated versions of the just released ebuilds
> libdrm-2.4.5, libXi-1.2.1 and pixman-0.14.0.
> http://xx.vu/~ahuemer/multilib-xlibs-20090226.tgz
> as actually anybody using this? some feedback would be useful.
> 

Okay, I've had a look.  Looks good, however have you found it works when a cross-i686 toolchain is installed?  I found it's necessary to "export" CC and CXX, otherwise they don't actually get used (see your multilib-xlibs.eclass).  
Comment 70 Alexander Huemer 2009-03-05 18:04:31 UTC
i do not use crossdev.
steven, please take a look again at the forums post [1].
let's discuss there how to continue. do you have contact with any gentoo dev who could integrate this stuff when it is mature enough, or at least a guy from the x11 overlay?

[1] http://forums.gentoo.org/viewtopic-t-712511-start-25.html
Comment 71 bb 2009-03-28 10:52:12 UTC
http://github.com/sjnewbury/multilib-overlay/tree/master could be interesting 
Comment 72 Pacho Ramos gentoo-dev 2009-12-27 10:41:31 UTC
Please test with app-emulation/emul-linux-x86-xlibs-20091226 , it includes current x86 stable X packages