Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 199633 - x11-drivers/ati-drivers-8.42.3 libGL.so.1.2 has wrong SONAME
Summary: x11-drivers/ati-drivers-8.42.3 libGL.so.1.2 has wrong SONAME
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: X11 External Driver Maintainers
URL:
Whiteboard:
Keywords:
: 200754 201331 201348 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-11-19 06:14 UTC by Bernd Steinhauser
Modified: 2008-03-06 10:59 UTC (History)
16 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
eselect-opengl.patch (easy workaround) (eselect-opengl.patch,478 bytes, patch)
2007-11-19 06:17 UTC, Bernd Steinhauser
Details | Diff
eselect-opengl-1.0.5.ebuild.patch (eselect-opengl-1.0.5.ebuild.patch,685 bytes, patch)
2007-11-19 06:18 UTC, Bernd Steinhauser
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Bernd Steinhauser 2007-11-19 06:14:04 UTC
With the new driver there has been a problem introduced. The library libGL.so.1.2 has the wrong SONAME:
readelf -d 8.42.3/arch/x86_64/usr/X11R6/lib64/libGL.so.1.2
*snip*
0x000000000000000e (SONAME)             Library soname: [libGL.so.1.2]

while it should be:
0x000000000000000e (SONAME)             Library soname: [libGL.so.1]

This leads to the problem, that without further modification, after the driver has been installed and eselect switched opengl to ati, applications, that use opengl with show an error about missing this library.

There is a possibility to fix this (actually not fix it, but there is a workaround). eselect-opengl currently creates one symlink.
/usr/lib/libGL.so -> /usr/lib/opengl/ati/lib/libGL.so

If one creates the symlinks
/usr/lib/libGL.so.1 -> /usr/lib/libGL.so
/usr/lib/libGL.so.1.2 -> /usr/lib/libGL.so
the applications will work again.

So the workaround is to let eselect create three symlinks instead of only one.
Either:
/usr/lib/libGL.so.1.2 -> /usr/lib/opengl/ati/lib/libGL.so.1.2
/usr/lib/libGL.so.1 -> /usr/lib/libGL.so.1.2
/usr/lib/libGL.so -> /usr/lib/libGL.so.1.2

or:
/usr/lib/libGL.so.1.2 -> /usr/lib/opengl/ati/lib/libGL.so.1.2
/usr/lib/libGL.so.1 -> /usr/lib/opengl/ati/lib/libGL.so.1
/usr/lib/libGL.so -> /usr/lib/opengl/ati/lib/libGL.so

The second one obviously doesn't need much modification.

The other possibility would be to add a warning to ati-drivers ebuild, that users should create this symlink manually. 

Reproducible: Always

Steps to Reproduce:
1. emerge =ati-drivers-8.42.3
2. Make sure there is only the link, that eselect created
3. Run glxgears

Actual Results:  
glxgears will crash:
glxgears: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory


See also bug 196820, there comment 5, 44, 56.
http://ati.cchtml.com/show_bug.cgi?id=843
Comment 1 Bernd Steinhauser 2007-11-19 06:17:01 UTC
Created attachment 136346 [details, diff]
eselect-opengl.patch (easy workaround)

This is an easy workaround for this problem.
Although it is not the best solution I guess, but it works for me.

I don't know if there is something wrong with eselect-opengl creating three symlinks instead of only one.
Comment 2 Bernd Steinhauser 2007-11-19 06:18:23 UTC
Created attachment 136348 [details, diff]
eselect-opengl-1.0.5.ebuild.patch

Patch for the ebuild.
Comment 3 Bernd Steinhauser 2007-11-21 23:31:27 UTC
This problem also exists with the new 7.11 driver version released today.
Comment 4 R!tman 2007-11-25 10:04:21 UTC
Because of this bug ati-drivers-8.42.3 doesn't work. This version of ati-drivers should have a dependency to an eselect-opengl version that makes the whole thing work!
Comment 5 Jory A. Pratt gentoo-dev 2007-11-26 13:29:15 UTC
I am working with upstream to fix this soname issue as fast as possible give me a day or so and I will have  some news on this issue.
Comment 6 Jakub Moc (RETIRED) gentoo-dev 2007-11-28 19:48:59 UTC
Comment on attachment 136346 [details, diff]
eselect-opengl.patch (easy workaround)

