[gentoo-amd64] eselect opengl set xorg-x11 keeps breaking my headers

[gentoo-amd64] eselect opengl set xorg-x11 keeps breaking my headers

[Alex Bennee]

Despite no longer having the emulation libraries installed eselect keep
screwing up my headers to point at 32 bit glx stuff. This obviously
breaks various X related compiles.

Does anyone know how I can stop it doing this? Unfortunately its called
during the ebuild so I can't manually fix them and re-run the build.

--
Alex, homepage: http://www.bennee.com/~alex/
Declared guilty... of displaying feelings of an almost human nature. --
Pink Floyd, "The Wall"

-- 
gentoo-amd64@gentoo.org mailing list

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

[Duncan]

Alex Bennee <kernel-hacker@bennee.com> posted
1151449927.10564.2.camel@malory, excerpted below, on  Wed, 28 Jun 2006
00:12:06 +0100:

> Despite no longer having the emulation libraries installed eselect keep
> screwing up my headers to point at 32 bit glx stuff. This obviously breaks
> various X related compiles.

What does equery belongs </path/to/32-bit-file> return?  What video
drivers are you running?

If you are running slaveryware video drivers, equery belongs will probably
return them (assuming you merged them using portage, anyway).  If it
returns nothing and you didn't manually (not using portage, so it doesn't
know about the file) install something using that file, it's likely safe to
delete it. Just to be safe, however, I'd rename it to *.2006.07.28.remove
(a month later) or something similar. Then after that date, if you've not
found anything broken, go ahead and remove it, as even if it /does/ break
something it can't be too critical if you've not used it once in 30 days.

> Does anyone know how I can stop it doing this? Unfortunately its called
> during the ebuild so I can't manually fix them and re-run the build.

Actually, that isn't entirely the case.  See the Gentoo Handbook, Working
with Portage section, and the ebuild (1 and 5) manpages for some details,
but many Gentoo users have their own local overlays, where they copy
ebuilds and modify them as desired, then redigest and merge them.  I
routinely do this with some packages, say to strip out a filterflags call
that was thrown in by the Gentoo maintainer due to some problem with some
subarchs of x86, where the flags in question work just fine on at least my
amd64, for instance.  That's the beauty of having ebuilds that are
basically bash scripts -- they are easily modified by anyone who knows
bash -- the portage system was deliberately set up to allow this, and a
lot of work has gone into and will continue to go into ensuring that this
easy modifiability remains the case.



-- 
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

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

[Alex Bennee]

On Wed, 2006-06-28 at 17:33 +0000, Duncan wrote:
> Alex Bennee <kernel-hacker@bennee.com> posted
> 1151449927.10564.2.camel@malory, excerpted below, on  Wed, 28 Jun 2006
> 00:12:06 +0100:
> 
> > Despite no longer having the emulation libraries installed eselect
keep
> > screwing up my headers to point at 32 bit glx stuff. This obviously
breaks
> > various X related compiles.
> 
> What does equery belongs </path/to/32-bit-file> return?  What video
> drivers are you running?

Ahh the emul-libs keep getting pulled in. Probably because of OO. Some
of the files actually belong to eselect:


malory GL # equery b /usr/lib32/opengl/global/include/glxext.h
[ Searching for file(s) /usr/lib32/opengl/global/include/glxext.h in
*... ]
app-admin/eselect-opengl-1.0.3
(/usr/lib32/opengl/global/include/glxext.h)

> If you are running slaveryware video drivers, equery belongs will
probably
> return them (assuming you merged them using portage, anyway).  If it
> returns nothing and you didn't manually (not using portage, so it
doesn't
> know about the file) install something using that file, it's likely
safe to
> delete it. Just to be safe, however, I'd rename it to
*.2006.07.28.remove
> (a month later) or something similar. Then after that date, if you've
not
> found anything broken, go ahead and remove it, as even if it /does/
break
> something it can't be too critical if you've not used it once in 30
days.

No just plain OS drivers (I will be experimenting with the OS r300
drivers when I get a chance).

> > Does anyone know how I can stop it doing this? Unfortunately its
called
> > during the ebuild so I can't manually fix them and re-run the build.
> 
> Actually, that isn't entirely the case.  See the Gentoo Handbook,
Working
> with Portage section, and the ebuild (1 and 5) manpages for some
details,
> but many Gentoo users have their own local overlays, where they copy
> ebuilds and modify them as desired,
> <snip>

