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

Am Mittwoch, 21. November 2007 schrieb Thomas Bächler:

Jan de Groot schrieb:

...

...

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?

I guess we could, but are we allowed to? Anyway, in a clean build chroot with libgl installed, this is not a problem.

I think the problem was that my chroot dropped in fglrx-utils because pacman chooses to install the first packages that matches with libgl, which is unfortunately fglrx-utils :( greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org

On Wed, 2007-11-21 at 13:48 +0100, Thomas Bächler wrote:

Jan de Groot schrieb:

...

...

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?

I guess we could, but are we allowed to? Anyway, in a clean build chroot with libgl installed, this is not a problem.

Their license states that we're not allowed to change any binary in fglrx. Problem for them is that they're violating the MIT license though. libGL.so contains enough error messages, debug variables and warnings which would prove it's a fork of mesa's libGL (even warnings about fbconfig are still present, while fglrx doesn't have anything to do with fbconfig). Mesa itself is licensed with the MIT license: http://www.mesa3d.org/license.html "Copyright (C) 1999-2007 Brian Paul All Rights Reserved. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software." Take note of the last paragraph I quoted, though AMD has relicensed their driver and mesa code to their own license (sublicensing is allowed), there's not a single reference to the quoted copyright in their license file that we have in our package. Their "source" package doesn't have any reference to the MIT license either Another thing is that I don't see the modification of some binary library to fix linking as a modification to their driver. We don't modify their driver, we modify the way it integrates into a system that uses shared libraries. This binary happens to be libGL.so, which isn't even covered by their license because it is invalid.