[Pkg-opencl-devel] Bug#763638: lintian: OpenCL ICD Loader used to built official Debian packages should be the free one
Vincent Danjean
vdanjean at debian.org
Wed Oct 1 14:37:54 UTC 2014
Package: lintian
Version: 2.5.27
Severity: wishlist
Hi,
In Debian, we have several OpenCL ICD Loader implementation. An ICD
Loader is used to load the OpenCL implementation (provided as a plugin), it
does not implement OpenCL itself.
In theory, all OpenCL ICD Loaders can be switched. They should be equivalent
(API defined by the Khonos OpenCL consorsium).
However, in pratice, this is not the case. There are several reasons, such
as:
- OpenCL version support is not the same
- some ICD Loaders provide versionned symbols, other not
- ...
About the version, ICD Loaders are backward compatible, ie a new loader is
able to run an old program with an old ICD (and even with a new ICD if the ICD
has been wrotten with backward compatibility in mind).
About the versionned symbols, as only default symbols are used for now, ICD
Loaders can still be switched at runtime without any problem for the users.
However, problems can occur when a library is linked with a ICD Loader
providing versionned symbols and, then, a program is linked to the library with an ICD Loader *not* providing versionned symbols, then a link-time error occurs during the compilation. See #743740.
Currently, Debian provides one free ICD Loader in main (ocl-icd-libopencl1)
and two in non-free (amd-libopencl1 and nvidia-libopencl1). It possible that
the intel one will be packaged latter.
I would like that lintian emits a warning when a official build is using an
ICD Loader not supporting versionned symbols. Unless very specific needs (that
can be adressed with a lintian override), there is no reason not to use the
free implementation that provides versionned symbols. Even if a non-free
OpenCL implementation is required (the nvidia one for example), then this
OpenCL implementation can be used with the free ICD Loader (that is
nvidia-opencl-icd can be installed with ocl-icd-libopencl1).
With this warning, packagers of OpenCL applications would be informed of the
issue and the group of people managing OpenCL in Debian can search for such
issues by looking at archive-wide lintian results.
That said, I'm not sure how to detect that a package has been compiled with
versionned symbols for the libOpenCL.so.1 library.
Regards,
Vincent
-- System Information:
Debian Release: jessie/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
armel
mipsel
Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages lintian depends on:
ii binutils 2.24.51.20140918-1
ii bzip2 1.0.6-7
ii diffstat 1.58-1
ii file 1:5.19-2
ii gettext 0.19.2-2
ii hardening-includes 2.5+nmu1
ii intltool-debian 0.35.0+20060710.1
ii libapt-pkg-perl 0.1.29+b2
ii libarchive-zip-perl 1.38-1
ii libclass-accessor-perl 0.34-1
ii libclone-perl 0.37-1+b1
ii libdpkg-perl 1.17.13
ii libemail-valid-perl 1.195-1
ii libfile-basedir-perl 0.03-1
ii libipc-run-perl 0.92-1
ii liblist-moreutils-perl 0.33-2+b1
ii libparse-debianchangelog-perl 1.2.0-1.1
ii libtext-levenshtein-perl 0.09-1
ii libtimedate-perl 2.3000-2
ii liburi-perl 1.64-1
ii man-db 2.6.7.1-1
ii patchutils 0.3.3-1
ii perl [libdigest-sha-perl] 5.20.0-6
ii t1utils 1.37-2.1
Versions of packages lintian recommends:
ii libautodie-perl 2.25-1
ii libperlio-gzip-perl 0.18-3+b1
ii perl 5.20.0-6
ii perl-modules [libautodie-perl] 5.20.0-6
Versions of packages lintian suggests:
ii binutils-multiarch 2.24.51.20140918-1
ii dpkg-dev 1.17.13
ii libhtml-parser-perl 3.71-1+b2
ii libtext-template-perl 1.46-1
ii libyaml-perl 1.11-1
ii xz-utils 5.1.1alpha+20120614-2
-- no debconf information
More information about the Pkg-opencl-devel
mailing list