This clearly isn't an eselect-opengl issue; as such, patching eselect-opengl doesn't make sense.
Comment 7 Bernd Steinhauser 2007-11-28 19:55:16 UTC
(In reply to comment #6)
> (From update of attachment 136346 [details, diff] [edit])
> This clearly isn't an eselect-opengl issue; as such, patching eselect-opengl
> doesn't make sense.
> 

I didn't say, that it is an eselect-opengl issue.
I said, that it is a possible workaround. Not more.
Comment 8 Jakub Moc (RETIRED) gentoo-dev 2007-11-29 21:07:14 UTC
*** Bug 200754 has been marked as a duplicate of this bug. ***
Comment 9 Jory A. Pratt gentoo-dev 2007-11-30 03:00:19 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > (From update of attachment 136346 [details, diff] [edit] [edit])
> > This clearly isn't an eselect-opengl issue; as such, patching eselect-opengl
> > doesn't make sense.
> > 
> 
> I didn't say, that it is an eselect-opengl issue.
> I said, that it is a possible workaround. Not more.
> 

I am still waiting to hear back from upstream. More distros are jumping on the ban wagon about the soname being incorrect. I will poke them again to see what we can get before 8.45x is released.
Comment 10 Jory A. Pratt gentoo-dev 2007-12-03 21:36:09 UTC
The soname is being discussed with the component team in question.

Regards,

Matthew
Comment 11 Jakub Moc (RETIRED) gentoo-dev 2007-12-05 08:23:16 UTC
*** Bug 201331 has been marked as a duplicate of this bug. ***
Comment 12 Jakub Moc (RETIRED) gentoo-dev 2007-12-05 12:52:37 UTC
*** Bug 201348 has been marked as a duplicate of this bug. ***
Comment 13 Ákos Maróy 2007-12-05 13:02:09 UTC
I have been referred here for filing a duplicate bug. I don't see a solution anywhere.

is it so that there are no ati-drivers package in Gentoo currently that actually work?
Comment 14 Bernd Steinhauser 2007-12-05 13:31:34 UTC
(In reply to comment #13)
> I have been referred here for filing a duplicate bug. I don't see a solution
> anywhere.
> 
> is it so that there are no ati-drivers package in Gentoo currently that
> actually work?
> 

As a dirty workaround you can create a symlink, see my first post in this bug.
And no, there are no ati-drivers >=8.40.4 currently in the tree, that work out of the box without this problem.

Comment 15 Ákos Maróy 2007-12-05 13:33:32 UTC
yes, I made the workaround

but if 8.40.4 is also broken - that's actually the ebuild marked stable. kind of beats the idea of 'stable', if it's well known to be broken...
Comment 16 Bernd Steinhauser 2007-12-05 13:50:58 UTC
(In reply to comment #15)
> yes, I made the workaround
> 
> but if 8.40.4 is also broken - that's actually the ebuild marked stable. kind
> of beats the idea of 'stable', if it's well known to be broken...
> 

Oops, my fault, I meant > and not >=.
8.40.4 is ok, it doesn't have this problem.

Comment 17 Ákos Maróy 2007-12-05 13:56:50 UTC
I'm sad to inform you that 8.40.4 also has this problem, see my related bugreport Bug 201348 , marked as a duplicate of this one...
Comment 18 Jory A. Pratt gentoo-dev 2007-12-05 14:05:53 UTC
(In reply to comment #17)
> I'm sad to inform you that 8.40.4 also has this problem, see my related
> bugreport Bug 201348 , marked as a duplicate of this one...
> 

umm incorrect it is fine just env-update and your problem will be resolved.
Comment 19 Ákos Maróy 2007-12-05 14:16:55 UTC
fair enough - I seem to have missed env-update before running eselect again.. 8.40.4 indeed works..
Comment 20 William L. Thomson Jr. (RETIRED) gentoo-dev 2007-12-05 15:10:23 UTC
For the record I have no problems with 8.42.3, or 8.433/7.11. I get that others are having problems. I just don't understand why I am not seeing them or running into them as others are. Very likely I am missing something, that others are doing. Not sure what that is though.

eselect works fine for me, I can switch back and forth from ati to xorg-x11 without and problem. I really don't get it, why I don't have any problems ;)
Not sure if it makes any difference but for the record I am running entirely ~amd64. Might be a result of mixing ~arch with arch.
Comment 21 Bernd Steinhauser 2007-12-05 15:21:15 UTC
(In reply to comment #20)
> For the record I have no problems with 8.42.3, or 8.433/7.11. I get that others
> are having problems. I just don't understand why I am not seeing them or
> running into them as others are. Very likely I am missing something, that
> others are doing. Not sure what that is though.
> 
> eselect works fine for me, I can switch back and forth from ati to xorg-x11
> without and problem. I really don't get it, why I don't have any problems ;)
> Not sure if it makes any difference but for the record I am running entirely
> ~amd64. Might be a result of mixing ~arch with arch.
> 
Does it still work, if you make sure, there are now symlinks:
/usr/lib/libGL.so.1 -> /usr/lib/libGL.so
/usr/lib/libGL.so.1.2 -> /usr/lib/libGL.so

and then run:
eselect opengl set at
Comment 22 William L. Thomson Jr. (RETIRED) gentoo-dev 2007-12-05 15:41:07 UTC
wlt@wlt ~ $ ls -l /usr/lib/libGL.*
-rw-r--r-- 1 root root 706 Dec  2 22:37 /usr/lib/libGL.la
lrwxrwxrwx 1 root root  35 Dec  2 22:37 /usr/lib/libGL.so -> //usr/lib64/opengl/ati/lib/libGL.so
lrwxrwxrwx 1 root root   8 Nov 12 00:52 /usr/lib/libGL.so.1 -> libGL.so
lrwxrwxrwx 1 root root  10 Nov 12 00:55 /usr/lib/libGL.so.1.2 -> libGL.so.1

wlt wlt # eselect opengl set xorg-x11
Switching to xorg-x11 OpenGL interface... done
wlt wlt # ls -l /usr/lib/libGL.*
-rw-r--r-- 1 root root 747 Dec  5 10:39 /usr/lib/libGL.la
lrwxrwxrwx 1 root root  39 Dec  5 10:39 /usr/lib/libGL.so -> /usr/lib64/opengl/xorg-x11/lib/libGL.so
lrwxrwxrwx 1 root root   8 Nov 12 00:52 /usr/lib/libGL.so.1 -> libGL.so
lrwxrwxrwx 1 root root  10 Nov 12 00:55 /usr/lib/libGL.so.1.2 -> libGL.so.1

wlt wlt # eselect opengl set ati     
Switching to ati OpenGL interface... done
wlt wlt # ls -l /usr/lib/libGL.*
-rw-r--r-- 1 root root 706 Dec  5 10:39 /usr/lib/libGL.la
lrwxrwxrwx 1 root root  34 Dec  5 10:39 /usr/lib/libGL.so -> /usr/lib64/opengl/ati/lib/libGL.so
lrwxrwxrwx 1 root root   8 Nov 12 00:52 /usr/lib/libGL.so.1 -> libGL.so
lrwxrwxrwx 1 root root  10 Nov 12 00:55 /usr/lib/libGL.so.1.2 -> libGL.so.1

Looks fine to me? I don't have any issues with any apps? Others were unable to launch some apps, others crashed. Things are fine for me :)
Comment 23 Bernd Steinhauser 2007-12-05 15:52:55 UTC
(In reply to comment #22)
> wlt@wlt ~ $ ls -l /usr/lib/libGL.*
> -rw-r--r-- 1 root root 706 Dec  2 22:37 /usr/lib/libGL.la
> lrwxrwxrwx 1 root root  35 Dec  2 22:37 /usr/lib/libGL.so ->
> //usr/lib64/opengl/ati/lib/libGL.so
> lrwxrwxrwx 1 root root   8 Nov 12 00:52 /usr/lib/libGL.so.1 -> libGL.so
> lrwxrwxrwx 1 root root  10 Nov 12 00:55 /usr/lib/libGL.so.1.2 -> libGL.so.1

Well, then of course you don't have problems. 
eselect will only touch /usr/lib/libGL.so and is not interested in those other two.
You did create them on your on I suspect (maybe you can't remember).
If you remove those symlinks, the problems will start.
Creating symlinks, just like you did is a possible workaround as I mentioned in comment 1.

> Looks fine to me? I don't have any issues with any apps? Others were unable to
> launch some apps, others crashed. Things are fine for me :)
> 

Of course applications run, but the problem (has wrong SONAME) is still present.
You can check it with:
eselect opengl set ati
readelf -d /usr/lib/libGL.so |grep SONAME
and it will print out, that the SONAME is libGL.so.1.2 and not libGL.so.1.
Comment 24 William L. Thomson Jr. (RETIRED) gentoo-dev 2007-12-05 16:28:32 UTC
(In reply to comment #23)
>
> Well, then of course you don't have problems. 
> eselect will only touch /usr/lib/libGL.so and is not interested in those other
> two.
> You did create them on your on I suspect (maybe you can't remember).

No I have no clue where they came from. But I KNOW I didn't create them. equery isn't showing them belong to a package. So it's not helping me prove that. I have created some symlinks it the past. But it was long ago since the last time I did that. These days I usually bite the bullet and recompile stuff or etc. But it wasn't libGL, last one I believe was expat :)

> If you remove those symlinks, the problems will start.
> Creating symlinks, just like you did is a possible workaround as I mentioned in
> comment 1.

I will remove, and see if they get re-created. They were created 3 seconds apart, Nov 12. Which is kinda slow for a script or ebuild. I wasn't even running 8.42.3 then. I did several days later and made the commit of 8.42.3 on Nov 19th.  Maybe I did create them, but should remember since it would be in the last month, or few weeks.

If I did create them it surely wasn't for 8.42.3. I know what I did there, and it was just copy ebuild in tree. Merge some mods/patches from a bug, test, and commit. No creation of links or etc. But no clue where they came from..

Will see if I can get something to re-create them.

> Of course applications run, but the problem (has wrong SONAME) is still
> present.
> You can check it with:
> eselect opengl set ati
> readelf -d /usr/lib/libGL.so |grep SONAME
> and it will print out, that the SONAME is libGL.so.1.2 and not libGL.so.1.

Yeah I confirmed that, but I should have linking problems and etc as others are. Unless recompiling makes any difference there? No clue, but one would think a wrong SONAME would cause some apps to act up and etc. Sure seemed like it was for others.


Comment 25 Jory A. Pratt gentoo-dev 2007-12-09 15:50:31 UTC
(In reply to comment #24)
> No I have no clue where they came from. 
> Will see if I can get something to re-create them.

An older version of eselect used to set up all three symlinks, this is most likely where yours came from and hense you did not see the problem. As soon as the soname is fixed the eselect issue will be resolved. I am still waiting to hear from the component team as to what they plan to do.
Comment 26 Bernd Steinhauser 2007-12-09 17:01:24 UTC
(In reply to comment #25)
> (In reply to comment #24)
> > No I have no clue where they came from. 
> > Will see if I can get something to re-create them.
> 
> An older version of eselect used to set up all three symlinks, this is most
> likely where yours came from and hense you did not see the problem. As soon as
> the soname is fixed the eselect issue will be resolved. I am still waiting to
> hear from the component team as to what they plan to do.
> 
Hm, maybe small corrections here?
There is no "eselect issue", I just posted that as a workaround. ;-)
Comment 27 Chris Henhawke (RETIRED) gentoo-dev 2007-12-10 10:59:52 UTC
I recently updated to 8.433 and got felled by this issue, I was able to fix it by doing a revdep-rebuild --libary=libGL.so.1 (as well as .so, and .so.1.2)... Only things that don't work for me at this moment are:

Wine - it crashes, even when running winecfg.  Could be related to http://bugs.winehq.org/show_bug.cgi?id=4561
Cedega - same thing, except I don't get any pagefault info.
GL screensavers - they won't display fullscreen.  In windowed mode they are fine, but if I run one in fullscreen, I get a black screen.  Could be completely unrelated, as I've had this particular issue off and on for a long time.

Other GL stuff works great, and with a performance boost.  I can play doom3 for once without it lagging.

[ebuild   R   ] x11-drivers/ati-drivers-8.433  USE="acpi -debug" 0 kB

lrwxrwxrwx 1 root root     34 Dec  8 01:47 /usr/lib/libGL.so -> //usr//lib/opengl/ati/lib/libGL.so
lrwxrwxrwx 1 root root     17 Dec  6 09:33 /usr/lib/libGL.so.1 -> /usr/lib/libGL.so
lrwxrwxrwx 1 root root     17 Dec  6 09:33 /usr/lib/libGL.so.1.2 -> /usr/lib/libGL.so

(ignore the timestamps, i was playing with the symlinks then realized that it's not eselect at fault)
Comment 28 Bernd Steinhauser 2007-12-10 11:21:32 UTC
(In reply to comment #27)
> I recently updated to 8.433 and got felled by this issue, I was able to fix it
> by doing a revdep-rebuild --libary=libGL.so.1 (as well as .so, and .so.1.2)...
> Only things that don't work for me at this moment are:
How can revdep-rebuild fix this?

> Wine - it crashes, even when running winecfg.  Could be related to
> http://bugs.winehq.org/show_bug.cgi?id=4561
> Cedega - same thing, except I don't get any pagefault info.
> GL screensavers - they won't display fullscreen.  In windowed mode they are
> fine, but if I run one in fullscreen, I get a black screen.  Could be
> completely unrelated, as I've had this particular issue off and on for a long
> time.
winecfg works here. I didn't try Cedega.
GL screensavers will lead into a lock, I can reproduce that. I didn't know that yet.
Maybe I'll try to squeeze some information out of it with netconsole, when I have some time.
But it seems to be a different problem.
I suggest you open up a new bug about that, I also didn't find a bug on ATI's list yet.
Could you try 8.42.3 and report (on the new bug), if the problem exists there, too?

> lrwxrwxrwx 1 root root     34 Dec  8 01:47 /usr/lib/libGL.so ->
> //usr//lib/opengl/ati/lib/libGL.so
> lrwxrwxrwx 1 root root     17 Dec  6 09:33 /usr/lib/libGL.so.1 ->
> /usr/lib/libGL.so
> lrwxrwxrwx 1 root root     17 Dec  6 09:33 /usr/lib/libGL.so.1.2 ->
> /usr/lib/libGL.so
If you have got these symlinks, then you won't experience this problem.
But this only a workaround. The real fix can only be made by ATI people, because the driver is closed source.
Comment 29 Chris Henhawke (RETIRED) gentoo-dev 2007-12-10 11:35:33 UTC
(In reply to comment #28)
> How can revdep-rebuild fix this?

Every GL app I tried was throwing "error while loading shared libraries: libGL.so.1" etc, so revdep was able to fix this... but you have to specify the library or else revdep walks right past it.

> Could you try 8.42.3 and report (on the new bug), if the problem exists there,
> too?

Give me a couple days and I'd be glad to try...

Hrm, it seems I also forgot to post this:

# readelf -d /usr/lib/libGL.so.1.2 | grep SONAME
 0x0000000e (SONAME)                     Library soname: [libGL.so.1.2]

Is that not the issue at hand?
Comment 30 Bernd Steinhauser 2007-12-10 12:13:52 UTC
(In reply to comment #29)
> (In reply to comment #28)
> > How can revdep-rebuild fix this?
> 
> Every GL app I tried was throwing "error while loading shared libraries:
> libGL.so.1" etc, so revdep was able to fix this... but you have to specify the
> library or else revdep walks right past it.
revdep-rebuild (afaik) can only re-emerge packages to fix missing libraries. Since this problem can't be fixed by re-emerging a package (ati-drivers) it can't be fixed by revdep-rebuild.
But because it doesn't cost anything I tried it and it doesn't work.
The problem went away for you, because you do provide those symlinks you mentioned.
Neither current eselect nor ati-drivers do create those symlinks, so they are either a leftover from older eselect (was mentioned above) or you created them.

> Hrm, it seems I also forgot to post this:
> 
> # readelf -d /usr/lib/libGL.so.1.2 | grep SONAME
>  0x0000000e (SONAME)                     Library soname: [libGL.so.1.2]
> 
> Is that not the issue at hand?
Yes, that is it, but you did not fix it, you applied a workaround by providing those symlinks.
Comment 31 Chris Henhawke (RETIRED) gentoo-dev 2007-12-10 12:25:53 UTC
(In reply to comment #30)
> Neither current eselect nor ati-drivers do create those symlinks, so they are
> either a leftover from older eselect (was mentioned above) or you created them.

taking a look at mesa-6.5.2-r1.ebuild, it is what creates them.

# Create required symlinks
	if [[ ${CHOST} == *-freebsd* ]]; then
		# FreeBSD doesn't use major.minor versioning, so the library is only
		# libGL.so.1 and no libGL.so.1.2 is ever used there, thus only create
		# libGL.so symlink and leave libGL.so.1 being the real thing
		dosym libGL.so.1 /usr/$(get_libdir)/libGL.so
	else
		dosym libGL.so.1.2 /usr/$(get_libdir)/libGL.so
		dosym libGL.so.1.2 /usr/$(get_libdir)/libGL.so.1
	fi
Comment 32 Bernd Steinhauser 2007-12-10 12:59:06 UTC
(In reply to comment #31)
> (In reply to comment #30)
> > Neither current eselect nor ati-drivers do create those symlinks, so they are
> > either a leftover from older eselect (was mentioned above) or you created them.
> 
> taking a look at mesa-6.5.2-r1.ebuild, it is what creates them.
> 
> # Create required symlinks
>         if [[ ${CHOST} == *-freebsd* ]]; then
>                 # FreeBSD doesn't use major.minor versioning, so the library is
> only
>                 # libGL.so.1 and no libGL.so.1.2 is ever used there, thus only
> create
>                 # libGL.so symlink and leave libGL.so.1 being the real thing
>                 dosym libGL.so.1 /usr/$(get_libdir)/libGL.so
>         else
>                 dosym libGL.so.1.2 /usr/$(get_libdir)/libGL.so
>                 dosym libGL.so.1.2 /usr/$(get_libdir)/libGL.so.1
>         fi
> 

No, first I just tried it, and it doesn't create symlinks. ;)
Second if you look at that you'll see, that it will create symlinks, but they aren't what you expect there. After fix_opengl_symlinks() they run dynamic_libgl_install() and it that you will find:
mv -f ${x} "${D}"/usr/$(get_libdir)/opengl/${OPENGL_DIR}/lib

So the symlinked files are actually those in /usr/lib/opengl/xorg-x11/lib.

Maybe I should emphasize this again:
There is "no" package except eselect-opengl, that should touch /usr/lib/libGL.so*.
And hopefully there is no package except eselect-opengl that does and if there is one it would be a bug in that ebuild.

Comment 33 Chris Henhawke (RETIRED) gentoo-dev 2007-12-10 13:24:41 UTC
(In reply to comment #32)

> Maybe I should emphasize this again:
> There is "no" package except eselect-opengl, that should touch
> /usr/lib/libGL.so*.
> And hopefully there is no package except eselect-opengl that does and if there
> is one it would be a bug in that ebuild.
> 

So I browsed the entire opengl.eselect-1.0.5 script and found no reference to creating or verifying for those symlinks.  I agree with Jakub in his assessment.
Comment 34 Bernd Steinhauser 2007-12-10 13:33:13 UTC
(In reply to comment #33)
> (In reply to comment #32)
> So I browsed the entire opengl.eselect-1.0.5 script and found no reference to
> creating or verifying for those symlinks.  I agree with Jakub in his
> assessment.
Noone ever said, that it is an eselect-opengl issue. 
Also noone ever said, that it can be "fixed" by eselect-opengl.

With a patch similar to the one I posted it would be possible to create a workaround(!) for the time till ATI(!) fixed this, we can't fix it, we can only create a workaround.
That doesn't make it an issue of eselect-opengl, I've never said that.
Comment 35 Daniel Kreßner 2007-12-11 23:04:56 UTC
Workarround

# ln -s /usr/lib/opengl/ati/lib/libGL.so.1 /usr/lib/libGL.so.1

works for me
Comment 36 Jory A. Pratt gentoo-dev 2007-12-13 00:26:23 UTC
As I said I would update ya on the info from upstream here it is.

8.44x will be out in the next week or so. This does fix this soname ( restores it to original soname ). There are many other bug fixes in this release I will not mention I will make sure they are included in the changelog when je_fro pushes it to the tree.

eselect will be fine no changes when this hits the tree make sure you remove your symlinks they will not be needed any longer.
Comment 37 real.nemesis87 2007-12-20 09:44:20 UTC
hi i did the workaround and then found out that the driver is to buggy for me. then i switched back to 8.40.4 and when i do

# glxinfo | grep direct

i get

X Error of failed request:  GLXBadContext
  Major opcode of failed request:  142 (GLX)
  Minor opcode of failed request:  5 (X_GLXMakeCurrent)
  Serial number of failed request:  15
  Current serial number in output stream:  15


can anybody help me to solve this problem?
Comment 38 Bernd Steinhauser 2007-12-20 22:52:39 UTC
(In reply to comment #36)
> As I said I would update ya on the info from upstream here it is.
Indeed, it has been fixed with 8.443.1:

readelf -d 8.443.1/arch/x86_64/usr/X11R6/lib64/libGL.so.1.2
---
0x000000000000000e (SONAME)             Library soname: [libGL.so.1]
---
Comment 39 Sabeeh Baig 2008-01-01 18:13:39 UTC
(In reply to comment #38)
> (In reply to comment #36)
> > As I said I would update ya on the info from upstream here it is.
> Indeed, it has been fixed with 8.443.1:
> 
> readelf -d 8.443.1/arch/x86_64/usr/X11R6/lib64/libGL.so.1.2
> ---
> 0x000000000000000e (SONAME)             Library soname: [libGL.so.1]
> ---
> 

It has not been fixed.  I'm still encountering the issue on AMD64.
Comment 40 Bernd Steinhauser 2008-01-01 18:33:46 UTC
(In reply to comment #39)
> It has not been fixed.  I'm still encountering the issue on AMD64.
> 

It has been fixed. Did you run revdep-rebuild?
I had to recompile a few packages (like mplayer).
Comment 41 Jory A. Pratt gentoo-dev 2008-01-04 20:47:12 UTC
(In reply to comment #40)
> (In reply to comment #39)
> > It has not been fixed.  I'm still encountering the issue on AMD64.
> > 
> 
> It has been fixed. Did you run revdep-rebuild?
> I had to recompile a few packages (like mplayer).
> 

Please close the bug as fixed. 

Thank You.
Comment 42 Bernd Steinhauser 2008-01-04 21:10:27 UTC
Fixed in ati-drivers-8.443.1.
Comment 43 Petrik Galvosas 2008-03-06 10:59:54 UTC
(In reply to comment #19)
> fair enough - I seem to have missed env-update before running eselect again..
> 8.40.4 indeed works..
> 
Can someone just help me out? I just downgraded to 8.40.4. Still with env-update and eselect subsequently (see below) I have the error message:

galvosas@pgal ~ $ glxinfo  
glxinfo: error while loading shared libraries: libGL.so.1.2: cannot open shared object file: No such file or directory

What do I miss here?

As root I did:

pgal bin # env-update
>>> Regenerating /etc/ld.so.cache...
pgal bin # eselect opengl set 2
Switching to xorg-x11 OpenGL interface... done
pgal bin # eselect opengl set 1
Switching to ati OpenGL interface... done