[gentoo-amd64] libGL can't be found...

[gentoo-amd64] libGL can't be found...

[Hamish Marson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I've updated recently but am having problems with whatever changes
were made to the opengl support in Gentoo ~amd64 (recently?).
Bascially if I try to emerge anythig using opengl, I just get errors
that libGL can't be found.

Now xorg-x11 has installed it's opengl stuff in
/usr/lib/opengl/xorg-x11/lib/* and I've done an eselect to select
xorg-x11 as the current opengl implementation. But still nothing finds
it...

Where exactly SHOULD the linking stages be looking for opengl libs?
(Including GLUT etc). And if they're not there by default because you
can eselect between different implementations, why doesn't eselect put
them where they should be when it's told?

TIA

Hamish.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD3K4t/3QXwQQkZYwRAh4PAKDQx429jqDRo5cMoz1PbNnpG97+PgCgxMbr
DkgDwOpZYMYhbUd2jOSvnCU=
=J1i/
-----END PGP SIGNATURE-----

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] libGL can't be found...

[Brian Litzinger]

On Sun, Jan 29, 2006 at 11:59:41AM +0000, Hamish Marson wrote:
> 
> I've updated recently but am having problems with whatever changes
> were made to the opengl support in Gentoo ~amd64 (recently?).
> Bascially if I try to emerge anythig using opengl, I just get errors
> that libGL can't be found.
> 
> Now xorg-x11 has installed it's opengl stuff in
> /usr/lib/opengl/xorg-x11/lib/* and I've done an eselect to select
> xorg-x11 as the current opengl implementation. But still nothing finds
> it...
> 
> Where exactly SHOULD the linking stages be looking for opengl libs?
> (Including GLUT etc). And if they're not there by default because you
> can eselect between different implementations, why doesn't eselect put
> them where they should be when it's told?

I'd appreciate reading whatever you learn in answer to this question.

I've long had similar problems.

-- 
Brian Litzinger
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] libGL can't be found...

[Hemmann, Volker Armin]

On Sunday 29 January 2006 12:59, Hamish Marson wrote:
> I've updated recently but am having problems with whatever changes
> were made to the opengl support in Gentoo ~amd64 (recently?).
> Bascially if I try to emerge anythig using opengl, I just get errors
> that libGL can't be found.
>
> Now xorg-x11 has installed it's opengl stuff in
> /usr/lib/opengl/xorg-x11/lib/* and I've done an eselect to select
> xorg-x11 as the current opengl implementation. But still nothing finds
> it...
>
> Where exactly SHOULD the linking stages be looking for opengl libs?
> (Including GLUT etc). And if they're not there by default because you
> can eselect between different implementations, why doesn't eselect put
> them where they should be when it's told?
>

/usr/lib

ls -lh /usr/lib/libGL*
lrwxrwxrwx 1 root root   42 29. Jan 04:39 /usr/lib/libGLcore.so 
-> //usr/lib64/opengl/nvidia/lib/libGLcore.so
-rw-r--r-- 1 root root  731 29. Jan 04:39 /usr/lib/libGL.la
lrwxrwxrwx 1 root root   38 29. Jan 04:39 /usr/lib/libGL.so 
-> //usr/lib64/opengl/nvidia/lib/libGL.so
-rw-r--r-- 1 root root  752 19. Jan 04:25 /usr/lib/libGLU.la
lrwxrwxrwx 1 root root   11 19. Jan 04:25 /usr/lib/libGLU.so -> libGLU.so.1
lrwxrwxrwx 1 root root   20 19. Jan 04:25 /usr/lib/libGLU.so.1 -> 
libGLU.so.1.3.060401
lrwxrwxrwx 1 root root   20 19. Jan 04:25 /usr/lib/libGLU.so.1.3 -> 
libGLU.so.1.3.060401
-rwxr-xr-x 1 root root 509K 19. Jan 04:25 /usr/lib/libGLU.so.1.3.060401
lrwxrwxrwx 1 root root   11 19. Jan 04:25 /usr/lib/libGLw.so -> libGLw.so.1
lrwxrwxrwx 1 root root   15 19. Jan 04:25 /usr/lib/libGLw.so.1 -> 
libGLw.so.1.0.0
lrwxrwxrwx 1 root root   15 19. Jan 04:25 /usr/lib/libGLw.so.1.0 -> 
libGLw.so.1.0.0
-rwxr-xr-x 1 root root  26K 19. Jan 04:25 /usr/lib/libGLw.so.1.0.0

control the symlinks.

If the linker does not look into /usr/lib something is extremly broken.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] libGL can't be found...

[Hamish Marson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hemmann, Volker Armin wrote:

> On Sunday 29 January 2006 12:59, Hamish Marson wrote:
>
>> I've updated recently but am having problems with whatever
>> changes were made to the opengl support in Gentoo ~amd64
>> (recently?). Bascially if I try to emerge anythig using opengl, I
>> just get errors that libGL can't be found.
>>
>> Now xorg-x11 has installed it's opengl stuff in
>> /usr/lib/opengl/xorg-x11/lib/* and I've done an eselect to select
>> xorg-x11 as the current opengl implementation. But still nothing
>> finds it...
>>
>> Where exactly SHOULD the linking stages be looking for opengl
>> libs? (Including GLUT etc). And if they're not there by default
>> because you can eselect between different implementations, why
>> doesn't eselect put them where they should be when it's told?
>>
>
> /usr/lib
>
> ls -lh /usr/lib/libGL* lrwxrwxrwx 1 root root 42 29. Jan 04:39
> /usr/lib/libGLcore.so -> //usr/lib64/opengl/nvidia/lib/libGLcore.so
> -rw-r--r-- 1 root root 731 29. Jan 04:39 /usr/lib/libGL.la
> lrwxrwxrwx 1 root root 38 29. Jan 04:39 /usr/lib/libGL.so ->
> //usr/lib64/opengl/nvidia/lib/libGL.so -rw-r--r-- 1 root root 752
> 19. Jan 04:25 /usr/lib/libGLU.la lrwxrwxrwx 1 root root 11 19.
> Jan 04:25 /usr/lib/libGLU.so -> libGLU.so.1 lrwxrwxrwx 1 root root
> 20 19. Jan 04:25 /usr/lib/libGLU.so.1 -> libGLU.so.1.3.060401
> lrwxrwxrwx 1 root root 20 19. Jan 04:25 /usr/lib/libGLU.so.1.3 ->
> libGLU.so.1.3.060401 -rwxr-xr-x 1 root root 509K 19. Jan 04:25
> /usr/lib/libGLU.so.1.3.060401 lrwxrwxrwx 1 root root 11 19. Jan
> 04:25 /usr/lib/libGLw.so -> libGLw.so.1 lrwxrwxrwx 1 root root 15
> 19. Jan 04:25 /usr/lib/libGLw.so.1 -> libGLw.so.1.0.0 lrwxrwxrwx 1
> root root 15 19. Jan 04:25 /usr/lib/libGLw.so.1.0 ->
> libGLw.so.1.0.0 -rwxr-xr-x 1 root root 26K 19. Jan 04:25
> /usr/lib/libGLw.so.1.0.0
>
> control the symlinks.
>
> If the linker does not look into /usr/lib something is extremly
> broken.

No, the linker is looking in /usr/lib, but it's gentoo that doesn't
seem to want to put the libGL etc in /usr/lib...

H


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD3TEv/3QXwQQkZYwRAv1lAJ9fiSNhzy/dtI6ViR+ykMATVgwosgCeMwe2
ALFj6xq5RwyFjiMDgpw2h98=
=XGqx
-----END PGP SIGNATURE-----

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] libGL can't be found...

[Hemmann, Volker Armin]

On Sunday 29 January 2006 22:18, Hamish Marson wrote:
> Hemmann, Volker Armin wrote:
> > On Sunday 29 January 2006 12:59, Hamish Marson wrote:
> >> I've updated recently but am having problems with whatever
> >> changes were made to the opengl support in Gentoo ~amd64
> >> (recently?). Bascially if I try to emerge anythig using opengl, I
> >> just get errors that libGL can't be found.
> >>
> >> Now xorg-x11 has installed it's opengl stuff in
> >> /usr/lib/opengl/xorg-x11/lib/* and I've done an eselect to select
> >> xorg-x11 as the current opengl implementation. But still nothing
> >> finds it...
> >>
> >> Where exactly SHOULD the linking stages be looking for opengl
> >> libs? (Including GLUT etc). And if they're not there by default
> >> because you can eselect between different implementations, why
> >> doesn't eselect put them where they should be when it's told?
> >
> > /usr/lib
> >
> > ls -lh /usr/lib/libGL* lrwxrwxrwx 1 root root 42 29. Jan 04:39
> > /usr/lib/libGLcore.so -> //usr/lib64/opengl/nvidia/lib/libGLcore.so
> > -rw-r--r-- 1 root root 731 29. Jan 04:39 /usr/lib/libGL.la
> > lrwxrwxrwx 1 root root 38 29. Jan 04:39 /usr/lib/libGL.so ->
> > //usr/lib64/opengl/nvidia/lib/libGL.so -rw-r--r-- 1 root root 752
> > 19. Jan 04:25 /usr/lib/libGLU.la lrwxrwxrwx 1 root root 11 19.
> > Jan 04:25 /usr/lib/libGLU.so -> libGLU.so.1 lrwxrwxrwx 1 root root
> > 20 19. Jan 04:25 /usr/lib/libGLU.so.1 -> libGLU.so.1.3.060401
> > lrwxrwxrwx 1 root root 20 19. Jan 04:25 /usr/lib/libGLU.so.1.3 ->
> > libGLU.so.1.3.060401 -rwxr-xr-x 1 root root 509K 19. Jan 04:25
> > /usr/lib/libGLU.so.1.3.060401 lrwxrwxrwx 1 root root 11 19. Jan
> > 04:25 /usr/lib/libGLw.so -> libGLw.so.1 lrwxrwxrwx 1 root root 15
> > 19. Jan 04:25 /usr/lib/libGLw.so.1 -> libGLw.so.1.0.0 lrwxrwxrwx 1
> > root root 15 19. Jan 04:25 /usr/lib/libGLw.so.1.0 ->
> > libGLw.so.1.0.0 -rwxr-xr-x 1 root root 26K 19. Jan 04:25
> > /usr/lib/libGLw.so.1.0.0
> >
> > control the symlinks.
> >
> > If the linker does not look into /usr/lib something is extremly
> > broken.
>
> No, the linker is looking in /usr/lib, but it's gentoo that doesn't
> seem to want to put the libGL etc in /usr/lib...
>

because it puts the symlinks there and libGL* into /usr/lib64/opengl/...

so, are the symlinks there?

if not, retry with setting xorg-x11, then nvidia or ati.

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

Re: [gentoo-amd64] libGL can't be found...

[Hamish Marson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hemmann, Volker Armin wrote:

> On Sunday 29 January 2006 22:18, Hamish Marson wrote:
>
>> Hemmann, Volker Armin wrote:
>>
>>> On Sunday 29 January 2006 12:59, Hamish Marson wrote:
>>>
>>>> I've updated recently but am having problems with whatever
>>>> changes were made to the opengl support in Gentoo ~amd64
>>>> (recently?). Bascially if I try to emerge anythig using
>>>> opengl, I just get errors that libGL can't be found.
>>>>
>>>> Now xorg-x11 has installed it's opengl stuff in
>>>> /usr/lib/opengl/xorg-x11/lib/* and I've done an eselect to
>>>> select xorg-x11 as the current opengl implementation. But
>>>> still nothing finds it...
>>>>
>>>> Where exactly SHOULD the linking stages be looking for opengl
>>>> libs? (Including GLUT etc). And if they're not there by
>>>> default because you can eselect between different
>>>> implementations, why doesn't eselect put them where they
>>>> should be when it's told?
>>>
>>> /usr/lib
>>>
>>> ls -lh /usr/lib/libGL* lrwxrwxrwx 1 root root 42 29. Jan 04:39
>>> /usr/lib/libGLcore.so ->
>>> //usr/lib64/opengl/nvidia/lib/libGLcore.so -rw-r--r-- 1 root
>>> root 731 29. Jan 04:39 /usr/lib/libGL.la lrwxrwxrwx 1 root root
>>> 38 29. Jan 04:39 /usr/lib/libGL.so ->
>>> //usr/lib64/opengl/nvidia/lib/libGL.so -rw-r--r-- 1 root root
>>> 752 19. Jan 04:25 /usr/lib/libGLU.la lrwxrwxrwx 1 root root 11
>>> 19. Jan 04:25 /usr/lib/libGLU.so -> libGLU.so.1 lrwxrwxrwx 1
>>> root root 20 19. Jan 04:25 /usr/lib/libGLU.so.1 ->
>>> libGLU.so.1.3.060401 lrwxrwxrwx 1 root root 20 19. Jan 04:25
>>> /usr/lib/libGLU.so.1.3 -> libGLU.so.1.3.060401 -rwxr-xr-x 1
>>> root root 509K 19. Jan 04:25 /usr/lib/libGLU.so.1.3.060401
>>> lrwxrwxrwx 1 root root 11 19. Jan 04:25 /usr/lib/libGLw.so ->
>>> libGLw.so.1 lrwxrwxrwx 1 root root 15 19. Jan 04:25
>>> /usr/lib/libGLw.so.1 -> libGLw.so.1.0.0 lrwxrwxrwx 1 root root
>>> 15 19. Jan 04:25 /usr/lib/libGLw.so.1.0 -> libGLw.so.1.0.0
>>> -rwxr-xr-x 1 root root 26K 19. Jan 04:25
>>> /usr/lib/libGLw.so.1.0.0
>>>
>>> control the symlinks.
>>>
>>> If the linker does not look into /usr/lib something is extremly
>>> broken.
>>
>> No, the linker is looking in /usr/lib, but it's gentoo that
>> doesn't seem to want to put the libGL etc in /usr/lib...
>>
>
> because it puts the symlinks there and libGL* into
> /usr/lib64/opengl/...
>
> so, are the symlinks there?
>
> if not, retry with setting xorg-x11, then nvidia or ati.
>

Sorry for any confusion. When I said no the libs aren't in there, I
meant symlinks as well. (Since that's effectively put them in there).

I only have xorg-x11 installed. The ATI rubbsh never works for me
because they don't & aren't interested in supporting the PCI-ID of my
card (Saphire9600 256MB job). [Besides which I abhore proprietary
drivers. To the extent that I think I'll go OGP when it comes out if I
can afford it - but I digress].

I gather eselect is SUPPOSED to put the symlinks in there... Any tips
if it doesn't?

regards
  Hamish.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD5IJH/3QXwQQkZYwRAnWPAJ9lviQhAlp3WXuCkY/nfg68LMuQBQCfW47r
ymt1MKPrURXDk9HkKjdtgLw=
=ZMx0
-----END PGP SIGNATURE-----

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] libGL can't be found...

[Hemmann, Volker Armin]

On Saturday 04 February 2006 11:30, Hamish Marson wrote:
> Hemmann, Volker Armin wrote:
> > On Sunday 29 January 2006 22:18, Hamish Marson wrote:
> >> Hemmann, Volker Armin wrote:
> >>> On Sunday 29 January 2006 12:59, Hamish Marson wrote:
> >>>> I've updated recently but am having problems with whatever
> >>>> changes were made to the opengl support in Gentoo ~amd64
> >>>> (recently?). Bascially if I try to emerge anythig using
> >>>> opengl, I just get errors that libGL can't be found.
> >>>>
> >>>> Now xorg-x11 has installed it's opengl stuff in
> >>>> /usr/lib/opengl/xorg-x11/lib/* and I've done an eselect to
> >>>> select xorg-x11 as the current opengl implementation. But
> >>>> still nothing finds it...
> >>>>
> >>>> Where exactly SHOULD the linking stages be looking for opengl
> >>>> libs? (Including GLUT etc). And if they're not there by
> >>>> default because you can eselect between different
> >>>> implementations, why doesn't eselect put them where they
> >>>> should be when it's told?
> >>>
> >>> /usr/lib
> >>>
> >>> ls -lh /usr/lib/libGL* lrwxrwxrwx 1 root root 42 29. Jan 04:39
> >>> /usr/lib/libGLcore.so ->
> >>> //usr/lib64/opengl/nvidia/lib/libGLcore.so -rw-r--r-- 1 root
> >>> root 731 29. Jan 04:39 /usr/lib/libGL.la lrwxrwxrwx 1 root root
> >>> 38 29. Jan 04:39 /usr/lib/libGL.so ->
> >>> //usr/lib64/opengl/nvidia/lib/libGL.so -rw-r--r-- 1 root root
> >>> 752 19. Jan 04:25 /usr/lib/libGLU.la lrwxrwxrwx 1 root root 11
> >>> 19. Jan 04:25 /usr/lib/libGLU.so -> libGLU.so.1 lrwxrwxrwx 1
> >>> root root 20 19. Jan 04:25 /usr/lib/libGLU.so.1 ->
> >>> libGLU.so.1.3.060401 lrwxrwxrwx 1 root root 20 19. Jan 04:25
> >>> /usr/lib/libGLU.so.1.3 -> libGLU.so.1.3.060401 -rwxr-xr-x 1
> >>> root root 509K 19. Jan 04:25 /usr/lib/libGLU.so.1.3.060401
> >>> lrwxrwxrwx 1 root root 11 19. Jan 04:25 /usr/lib/libGLw.so ->
> >>> libGLw.so.1 lrwxrwxrwx 1 root root 15 19. Jan 04:25
> >>> /usr/lib/libGLw.so.1 -> libGLw.so.1.0.0 lrwxrwxrwx 1 root root
> >>> 15 19. Jan 04:25 /usr/lib/libGLw.so.1.0 -> libGLw.so.1.0.0
> >>> -rwxr-xr-x 1 root root 26K 19. Jan 04:25
> >>> /usr/lib/libGLw.so.1.0.0
> >>>
> >>> control the symlinks.
> >>>
> >>> If the linker does not look into /usr/lib something is extremly
> >>> broken.
> >>
> >> No, the linker is looking in /usr/lib, but it's gentoo that
> >> doesn't seem to want to put the libGL etc in /usr/lib...
> >
> > because it puts the symlinks there and libGL* into
> > /usr/lib64/opengl/...
> >
> > so, are the symlinks there?
> >
> > if not, retry with setting xorg-x11, then nvidia or ati.
>
> Sorry for any confusion. When I said no the libs aren't in there, I
> meant symlinks as well. (Since that's effectively put them in there).
>
> I only have xorg-x11 installed. The ATI rubbsh never works for me
> because they don't & aren't interested in supporting the PCI-ID of my
> card (Saphire9600 256MB job). [Besides which I abhore proprietary
> drivers. To the extent that I think I'll go OGP when it comes out if I
> can afford it - but I digress].
>
> I gather eselect is SUPPOSED to put the symlinks in there... Any tips
> if it doesn't?
>

ok, in that case look into /usr/lib/opengl/libs
you should find there is librarys&symlinks:
s -lh /usr/lib/opengl/xorg-x11/lib/
insgesamt 545K
-rw-r--r-- 1 root root  763 30. Jan 02:29 libGL.la
lrwxrwxrwx 1 root root   12 30. Jan 02:29 libGL.so -> libGL.so.1.2
lrwxrwxrwx 1 root root   12 30. Jan 02:29 libGL.so.1 -> libGL.so.1.2
-rwxr-xr-x 1 root root 537K 30. Jan 02:29 libGL.so.1.2

 cd into /usr/lib and create symlinks from the libs 
in /usr/lib/opengl(/xorg-x11 to /usr/lib

after that go into   /usr/lib/xorg/modules/extensions/ and create symlinks 
to /usr/lib/opengl/xorg-x11/extensions/libglx*
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] libGL can't be found...

[Hamish Marson]

On Sat, 2006-02-04 at 13:33 +0100, Hemmann, Volker Armin wrote:
> On Saturday 04 February 2006 11:30, Hamish Marson wrote:
> > Hemmann, Volker Armin wrote:
> > > On Sunday 29 January 2006 22:18, Hamish Marson wrote:
> > >> Hemmann, Volker Armin wrote:
> > >>> On Sunday 29 January 2006 12:59, Hamish Marson wrote:
> > >>>> I've updated recently but am having problems with whatever
> > >>>> changes were made to the opengl support in Gentoo ~amd64
> > >>>> (recently?). Bascially if I try to emerge anythig using
> > >>>> opengl, I just get errors that libGL can't be found.
> > >>>>
> > >>>> Now xorg-x11 has installed it's opengl stuff in
> > >>>> /usr/lib/opengl/xorg-x11/lib/* and I've done an eselect to
> > >>>> select xorg-x11 as the current opengl implementation. But
> > >>>> still nothing finds it...
> > >>>>
> > >>>> Where exactly SHOULD the linking stages be looking for opengl
> > >>>> libs? (Including GLUT etc). And if they're not there by
> > >>>> default because you can eselect between different
> > >>>> implementations, why doesn't eselect put them where they
> > >>>> should be when it's told?
> > >>>
> > >>> /usr/lib
> > >>>
> > >>> ls -lh /usr/lib/libGL* lrwxrwxrwx 1 root root 42 29. Jan 04:39
> > >>> /usr/lib/libGLcore.so ->
> > >>> //usr/lib64/opengl/nvidia/lib/libGLcore.so -rw-r--r-- 1 root
> > >>> root 731 29. Jan 04:39 /usr/lib/libGL.la lrwxrwxrwx 1 root root
> > >>> 38 29. Jan 04:39 /usr/lib/libGL.so ->
> > >>> //usr/lib64/opengl/nvidia/lib/libGL.so -rw-r--r-- 1 root root
> > >>> 752 19. Jan 04:25 /usr/lib/libGLU.la lrwxrwxrwx 1 root root 11
> > >>> 19. Jan 04:25 /usr/lib/libGLU.so -> libGLU.so.1 lrwxrwxrwx 1
> > >>> root root 20 19. Jan 04:25 /usr/lib/libGLU.so.1 ->
> > >>> libGLU.so.1.3.060401 lrwxrwxrwx 1 root root 20 19. Jan 04:25
> > >>> /usr/lib/libGLU.so.1.3 -> libGLU.so.1.3.060401 -rwxr-xr-x 1
> > >>> root root 509K 19. Jan 04:25 /usr/lib/libGLU.so.1.3.060401
> > >>> lrwxrwxrwx 1 root root 11 19. Jan 04:25 /usr/lib/libGLw.so ->
> > >>> libGLw.so.1 lrwxrwxrwx 1 root root 15 19. Jan 04:25
> > >>> /usr/lib/libGLw.so.1 -> libGLw.so.1.0.0 lrwxrwxrwx 1 root root
> > >>> 15 19. Jan 04:25 /usr/lib/libGLw.so.1.0 -> libGLw.so.1.0.0
> > >>> -rwxr-xr-x 1 root root 26K 19. Jan 04:25
> > >>> /usr/lib/libGLw.so.1.0.0
> > >>>
> > >>> control the symlinks.
> > >>>
> > >>> If the linker does not look into /usr/lib something is extremly
> > >>> broken.
> > >>
> > >> No, the linker is looking in /usr/lib, but it's gentoo that
> > >> doesn't seem to want to put the libGL etc in /usr/lib...
> > >
> > > because it puts the symlinks there and libGL* into
> > > /usr/lib64/opengl/...
> > >
> > > so, are the symlinks there?
> > >
> > > if not, retry with setting xorg-x11, then nvidia or ati.
> >
> > Sorry for any confusion. When I said no the libs aren't in there, I
> > meant symlinks as well. (Since that's effectively put them in there).
> >
> > I only have xorg-x11 installed. The ATI rubbsh never works for me
> > because they don't & aren't interested in supporting the PCI-ID of my
> > card (Saphire9600 256MB job). [Besides which I abhore proprietary
> > drivers. To the extent that I think I'll go OGP when it comes out if I
> > can afford it - but I digress].
> >
> > I gather eselect is SUPPOSED to put the symlinks in there... Any tips
> > if it doesn't?
> >
> 
> ok, in that case look into /usr/lib/opengl/libs
> you should find there is librarys&symlinks:
> s -lh /usr/lib/opengl/xorg-x11/lib/
> insgesamt 545K
> -rw-r--r-- 1 root root  763 30. Jan 02:29 libGL.la
> lrwxrwxrwx 1 root root   12 30. Jan 02:29 libGL.so -> libGL.so.1.2
> lrwxrwxrwx 1 root root   12 30. Jan 02:29 libGL.so.1 -> libGL.so.1.2
> -rwxr-xr-x 1 root root 537K 30. Jan 02:29 libGL.so.1.2
> 
>  cd into /usr/lib and create symlinks from the libs 
> in /usr/lib/opengl(/xorg-x11 to /usr/lib
> 
> after that go into   /usr/lib/xorg/modules/extensions/ and create symlinks 
> to /usr/lib/opengl/xorg-x11/extensions/libglx*

Sigh... Much hacking later... The damn things disappear!!! OK. I
re-emerged a lot... Update xorg-x11 as well because mythtv 0.19 needs qt
with opengl support... And my symlinks disappear... So I play with
eselect a bit & putting set -x in the relevant routins
in /usr/share/eselect/modules/opengl.eselect reveals that eselect is
busy trying to symlink opengl libs from /usr/lib32 which don't exist &
ignoring lib64...

Damn... Where is this stuff configured for eselect to do that?

H

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] libGL can't be found...

[Hemmann, Volker Armin]

On Thursday 23 February 2006 17:52, Hamish Marson wrote:
> On Sat, 2006-02-04 at 13:33 +0100, Hemmann, Volker Armin wrote:
> > On Saturday 04 February 2006 11:30, Hamish Marson wrote:
> > > Hemmann, Volker Armin wrote:
> > > > On Sunday 29 January 2006 22:18, Hamish Marson wrote:
> > > >> Hemmann, Volker Armin wrote:
> > > >>> On Sunday 29 January 2006 12:59, Hamish Marson wrote:
> > > >>>> I've updated recently but am having problems with whatever
> > > >>>> changes were made to the opengl support in Gentoo ~amd64
> > > >>>> (recently?). Bascially if I try to emerge anythig using
> > > >>>> opengl, I just get errors that libGL can't be found.
> > > >>>>
> > > >>>> Now xorg-x11 has installed it's opengl stuff in
> > > >>>> /usr/lib/opengl/xorg-x11/lib/* and I've done an eselect to
> > > >>>> select xorg-x11 as the current opengl implementation. But
> > > >>>> still nothing finds it...
> > > >>>>
> > > >>>> Where exactly SHOULD the linking stages be looking for opengl
> > > >>>> libs? (Including GLUT etc). And if they're not there by
> > > >>>> default because you can eselect between different
> > > >>>> implementations, why doesn't eselect put them where they
> > > >>>> should be when it's told?
> > > >>>
> > > >>> /usr/lib
> > > >>>
> > > >>> ls -lh /usr/lib/libGL* lrwxrwxrwx 1 root root 42 29. Jan 04:39
> > > >>> /usr/lib/libGLcore.so ->
> > > >>> //usr/lib64/opengl/nvidia/lib/libGLcore.so -rw-r--r-- 1 root
> > > >>> root 731 29. Jan 04:39 /usr/lib/libGL.la lrwxrwxrwx 1 root root
> > > >>> 38 29. Jan 04:39 /usr/lib/libGL.so ->
> > > >>> //usr/lib64/opengl/nvidia/lib/libGL.so -rw-r--r-- 1 root root
> > > >>> 752 19. Jan 04:25 /usr/lib/libGLU.la lrwxrwxrwx 1 root root 11
> > > >>> 19. Jan 04:25 /usr/lib/libGLU.so -> libGLU.so.1 lrwxrwxrwx 1
> > > >>> root root 20 19. Jan 04:25 /usr/lib/libGLU.so.1 ->
> > > >>> libGLU.so.1.3.060401 lrwxrwxrwx 1 root root 20 19. Jan 04:25
> > > >>> /usr/lib/libGLU.so.1.3 -> libGLU.so.1.3.060401 -rwxr-xr-x 1
> > > >>> root root 509K 19. Jan 04:25 /usr/lib/libGLU.so.1.3.060401
> > > >>> lrwxrwxrwx 1 root root 11 19. Jan 04:25 /usr/lib/libGLw.so ->
> > > >>> libGLw.so.1 lrwxrwxrwx 1 root root 15 19. Jan 04:25
> > > >>> /usr/lib/libGLw.so.1 -> libGLw.so.1.0.0 lrwxrwxrwx 1 root root
> > > >>> 15 19. Jan 04:25 /usr/lib/libGLw.so.1.0 -> libGLw.so.1.0.0
> > > >>> -rwxr-xr-x 1 root root 26K 19. Jan 04:25
> > > >>> /usr/lib/libGLw.so.1.0.0
> > > >>>
> > > >>> control the symlinks.
> > > >>>
> > > >>> If the linker does not look into /usr/lib something is extremly
> > > >>> broken.
> > > >>
> > > >> No, the linker is looking in /usr/lib, but it's gentoo that
> > > >> doesn't seem to want to put the libGL etc in /usr/lib...
> > > >
> > > > because it puts the symlinks there and libGL* into
> > > > /usr/lib64/opengl/...
> > > >
> > > > so, are the symlinks there?
> > > >
> > > > if not, retry with setting xorg-x11, then nvidia or ati.
> > >
> > > Sorry for any confusion. When I said no the libs aren't in there, I
> > > meant symlinks as well. (Since that's effectively put them in there).
> > >
> > > I only have xorg-x11 installed. The ATI rubbsh never works for me
> > > because they don't & aren't interested in supporting the PCI-ID of my
> > > card (Saphire9600 256MB job). [Besides which I abhore proprietary
> > > drivers. To the extent that I think I'll go OGP when it comes out if I
> > > can afford it - but I digress].
> > >
> > > I gather eselect is SUPPOSED to put the symlinks in there... Any tips
> > > if it doesn't?
> >
> > ok, in that case look into /usr/lib/opengl/libs
> > you should find there is librarys&symlinks:
> > s -lh /usr/lib/opengl/xorg-x11/lib/
> > insgesamt 545K
> > -rw-r--r-- 1 root root  763 30. Jan 02:29 libGL.la
> > lrwxrwxrwx 1 root root   12 30. Jan 02:29 libGL.so -> libGL.so.1.2
> > lrwxrwxrwx 1 root root   12 30. Jan 02:29 libGL.so.1 -> libGL.so.1.2
> > -rwxr-xr-x 1 root root 537K 30. Jan 02:29 libGL.so.1.2
> >
> >  cd into /usr/lib and create symlinks from the libs
> > in /usr/lib/opengl(/xorg-x11 to /usr/lib
> >
> > after that go into   /usr/lib/xorg/modules/extensions/ and create
> > symlinks to /usr/lib/opengl/xorg-x11/extensions/libglx*
>
> Sigh... Much hacking later... The damn things disappear!!! OK. I
> re-emerged a lot... Update xorg-x11 as well because mythtv 0.19 needs qt
> with opengl support... And my symlinks disappear... So I play with
> eselect a bit & putting set -x in the relevant routins
> in /usr/share/eselect/modules/opengl.eselect reveals that eselect is
> busy trying to symlink opengl libs from /usr/lib32 which don't exist &
> ignoring lib64...
>
> Damn... Where is this stuff configured for eselect to do that?

hm, where does your /etc/profile points to?
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: libGL can't be found...

[Duncan]

Hamish Marson posted <1140713563.16708.26.camel@ballbreaker>, excerpted
below,  on Thu, 23 Feb 2006 16:52:43 +0000:

> Sigh... Much hacking later... The damn things disappear!!! OK. I
> re-emerged a lot... Update xorg-x11 as well because mythtv 0.19 needs qt
> with opengl support... And my symlinks disappear... So I play with
> eselect a bit & putting set -x in the relevant routins in
> /usr/share/eselect/modules/opengl.eselect reveals that eselect is busy
> trying to symlink opengl libs from /usr/lib32 which don't exist &
> ignoring lib64...
> 
> Damn... Where is this stuff configured for eselect to do that?

Isn't eselect still ~amd64?  This is probably one of the reasons.

$earch app-admin/eselect
eselect-0.9.6[0]:
eselect-1.0_rc1[0]:
eselect-1.0_rc2[0]:
eselect-1.0[0]: ~alpha ~amd64 ~arm ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86

Yes...  nothing stable on any arch.  Only ~arch for everything.  (earch is
a script I picked up on the dev list.  As you can see, it lists the
versions of a package [and the slot, 0 above as eselect is unslotted] with
the associated arch keywording.)

Those running the default multilib amd64 profiles who've upgraded gcc
since they've merged eselect are likely aware of another issue as well.
eselect compiler doesn't yet properly manage the 32-bit compiler
selection, when gcc is upgraded, so if the upgrade is in the same slot (as
is the case every time we upgrade the weekly gcc-4.1 cvs snapshots, for
those running it), the 32-bit compiler ends up pointing at the previous
version for that slot, which no longer exists!  eselect compiler must be
run manually to switch to the new 32-bit gcc.  Likewise, the old compiler
profile file isn't removed when the old gcc is unmerged, so eselect
continues to list stale gcc versions as choices until the associated
profile is removed manually.

Folks like me that run a ~arch system should expect such less than smooth
operation, from time to time, and in fact many of us enjoy the challenge
(I definitely do), so it's no big deal, even if it /does/ get slightly
frustrating from time to time.  It's all in the game!

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: libGL can't be found...

[D. Wokan]

Duncan wrote:
> Hamish Marson posted <1140713563.16708.26.camel@ballbreaker>, excerpted
> below,  on Thu, 23 Feb 2006 16:52:43 +0000:
> 
>> Sigh... Much hacking later... The damn things disappear!!! OK. I
>> re-emerged a lot... Update xorg-x11 as well because mythtv 0.19 needs qt
>> with opengl support... And my symlinks disappear... So I play with
>> eselect a bit & putting set -x in the relevant routins in
>> /usr/share/eselect/modules/opengl.eselect reveals that eselect is busy
>> trying to symlink opengl libs from /usr/lib32 which don't exist &
>> ignoring lib64...
>>
>> Damn... Where is this stuff configured for eselect to do that?
> 
> Isn't eselect still ~amd64?  This is probably one of the reasons.
> 
> $earch app-admin/eselect
> eselect-0.9.6[0]:
> eselect-1.0_rc1[0]:
> eselect-1.0_rc2[0]:
> eselect-1.0[0]: ~alpha ~amd64 ~arm ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86
> 
> Yes...  nothing stable on any arch.  Only ~arch for everything.  (earch is
> a script I picked up on the dev list.  As you can see, it lists the
> versions of a package [and the slot, 0 above as eselect is unslotted] with
> the associated arch keywording.)
> 
> Those running the default multilib amd64 profiles who've upgraded gcc
> since they've merged eselect are likely aware of another issue as well.
> eselect compiler doesn't yet properly manage the 32-bit compiler
> selection, when gcc is upgraded, so if the upgrade is in the same slot (as
> is the case every time we upgrade the weekly gcc-4.1 cvs snapshots, for
> those running it), the 32-bit compiler ends up pointing at the previous
> version for that slot, which no longer exists!  eselect compiler must be
> run manually to switch to the new 32-bit gcc.  Likewise, the old compiler
> profile file isn't removed when the old gcc is unmerged, so eselect
> continues to list stale gcc versions as choices until the associated
> profile is removed manually.
> 
> Folks like me that run a ~arch system should expect such less than smooth
> operation, from time to time, and in fact many of us enjoy the challenge
> (I definitely do), so it's no big deal, even if it /does/ get slightly
> frustrating from time to time.  It's all in the game!
> 

Any chance someone could put together an ebuild for earch so those of us 
who missed it on the dev list can install it?  While I realize I could 
go digging through ebuilds one by one to see what's x86 and ~amd64, it 
would be easier to just have a script pull out that info for me.  I'd 
like to help wherever I can in getting x86/~amd64 stuff tested and fixed.
--
D. Wokan
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: libGL can't be found...

[Duncan]

D. Wokan posted <43FF895B.1060305@cox.net>, excerpted below,  on Fri, 24
Feb 2006 15:31:55 -0700:

> Any chance someone could put together an ebuild for earch so those of us 
> who missed it on the dev list can install it?  While I realize I could 
> go digging through ebuilds one by one to see what's x86 and ~amd64, it 
> would be easier to just have a script pull out that info for me.  I'd 
> like to help wherever I can in getting x86/~amd64 stuff tested and fixed.

It's only a single python script file, not entirely huge either, as I got
it directly off the dev list, so an ebuild isn't entirely necessary.
Simply grab the script and save it to /usr/local/bin or sbin, or wherever
else you want to keep it (~/bin, maybe?), as desired, then adjust your
path if necessary. The /usr/local/ location is simply the traditional
place to keep system stuff not managed by the package manager (portage for
Gentoo), making it easier to track (and it's already in the default path,
IIRC).

Of course, anything not installed from the main portage tree, regardless
of whether it's installed directly or from an ebuild, is out of the
regular Gentoo security management regime, so it's up to you as the
administrator to worry about possible security issues and/or checking for
updates, but that just comes with the territory.

Looking at the comments in the script and quickly checking dev.gentoo.org...

eldad is original author.  The version on his dev page is outdated, but
there looks to be some other interesting stuff there, so ...

http://dev.gentoo.org/~eldad/

robbat2 has updated it.  Actually, it appears the 0.8 version I have is
outdated and there's now a 0.9 version.  See what I mean about having to
keep stuff updated manually?  Again, it's reasonable to assume if you find
earch interesting as he obviously did, that some of the other stuff he has
there may be equally interesting/useful.  I haven't actually checked it
out yet myself, but I'm going to after I post this.  (satanspetferret?? 
Sounds intriguing! <g>)

http://dev.gentoo.org/~robbat2/

Direct link to earch-0.9, for those that prefer:

http://dev.gentoo.org/~robbat2/earch-0.9

s/0.9/0.8/ if you prefer the older version I'm currently using and know
works.  He has versions back further than that, too, that might be
interesting for those that know or are learning python, that wish to trace
the evolution of the script.

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list