Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
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
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.
(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?
(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).
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.
(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.
(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
(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...
Created an attachment (id=154545) [details] 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.
(In reply to comment #8) > Created an attachment (id=154545) [edit] [details] > 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.
(In reply to comment #9) > (In reply to comment #8) > > Created an attachment (id=154545) [edit] [details] > > 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.
Created an attachment (id=154653) [details] 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.
Sorry, that last diff is broken. I'll post a new version in a few minutes.
Created an attachment (id=154655) [details] Mesa ebuild patch to enable multilib build support (fixed)
(In reply to comment #13) > Created an attachment (id=154655) [edit] [details] > 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...
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?
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.
Created an attachment (id=154661) [details] 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.
Created an attachment (id=154663) [details] Mesa live ebuild drop in replacement for the x11 overlay mesa
Created an attachment (id=154695) [details] 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?
Created an attachment (id=154697) [details] Mesa ebuild patch to enable multilib build support Missed CXXFLAGS
(In reply to comment #18) > Created an attachment (id=154663) [edit] [details] > 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
Created an attachment (id=154763) [details] Mesa live ebuild drop in replacement for the x11 overlay
Updated the attached ebuild to be in sync with the patch.
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.
emul-* packages only contain stable versions, hence the version mismatch that was originally reported. Xorg team: is this something you want to support?
(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.
Created an attachment (id=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.
new emul-xlibs in the tree, it might help.
(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).
(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.
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
Created an attachment (id=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 :)
Created an attachment (id=164910) [details] multilib mesa 7.1
(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.
(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.
(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.
(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. :)
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. :)
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.
@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.
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?
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?
(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.
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.
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.
Created an attachment (id=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
Created an attachment (id=171578) [details] multilib mesa-7.2
(In reply to comment #46) > Created an attachment (id=171577) [edit] [details] > multilib libdrm-2.4.1 (In reply to comment #47) > Created an attachment (id=171578) [edit] [details] > 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
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 :)
Created an attachment (id=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
(In reply to comment #50) > Created an attachment (id=173365) [edit] [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 > Thanks for keeping the ebuilds up-to-date, I've been somewhat distracted by real-world events just lately. :)
Created an attachment (id=174019) [details] fix epatch and just now I noticed that I attached the wrong ebuild with a custom epatch in it :/
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!
Created an attachment (id=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
(In reply to comment #54) > Created an attachment (id=177093) [edit] [details] > 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 ;)
Will this bug fix ever reach stable Portage, or is this depending on the mainstream Xorg bug fix?
I dubt emul-linux-x86-xlibs will include >=mesa-7.2 until it's marked stable I think :-|
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.
Created an attachment (id=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
Created an attachment (id=181870) [details] multilib libdrm-2.4.4
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.
(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
> 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?
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
(In reply to comment #59) > Created an attachment (id=181869) [edit] [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 > seems that my crossdev env is broken, had to add CPPFLAGS="-I/usr/include" LDFLAGS="-L/usr/lib32" to the emerge command
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.
(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.
(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.
(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).
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
http://github.com/sjnewbury/multilib-overlay/tree/master could be interesting
