Using alternatives instead of a conflict for libopencl1?

[Vincent Danjean]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Le 22/04/2013 14:49, Simon Richter a écrit :
> On 22.04.2013 14:04, Vincent Danjean wrote:

> Basically, I can see the following configurations:
> 
> 1. Beignet as the sole implementation
> 
> This makes sense on embedded systems or if the admin knows that no
> other GPUs are present. In this case, I think it makes sense to
> install Beignet as libOpenCL.so.1.

Even if no other GPU are present, amd (or the old intel) implementation
works on CPU. And pocl should work, too.

> 2. Multiple different ICDs
> 
> This makes sense on typical user setups, where we want to install
> support for as many different configurations as possible. Here, the
> OCL-ICD loader takes over as libOpenCL.so.1, and Beignet is registered
> through /etc/OpenCL/vendors.
> 
> We currently have the option of installing either AMD's or nVidias
> implementation standalone as well, by using "amd-libopencl1" or
> "nvidia-libopencl1", respectively, in which case the "Conflicts:
> libopencl1" inhibits installation of ocl-icd-libopencl1.

amd and nvidia do not provide standalone implementation.

amd-libopencl1, nvidia-libopencl1 and ocl-icd-libopencl1 are
three ICD loader implementation that are able to load any ICD
(with the restriction that the nvidia one only support
OpenCL 1.1 and not 1.2 yet)

> I'd like to provide the same option to the Beignet users, but I think
> the best idea to do so would be to provide libOpenCL-Intel.so.1 and a
> symlink managed by the alternatives system to make the library
> accessible as libOpenCL.so.1 if no other option is installed.

I'm not convinced: at compile time, an OpenCL application "registers"
the soname of the used libraries. This soname will be search on the
filesystem at runtime by the dynamic linker.
  You can fake the linker by providing symlinks between files that
does not have the correct soname[1]. For now, it works because the
linker does not check the soname of the loaded library. But it seems
very fragile to me.

  Instead of the symlink managed by the alternatives system, use
a symlink in a private directory. Users would just have to use
- -L at compile time and LD_LIBRARY_PATH (or nothing if rpath is
also used at compile time) at execution time.


  I'm very relunctant about providing alternatives for a shared
library. Even with the current scheme, there are problems:
symbols files should ensure that programs compiled and using
OpenCL 1.2 will get an OpenCL 1.2 ICD loader (I'm not talking
about the ICDs version that is another problem). However,
it does not work here, due to the fact that libopencl1 is
a virtual package...
  So, complexifying this mess with alternatives does not seem
a good thing to do.

  About your alternative solution, how to you handle:
- - development package(s) [for now, if I recall correctly,
  all -dev packages use the same opencl-headers package
  and the installed ICD loader]
- - build-dependencies (of OpenCL applications/bindings)
- - symbol files of this shared library
- - etc. ?

  Regards,
    Vincent

[1] I know it because we use this to run application compiled
with the Intel ICD loader (soname libOpenCL.so) with other
ICD loaders (soname libOpenCL.so.1).

> Simon
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIVAwUBUXVPE9T1zgD6DpudAQgHyQ//ft3ZVfdn4UNr41dTb+2vs+mNaKNEx4eK
VwyX6nynP/j3WID00tfnEzREbouwX+x6l48OE4i9djG2Dp9/PkHr2LVpvg+ixAJT
+U3vhuvrG6pz/9z7X/bMAv3uVLkCmBp76FfcXI13Q4QSd4LupWtzBnMMxE+1DmMU
EClnpaGyKpc2Kzl7iEfd1Zh5l3KV00rXL4kFa7NWys7OvD4/YwqrIffOGiIrCm95
SRRDvBDTsGMmdzrHrF2/No84wKBQHihS5UHeJZi8EBDMwkpU55jQU4Kmz0CNz8RE
OrrLo76QG5ZO3OC3CMO79JEobrhdGwvRSqtsgEA1o/8fyT8+00N+PyrcjrwclMcs
HxuAjRKPebt5hCbIjA7vu2Vj8OTREVw8oLmq6w0oHfCzBwhJk0dEfCsJAgPO1CX0
SsJWHsN6ug3vFoO2h7xRIm6rlB2X0+qq6cHYGge66Yh0qpqdQsfe1cemATCPh6i3
rQRTxqlXM2eIs7NHiLSZEI1otJ2Lha09SH+iYT4oNNcW2U6hYANSFnpcy9OvCfA/
gY59k2zvmsYC5mDFojQpE5xYq8t4vwDNEez4nq/BrkFkW5HXj99JaU5TpvqJ50iI
pwrImS7JZ4Sn7R3KwwuXugFIZriPMkxIXsSAG/4slst9Nglo0fp2rOsBgwkMwjZ8
odXpb/cJk3A=
=EQUC
-----END PGP SIGNATURE-----