[gentoo-amd64] eselect opengl keeps breaking my headers

[gentoo-amd64] eselect opengl keeps breaking my headers

[Alex Bennee]

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?

--
Alex, homepage: http://www.bennee.com/~alex/
A committee takes root and grows, it flowers, wilts and dies, scattering
the seed from which other committees will bloom. -- Parkinson

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: eselect opengl keeps breaking my headers

[Duncan]

Alex Bennee <kernel-hacker@bennee.com> posted
1150098579.10664.8.camel@malory, 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