-----Oorspronkelijk bericht----- Van: arch-dev-public-bounces@archlinux.org [mailto:arch-dev-public- bounces@archlinux.org] Namens Travis Willard Verzonden: woensdag 21 november 2007 13:28 Aan: arch-dev-public@archlinux.org Onderwerp: Re: [arch-dev-public] [Warning] Don't build openGL apps against fglrx-utils' libGL.so
On Wed, 21 Nov 2007 13:25:23 +0100 "Jan de Groot" <jan@jgc.homeip.net> wrote:
-----Oorspronkelijk bericht----- Van: arch-dev-public-bounces@archlinux.org [mailto:arch-dev-public- bounces@archlinux.org] Namens Thomas Bächler Verzonden: woensdag 21 november 2007 11:39 Aan: Public mailing list for ArchLinux development Onderwerp: [arch-dev-public] [Warning] Don't build openGL apps against fglrx-utils' libGL.so
tpowa and I found this when we were trying to fix a wine bug: When libgl or nvidia-utils are installed, applications are linked against "libGL.so.1":
$ readelf -d /usr/lib/libGL.so|grep SONAME 0x000000000000000e (SONAME) Library soname: [libGL.so.1]
However, if you try this command with fglrx-utils, it will return 'libGL.so.1.2' as SONAME. The binaries this produces are compatible with libgl and fglrx-utils, but not with nvidia-utils, as the file 'libGL.so.1.2' does not exist there (while libGL.so.1 does).
Thus, to ensure compatibility with nvidia users, only build OpenGL applications in environments where libgl or nvidia-utils is installed.
Can't we do the magic binary sed trick to get it replaced with libGL.so.1\0\0 in fglrx-utils libGL.so?
Or just add the libGL.so.1.2 symlink in the nvidia package?
So when mesa decides to supply libGL.so.1.3 because they support OpenGL 3.0 we have to add a backwards compatibility symlink on .so.1.2 also? On linux the normal soname versioning uses the first number of the extension. For libGL this is libGL.so.1. Some exceptions do exist, like OpenSSL which links to .so.0.9.7 and .so.0.9.8, but that's their choice. As mesa is the standard implementation of libGL on linux, we should follow mesa behaviour and not mess with things redesigned by ATI. BTW: Didn't we all build in rather clean chroots where we don't have these issues?