[arch-dev-public] [Warning] Don't build openGL apps against fglrx-utils' libGL.so
 

> -----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 in fglrx-utils libGL.so?


_______________________________________________
arch-dev-public mailing list
arch-dev-public@archlinux.org
http://archlinux.org/mailman/listinfo/arch-dev-public

[arch-dev-public] [Warning] Don't build openGL apps against fglrx-utils' libGL.so
 

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


_______________________________________________
arch-dev-public mailing list
arch-dev-public@archlinux.org
http://archlinux.org/mailman/listinfo/arch-dev-public