The available version of emul-linux-x86-xlibs contains a libX11 which is compiled without XCB support. If the 64bit system libX11 is compiled with xcb enabled, loading 32bit libX11 into an app using xcb enabled libX11 it will crash the application with a xlib xcb locking assertion failure. One example is media-sound/lmms on amd64 with VST support enabled. This app is able to load Windows VST plugins via wine, and embeds the GUI into it's own GUI using Qt4 functions. If LIBXCB_ALLOW_SLOPPY_LOCK is unset, lmms will crash right away due to the 32bit libX11 not having xcb enabled. It tested this on OpenSUSE and Arch linux in a VM, both providing a 32bit libX11 with xcb enabled, and it runs fine there. I haven't been able to test it on Gentoo due to the lack of documentation about the way the emul packages get built. This is a rare case of course, so it would be interesting to know if the majority of amd64 users with X installed do have xcb enabled or not. Because if most have xcb enabled, I'd say that the emul xlibs should have xcb support too. Minor issue regarding the easy LIBXCB_ALLOW_SLOPPY_LOCK=1 workaround, but anyways, having a xcb enabled 64bit libX11 and a non-xcb 32bit one causes inconsistencies here. Currently this issue is the cause for "media-sound/lmms vst" in base/package.use.mask though... Reproducible: Always Steps to Reproduce: 1. override vst p.use.mask and install media-sound/lmms with vst enabled 2. load some VST .dll in lmms Actual Results: lmms crashes with a locking assertion failure Expected Results: it should work
http://bugs.gentoo.org/show_bug.cgi?id=255117 Same issue I guess.
Nevermind the vmware issue, it doesn't really have anything to do with it.
Reassigning to amd64 herd.
With libX11-1.2 and libxcb-1.2, much of this will become a non-issue.
I am running a 64-bit gentoo system with libxcb-1.4-r1 and libX11 1.3.2 and I recently ran into a problem running a 32-bit binary of new puzzle action game called QuantZ. 32-bit binary can be download @ http://www.reddit.com/r/linux_gaming/comments/a2kux/quantz_ported_to_linux_please_help_us_test_the/ After running QuantZ i get this error: ./QuantZ: error while loading shared libraries: libxcb.so.1: cannot open shared object file: No such file or directory Is there any possibility that app-emulation/emul-linux-x86-xlibs's libX11 will gain libxcb support?
libxcb was added to app-emulation/emul-linux-x86-xlibs-20091226 , please try it
(In reply to comment #6) > libxcb was added to app-emulation/emul-linux-x86-xlibs-20091226 , please try it Any possibility that the ebuild could respect the xcb USE flag? Otherwise it will break app-editors/emacs-18.59-r6 which needs the "real" libX11.
(Please next time open a new bug report for keeping bugs a bit more ordered, I mean, one problem -> one bug. Thanks a lot :-)) (In reply to comment #7) > Any possibility that the ebuild could respect the xcb USE flag? Otherwise it > will break app-editors/emacs-18.59-r6 which needs the "real" libX11. > I have nothing against it, but I will have to prepare two libX11 versions, one with xcb and the other without and try to install the proper one with proper USE flags on ebuild I will look at it of course (since I don't expect to get emacs-18* cleaned soon, not? Thanks for reporting all issues you find
An important problem is that media-libs/mesa requires libX11 built with +xcb (how is this being handled currently on native systems? Seems that people with media-libs/mesa will simply be unable to install emacs:18 :-/) Also awesome and agg want libX11 built with +xcb
Sorry, I misinterpreted mesa's RDEPEND, it doesn't have that problem Then, the idea would be that, when USE="-xcb", libX11.so should be replaced by non-xcb one (that I will probably package apart) and libX11-xcb.so* should be removed. Since mesa provided libs are built without xcb they wouldn't require any change, I guess But I add x11 team to CC list for confirming if this would be safe since I am not a Xorg expert
(In reply to comment #8) > I will look at it of course (since I don't expect to get emacs-18* cleaned > soon, not? It won't go away anytime soon, since we keep -18* as lightweight Emacs version. If there's no other way, we could drop X11 support for it on amd64 (but I would hate to do this).
Why did you reverted tha summary? libX11 has now xcb support, the problem is trying to make it optional (In reply to comment #11) > It won't go away anytime soon, since we keep -18* as lightweight Emacs version. OK, I haven't ever used emacs and I wrongly associated old version with "near its remove", sorry > If there's no other way, we could drop X11 support for it on amd64 (but I would > hate to do this). > If X11 team agrees with simply changing libX11 would be enough, I will try to not having to drop its support :-)
(In reply to comment #12) > Why did you reverted tha summary? Sorry about this, it was unintentional. (I had a mid-air collision for comment #11 and didn't notice that you had changed the summary, so it was reverted.) (In reply to comment #10) > Then, the idea would be that, when USE="-xcb", libX11.so should be replaced > by non-xcb one (that I will probably package apart) and libX11-xcb.so* > should be removed. Looking at emul-linux-x86.eclass: maybe you could do something like the following in the ebuild: SRC_URI="mirror://gentoo/${P}.tar.bz2 xcb? ( mirror://gentoo/${P}-libX11-xcb.tar.bz2 ) !xcb? ( mirror://gentoo/${P}-libX11-noxcb.tar.bz2 )" i.e. take libX11 out of the main tarball?
Ulrich, FYI, we intend to drop the xcb USE flag from libX11 at some point in the near future to make xcb mandatory... If emacs-18 isn't working properly with libX11[xcb], it really ought to be fixed. Thanks
(In reply to comment #14) > Ulrich, FYI, we intend to drop the xcb USE flag from libX11 at some point in > the near future to make xcb mandatory... O.K., if the X11 team says that libX11[-xcb] is doomed, then it also makes no sense to foresee it in the emul-*-libs. Closing again.
OK, reverting the summary (for adjusting it to final resolution) Regards
This problem will arise again when new emul-linux-x86-xlibs will get stabled, then, I would want to know if emacs team will drop X use flag for emacs:18 (as -xcb libX11 support will be dropped in the future) or amd64 team will need to mask it only for our arch Thanks
(In reply to comment #17) > This problem will arise again when new emul-linux-x86-xlibs will get stabled, > then, I would want to know if emacs team will drop X use flag for emacs:18 (as > -xcb libX11 support will be dropped in the future) or amd64 team will need to > mask it only for our arch ulm just dropped X support for Emacs 18, so no non-xcb libX11 is needed anymore.
(In reply to comment #18) > ulm just dropped X support for Emacs 18, so no non-xcb libX11 is needed > anymore. Right (and no thanks for the mid-air collision). Patches to fix it properly are welcome, but at the moment I don't have time to search for the problem myself.
OK, thanks :-)
