Bug#679228: ocl-icd-libopencl1: unversioned .so in library runtime package
Le 30/06/2012 19:57, Julien Cristau a écrit : > On Wed, Jun 27, 2012 at 13:32:53 +0200, Vincent Danjean wrote: > >> severity 679228 normal >> thanks >> >> Hi, >> >> Le 27/06/2012 12:16, Ansgar Burchardt a écrit : >>> Package: ocl-icd-libopencl1 >>> Version: 1.1-1 >>> Severity: serious >>> >>> ocl-icd-libopencl1 ships the unversioned .so in the library runtime >>> package, however Policy 8.2 says >>> >>> >>> If your package contains files whose names do not change with each >>> change in the library shared object version, you must not put them in >>> the shared library package. Otherwise, several versions of the shared >>> library cannot be installed at the same time without filename clashes, >>> making upgrades and transitions unnecessarily difficult. >>> >> >> Our libopencl1 shared library has a proper SONAME (libopencl.so.1). >> Note that, as this is a free implementation of a library implemented >> by several vendors, we *need* to keep in sync with them if we want >> to keep binary compatibility. I plan to diffuse on d-d a document >> about the situation of OpenCL in Debian. I will try to think to cc >> this bug. For more info, please, first read this document: http://anonscm.debian.org/gitweb/?p=collab-maint/ocl-icd.git;a=blob;f=debian/README.Debian;hb=master But, if you want to comment it, please do it in d-d where I will post it just after this mail. > That would imply that binary compatibility exists in the first place. > Is there an ABI spec for libopencl.so? If yes it must include a > proper version. There is no ABI spec per se. There is a list of functions that must be implemented. This list of functions is the ones in the OpenCL headers maintains by the Khronos group (opencl-headers package in Debian). Now, each vendors (mainly Intel, AMD and NVidia) implemented this library differently: - the best: AMD: proper soname AND versionned symbols - middle: NVidia: proper soname but no versionned symbols - worst: intel: unversionned soname and no versionned symbols By following the AMD convention, ocl-icd uses the best practices and is able to run binaries compiled with any of the three non-free implementations (but for Intel, its means keeping the so symlink :-( ) >> In this case, the .so symlink is kept in the library package (instead >> of putting it in the dev package) because Intel version of the library >> use the "libopencl.so" soname instead of "libopencl.so.1". >> We plan to solve this issue with Intel in order to keep binary >> compatibility but this is not done yet. > > Sounds to me like we shouldn't ship this until that is fixed. We can decide that we do not want to provide Intel binary compatibility without users creating themselves manually the symlink. I wont argue strongly against that. I think that it is better to provides the compatibility while trying to make Intel change its way, but I can easily agree to remove Intel binary compatibility. But if you want to wait that this is fixed between Intel, NVidia and AMD, I think we can forget about OpenCL in Debian for the foreseeable future. >> Note that amd-libopencl1 and nvidia-libopencl1 packages do the >> same thing. >> > Just because others are doing it wrong, ... I talked recently with Andreas Beckmann (one maintainer of AMD and NVidia OpenCL packages). He tells me (and agrees to forward its mail): > Ideally a free release of libopencl1 by Khronos (with proper soname and > symbol versions) could cleanup the inter-vendor libopencl1 mess ... > > And I'd like to see the libopencl1.so symlink to be moved out of the > libopencl1 (virtual) package before people start to > dlopen(libopensl.so), so let's try to fix Intel The free version of libopencl1 by Khronos would indeed have been the better think. However, this does not occur. Khronos has an implementation in its SVN restricted to its members... And you can find lots of requests to free libopencl1 in Khronos forums. So... Perhaps, the existence of ocl-icd will change Kronos behaviour... ocl-icd has been written in response to this behavior. Its goal is to provide a free implementation of this simple library that will be used instead of the non-free ones. The "push" we are doing to have ocl-icd in wheezy is for this reason. We hope to become the "reference" when compiling and executing OpenCL programs. We try to convince by using good practices (correct soname, versionned symbols, pkg-config files, ...) ocl-icd has very little interest if non-free packages are used: the one from AMD provides exactly the same think, but the last version of ocl-icd (not in wheezy, only two days young) that allows ICD developers to test their ICD without being root (useful for a "make check"). About the mess due to Intel, I wrote a message on their OpenCL forum two days ago. No answer for now. I will try to see if some personal contact can allow me to talk to the good people at Intel. But, in any case, I do not think their SDK will be fixed soon. My idea about
Bug#679228: ocl-icd-libopencl1: unversioned .so in library runtime package
On Wed, Jun 27, 2012 at 13:32:53 +0200, Vincent Danjean wrote: > severity 679228 normal > thanks > > Hi, > > Le 27/06/2012 12:16, Ansgar Burchardt a écrit : > > Package: ocl-icd-libopencl1 > > Version: 1.1-1 > > Severity: serious > > > > ocl-icd-libopencl1 ships the unversioned .so in the library runtime > > package, however Policy 8.2 says > > > > > > If your package contains files whose names do not change with each > > change in the library shared object version, you must not put them in > > the shared library package. Otherwise, several versions of the shared > > library cannot be installed at the same time without filename clashes, > > making upgrades and transitions unnecessarily difficult. > > > > Our libopencl1 shared library has a proper SONAME (libopencl.so.1). > Note that, as this is a free implementation of a library implemented > by several vendors, we *need* to keep in sync with them if we want > to keep binary compatibility. I plan to diffuse on d-d a document > about the situation of OpenCL in Debian. I will try to think to cc > this bug. That would imply that binary compatibility exists in the first place. Is there an ABI spec for libopencl.so? If yes it must include a proper version. > In this case, the .so symlink is kept in the library package (instead > of putting it in the dev package) because Intel version of the library > use the "libopencl.so" soname instead of "libopencl.so.1". > We plan to solve this issue with Intel in order to keep binary > compatibility but this is not done yet. Sounds to me like we shouldn't ship this until that is fixed. > Note that amd-libopencl1 and nvidia-libopencl1 packages do the > same thing. > Just because others are doing it wrong, ... Cheers, Julien signature.asc Description: Digital signature
Bug#679228: ocl-icd-libopencl1: unversioned .so in library runtime package
severity 679228 normal thanks Hi, Le 27/06/2012 12:16, Ansgar Burchardt a écrit : > Package: ocl-icd-libopencl1 > Version: 1.1-1 > Severity: serious > > ocl-icd-libopencl1 ships the unversioned .so in the library runtime > package, however Policy 8.2 says > > > If your package contains files whose names do not change with each > change in the library shared object version, you must not put them in > the shared library package. Otherwise, several versions of the shared > library cannot be installed at the same time without filename clashes, > making upgrades and transitions unnecessarily difficult. > Our libopencl1 shared library has a proper SONAME (libopencl.so.1). Note that, as this is a free implementation of a library implemented by several vendors, we *need* to keep in sync with them if we want to keep binary compatibility. I plan to diffuse on d-d a document about the situation of OpenCL in Debian. I will try to think to cc this bug. In this case, the .so symlink is kept in the library package (instead of putting it in the dev package) because Intel version of the library use the "libopencl.so" soname instead of "libopencl.so.1". We plan to solve this issue with Intel in order to keep binary compatibility but this is not done yet. Note that amd-libopencl1 and nvidia-libopencl1 packages do the same thing. > It looks like this was fixed, but then reverted again as the changelog > for 1.3-2 says > > >* in particular, move the .so from -dev to -libopencl1 in order > to support programs created with the Intel SDK > Yes, we want to keep the binary compatibility with respect to OpenCL compiled with the Intel SDK. When and if a new libOpenCL library appears, then Intel would be required to also use soname (even if we do not succeed into changing Intel behavior before). At this time, it will be easy to release a version of this package without the so link (and put it in the -dev package). Note that, at that time, the conflict/replace will be between the current package and the new -dev package. Current package (or update of current package) and new shared lib package will be co-installable. And update of current package, new shared lib package and new -dev package will be co-installable. => for all these reasons, I downgraded the severity to "normal" So, until Intel shared library in it's SDK is fixed *or* that a new version (soname) of libOpenCL is release/requested by the Khronos group (the one that normalize OpenCL), I will let the .so symlink in this library package. Regards, Vincent > Regards, > Ansgar -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679228: ocl-icd-libopencl1: unversioned .so in library runtime package
Package: ocl-icd-libopencl1 Version: 1.1-1 Severity: serious ocl-icd-libopencl1 ships the unversioned .so in the library runtime package, however Policy 8.2 says If your package contains files whose names do not change with each change in the library shared object version, you must not put them in the shared library package. Otherwise, several versions of the shared library cannot be installed at the same time without filename clashes, making upgrades and transitions unnecessarily difficult. It looks like this was fixed, but then reverted again as the changelog for 1.3-2 says * in particular, move the .so from -dev to -libopencl1 in order to support programs created with the Intel SDK Regards, Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
