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 this would be: - in wheezy, try to keep maximum binary compatibility (so link in library package) - in wheezy+1, forget about Intel binary compatibility if they do not change their SDK (ie move the .so in the -dev package) Regards, Vincent > Cheers, > Julien -- Vincent Danjean GPG key ID 0x9D025E87 [email protected] 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 [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
