Alex Bennee <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Mon, 12 Jun 2006 08:49:39 +0100:
> Every time I run "eselect opengl set xorg-x11" it switches my opengl > headers to the 32 bit versions which obviously breaks compiles like X. > Unfortunately it seems to get called in the xorg ebuilds which means I > currently can't build X. > > Although the man page assures me there is some html documentation for > eselect I can't seem to find it on my system. Is there a build flag I > should be enabling? > > Regardless of finding documentation does anyone know how to stop eselect > breaking my setup? OK, I don't have the problem 32-bit libraries merged, and don't have the issue, which hints at one work-around, anyway. Assuming you are running the 32-bit compatibility binary packages, simply temporarily unmerge them, then run eselect opengl and do your xorg merges and whatever, then remerge the 32-bit stuff. Because it's a binary compatibility package that's precompiled, the remerge shouldn't be a big deal as it'll go pretty fast. If you are using the 32-bit chroot option and experiencing the problem, the unmerge/remerge solution will be rather more difficult as the remerge would do the 32-bit compile and therefore take longer. In this case, consider simply temporarily moving the 32-bit library dir containing the problem libraries out of the search path, say to /home or something, while you do the otherwise problematic 64-bit compiles, or umount the 32-bit chroot, if it's a separate mount, or use a mount --bind (see the mount manpage) or similar to mount something over the problem 32-bit dir, therefore hiding it temporarily. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-amd64@gentoo.org mailing list