I agree. I do actually run my own overlay for some bits and pieces.
However reading through the Xorg stuff I'd rather leave it to people
more qualified than me :-)

I think the behaviour I'm seeing may be related to
http://bugs.gentoo.org/show_bug.cgi?id=109922

> 
> 
> 
> -- 
> 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
> 

--
Alex, homepage: http://www.bennee.com/~alex/
Mal: "Nice shot." Jayne: "I was aiming for his head."

-- 
gentoo-amd64@gentoo.org mailing list

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

[Duncan]

Alex Bennee <kernel-hacker@bennee.com> posted
1151655497.26625.3.camel@malory, excerpted below, on  Fri, 30 Jun 2006
09:18:17 +0100:

> I agree. I do actually run my own overlay for some bits and pieces.
> However reading through the Xorg stuff I'd rather leave it to people
> more qualified than me :-)

The ebuilds are actually simple now, compared to the monolithic
xorg-6.7/6.8 ebuilds, because a lot of the stuff is module-specific and
therefore is only included in a couple of the ebuilds, so they all don't
occur in the same ebuild as they did pre-modular!  Never-the-less, I can
certainly see your point! =8^)

xorg-server and a couple of the other modules are in fact in my overlay
(the cited filterflags example applying to -fweb, which is filtered for
everyone in xorg-server, altho the issue apparently doesn't affect amd64
at all based on my experience and those of others when I asked on this
list some months ago), but I make only a couple very specific
modifications to them, and I was /very/ glad to see xorg go modular, so I
didn't have to track all the /other/ changes every release and figure out
if they affected the couple of changes I was making or not.

> I think the behaviour I'm seeing may be related to
> http://bugs.gentoo.org/show_bug.cgi?id=109922

I think you are correct.



-- 
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

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

[Bernhard Auzinger]

Am Mittwoch 28 Juni 2006 01:12 schrieb Alex Bennee:
> Despite no longer having the emulation libraries installed eselect keep
> screwing up my headers to point at 32 bit glx stuff. This obviously
> breaks various X related compiles.
>
> Does anyone know how I can stop it doing this? Unfortunately its called
> during the ebuild so I can't manually fix them and re-run the build.
>
> --
> Alex, homepage: http://www.bennee.com/~alex/
> Declared guilty... of displaying feelings of an almost human nature. --
> Pink Floyd, "The Wall"

Try to delete the gl-headers located in the "emul" directory. 
Usually /usr/include/GL contains symlinks to /usr/lib, but sometimes things 
go wrong with "early versions" of the emul stuff (they don't disappear by 
upgrading or unmerging) and eselect places a symlink which points 
to /usr/lib32 instead of /usr/lib or /usr/lib64. /usr/lib32 again is a 
symlink to the /emul directory. Delete gl-headers in the /emul directory to 
which the symlinks in /usr/include/GL point to.

rgds

Bernhard
-- 
gentoo-amd64@gentoo.org mailing list

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

[Bernhard Auzinger]

Am Mittwoch 28 Juni 2006 01:12 schrieb Alex Bennee:
> Despite no longer having the emulation libraries installed eselect keep
> screwing up my headers to point at 32 bit glx stuff. This obviously
> breaks various X related compiles.
>
> Does anyone know how I can stop it doing this? Unfortunately its called
> during the ebuild so I can't manually fix them and re-run the build.
>
> --
> Alex, homepage: http://www.bennee.com/~alex/
> Declared guilty... of displaying feelings of an almost human nature. --
> Pink Floyd, "The Wall"

Did my suggestions help?

rgds

Bernhard
-- 
gentoo-amd64@gentoo.org mailing list

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

[Alex Bennee]

On Thu, 2006-06-29 at 11:06 +0200, Bernhard Auzinger wrote:
> Am Mittwoch 28 Juni 2006 01:12 schrieb Alex Bennee:
> > Despite no longer having the emulation libraries installed eselect keep
> > screwing up my headers to point at 32 bit glx stuff. This obviously
> > breaks various X related compiles.
> >
<snip>
> 
> Did my suggestions help?

Sort of - removing the emulation headers by temporarily removing the
ebuild did the trick. Apart from the 2 32 bit headers that eselect
"owns"

--
Alex, homepage: http://www.bennee.com/~alex/
Political speeches are like steer horns. A point here, a point there,
and a lot of bull inbetween. -- Alfred E. Neuman

-- 
gentoo-amd64@gentoo.org mailing list