|
Description
Mark Glines
2008-01-07 14:35:04 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. (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 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.
(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. (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. 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.
Sorry, that last diff is broken. I'll post a new version in a few minutes. Created attachment 154655 [details, diff]
Mesa ebuild patch to enable multilib build support (fixed)
(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... 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 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.
Created attachment 154663 [details]
Mesa live ebuild drop in replacement for the x11 overlay mesa
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?
Created attachment 154697 [details, diff]
Mesa ebuild patch to enable multilib build support
Missed CXXFLAGS
(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 Created attachment 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 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.
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 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 :)
Created attachment 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 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
Created attachment 171578 [details]
multilib mesa-7.2
(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 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 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
(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. :) Created attachment 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 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
(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 ;) 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 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 Created attachment 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] > 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 Please test with app-emulation/emul-linux-x86-xlibs-20091226 , it includes current x86 stable X packages |
