Hi Vincent,
On 05.04.2014 02:35, Vincent Danjean wrote:
On 04/04/2014 21:21, Andreas Cadhalpun wrote:
Control: severity -1 serious
Justification: breaks other packages
You are kidding? The only effect of this bug is that, if you enable
the non-free Debian repo, then a non-free package can sometimes be
installed by default where another free one (from main) would work.
If installing another ICD Loader really does not work, then this
is another bug that has nothing to do with depends. ICD Loaders are
meant to be exchangeable.
You're right: the more serious problem is that nvidia-libopencl1 doesn't
work with a program build with ocl-icd-opencl-dev.
I just tested amd-libopencl1 and it works.
I was hopping that the first alternative would be a good enough
hint for package managers. It seems not. I will apply your patch.
Thanks.
This creates the following dependencies (from python-pyopencl):
Depends: libopencl-1.1-1, libopencl-1.2-1, ocl-icd-libopencl1 (>= 1.0) |
libopencl1, opencl-icd
Now if you try to install this package, apt satisfies the libopencl-1.1-1
dependency randomly, for me by installing nvidia-libopencl1. (A similar problem
is the opencl-icd dependency, but that is added by pyopencl itself.)
nvidia-libopencl1 does not provide libopencl-1.2-1 and conflict
with libopencl1. So I find this fact very suspicious. Do you have
any evidence of it? What are the precise versions of all involved
packages (in particular nvidia-libopencl1).
But I agree that amd-libopencl1 can be installed if the package
manager try to satisfy "libopencl-1.2-1" before
"ocl-icd-libopencl1 (>= 1.0) | libopencl1" (that said, it needs you
to have enable the non-free Debian repo *and* it should indeed work)
Sorry for mixing things up here. If I install python-pyopencl apt by
installs amd-libopencl1. nvidia-libopencl1 was installed in my build
process to satisfy the dependencies of libavutil152.
Note that opencl-icd is a different problem. It tells that your
program needs a ICD (ie OpenCL implementation). However, to my
knowledge (and same for other involved maintainers), there is no
way to express in dpkg/apt a depends on a ICD that will work for
your current hardware. So, this force you to install an ICD but
you will need to select a correct one for your machine.
This is indeed a problem as apt doesn't ask, but just installs a random
one. So I guess one has to install the correct ICD first.
Attached is a patch that fixes this problem in ocl-icd.
Additionally, I'm not sure if you are aware of [1]:
"Packages MUST NOT use virtual package names (except privately, amongst
a cooperating group of packages) unless they have been agreed upon and
appear in this list."
I think it would be a good idea to add the libopencl* virtual packages
to that list, because they can be added automatically via the symbols
file, which is not exactly using 'privately, amongst
a cooperating group of packages'.
However, that the case. They are used privately amongst OpenCL related
packages. There have been discussions explaining the reasons.
No maintainer of external packages should add them manually.
No package unrelated with OpenCL should use them at all.
If you think so.
But before you attempt this, I think you should coordinate with the
other packages currently providing these libraries and standardize
the symbol names.
This is not possible unless you are able to modify the binaries
provided by AMD, NVidia (and even Intel that, in its libopencl1.so
library doe no even use the correct SONAME...)
In any case, this is out the scope of the power of Debian Developer
(AMD and NVidia are in non-free, not in main, Intel ones is not
even in non-free due to an error in there licencing file. They promise
me to correct this on a forum but I did not see any fact until now...)
But the Debian Developer can ensure that nvidia-libopencl1 does not
provide libopencl1 as long as it doesn't work well together with the rest.
ocl-icd-libopencl1 uses @OPENCL_*, while e.g. nvidia-libopencl1 uses
@BASE, so if a program is compiled with ocl-icd-opencl-dev and used
with nvidia-libopencl1 (which apt installs by default with the current
broken symbols file), it will produce errors like:
undefined reference to `clReleaseMemObject@OPENCL_1.0'
Are you sure? When I test it a few months (years) ago, there was
only a warning. Look at line 310 and following at
http://anonscm.debian.org/gitweb/?p=collab-maint/ocl-icd.git;a=blob;f=debian/README.Debian;hb=HEAD
Perhaps the linker behavior changed since this time.
Yes, I'm sure that I see this error.
When FFmpeg is compiled with ocl-icd-opencl-dev and then e.g. amarok is
compiled while nvidia-libopencl1 is installed instead of
ocl-icd-libopencl1, it results in:
[ 71%] Building CXX object
src/core-impl/collections/ipodcollection/CMakeFiles/amarok_collection-ipodcollection.dir/IpodCollectionFactory.o
cd src/core-impl/collections/ipodcollection && /usr/bin/c++
-DKDE4_CMAKE_TOPLEVEL_DIR_LENGTH=11 -DKDE_DEPRECATED_WARNINGS
-DMAKE_AMAROK_COLLECTION_IPODCOLLECTION_LIB -DQT_CORE_LIB -DQT_DBUS_LIB
-DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_CAST_TO_ASCII -DQT_NO_STL
-DQT_STRICT_ITERATORS -DQT_SVG_LIB -DQT_USE_FAST_CONCATENATION
-DQT_USE_FAST_OPERATOR_PLUS -DQT_XML_LIB -D_BSD_SOURCE -D_REENTRANT
-D_XOPEN_SOURCE=500 -g -O2 -fstack-protector --param=ssp-buffer-size=4
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fmessage-length=0
-Wl,--as-needed -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align
-Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security
-fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common
-Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden
-Werror=return-type -fvisibility-inlines-hidden -DNDEBUG -DQT_NO_DEBUG
-fPIC -I. -I../../../../../src/core-impl/collections/ipodcollection
-I../../../../../shared -I../../../../shared -I../../../../../src
-I../../.. -I/usr/include/KDE -I/usr/include/qt4/phonon
-I/usr/include/qt4/QtXmlPatterns -I/usr/include/qt4/QtXml
-I/usr/include/qt4/QtWebKit -I/usr/include/qt4/QtUiTools
-I/usr/include/qt4/QtTest -I/usr/include/qt4/QtSvg
-I/usr/include/qt4/QtSql -I/usr/include/qt4/QtScriptTools
-I/usr/include/qt4/QtScript -I/usr/include/qt4/QtOpenGL
-I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtHelp
-I/usr/include/qt4/QtDesigner -I/usr/include/qt4/QtDeclarative
-I/usr/include/qt4/QtDBus -I/usr/include/qt4/Qt3Support
-I/usr/include/qt4/QtGui -I/usr/include/qt4/QtCore -I/usr/include/qt4/Qt
-I/usr/share/qt4/mkspecs/default -I/usr/include/qt4
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0/gobject
-I/usr/include/gpod-1.0 -I/usr/include/libxml2 -I/usr/include/p11-kit-1
-D_GNU_SOURCE -D_LARGEFILE64_SOURCE -o
CMakeFiles/amarok_collection-ipodcollection.dir/IpodCollectionFactory.o
-c
../../../../../src/core-impl/collections/ipodcollection/IpodCollectionFactory.cpp
//usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to
`clReleaseMemObject@OPENCL_1.0'
//usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to
`clReleaseCommandQueue@OPENCL_1.0'
//usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to
`clSetKernelArg@OPENCL_1.0'
//usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to
`clGetPlatformInfo@OPENCL_1.0'
//usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to
`clEnqueueUnmapMemObject@OPENCL_1.0'
//usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to
`clCreateProgramWithSource@OPENCL_1.0'
//usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to
`clCreateContextFromType@OPENCL_1.0'
//usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to
`clCreateCommandQueue@OPENCL_1.0'
//usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to
`clEnqueueMapBuffer@OPENCL_1.0'
//usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to
`clCreateBuffer@OPENCL_1.0'
//usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to
`clBuildProgram@OPENCL_1.0'
//usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to
`clGetDeviceIDs@OPENCL_1.0'
//usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to
`clGetDeviceInfo@OPENCL_1.0'
//usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to
`clReleaseContext@OPENCL_1.0'
//usr/lib/x86_64-linux-gnu/libavutil.so.152: undefined reference to
`clGetPlatformIDs@OPENCL_1.0'
collect2: error: ld returned 1 exit status
make[3]: *** [src/amarok] Error 1
This happens in my use case:
I packaged FFmpeg for Debian [2]. Adding opencl support breaks the compilation
of many possible reverse dependencies due to this problem.
I do not really understand what you mean. If the linker did not change
its behavior, then the chosen solution (versioned symbols) allowed
all possible runtimes (sometimes at the expense of a warning).
Did anyone ever test to compile a third program with a different
libopencl1 provider installed? I can imagine that there might be a
difference between run-time and compile-time.
Note that, if the linker changed its behavior, as AMD and NVidia
does not use the same thing (AMD also use versioned symbols), then
we wont be able to keep binary compatibility with all these ICD loaders.
In this case, ocl-icd will still keep its versioned symbols but I
will need to talk with NVidia maintainer so that we stop using the
same virtual packages (that were here to denote a binary compatibility).
It would be better if NVidia could be convinced to use the same symbols
as ocl-icd and AMD, but if they don't, they shouldn't use the same
virtual packages.
Best regards,
Andreas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
