[Pkg-opencl-devel] Bug#823528: llvmopencl.so.5 should be packaged in it's own binary package

[Vincent Danjean]

Le 09/05/2016 11:39, Andreas Beckmann a écrit :
> On 2016-05-08 18:19, Vincent Danjean wrote:
>> Le 08/05/2016 17:38, Matthias Klose a écrit :
>>> thanks for clarifying.  However I also saw dropped symbols in the
>>> libpocl.so.1 library, so it looks like the library packages needs
>>> to be renamed for 0.13.
> 
>>   I just saw an upload of pocl 0.13 has been done by someone else.
> That was just 0.11-3 to NEW ...
> 
>> I will look at these missing symbols to check if a rename is required
>> or if they are private ones.
> 
> OK, let's see what symbols we lost in 0.11, excluding anything from
> namespaces llvm and clang:
> 
> $ git diff debian/0.10-12..debian/0.11-3 -- debian/*.symbols | grep +#MISSING | grep -vE "(optional=templinst|_Z(TI|TV|TS|nwI)?NK?(4llvm|5clang))|non-virtual thunk to clang::"
> +#MISSING: 0.11# Header at Base 0.10
> +#MISSING: 0.11# KernelName at Base 0.10
> +#MISSING: 0.11# _Z21createWIVectorizePassv at Base 0.10
> +#MISSING: 0.11# _ZN4pocl14ParallelRegion12InjectPrintFEPN4llvm11InstructionESsRSt6vectorIPNS1_5ValueESaIS6_EE at Base 0.10
> +#MISSING: 0.11# _ZN4pocl7dumpCFGERN4llvm8FunctionESsPNS0_11SmallVectorIPNS_14ParallelRegionELj8EEEPSt3setIPNS0_10BasicBlockESt4lessISA_ESaISA_EE at Base 0.10
> +#MISSING: 0.11# (arch=!armel)_ZTVSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE2EE at Base 0.10
> +#MISSING: 0.11# pocl_command_enqueue at Base 0.10
> +#MISSING: 0.11# pocl_create_command at Base 0.10
> +#MISSING: 0.11# pocl_create_event at Base 0.10
> +#MISSING: 0.11# Header at Base 0.10
> +#MISSING: 0.11# KernelName at Base 0.10
> +#MISSING: 0.11# _Z21createWIVectorizePassv at Base 0.10
> +#MISSING: 0.11# _ZN4pocl14ParallelRegion12InjectPrintFEPN4llvm11InstructionESsRSt6vectorIPNS1_5ValueESaIS6_EE at Base 0.10
> +#MISSING: 0.11# _ZN4pocl7dumpCFGERN4llvm8FunctionESsPNS0_11SmallVectorIPNS_14ParallelRegionELj8EEEPSt3setIPNS0_10BasicBlockESt4lessISA_ESaISA_EE at Base 0.10
> 
> This seems to include some public symbols :-(

semi-public (ie public by the way the library is built but not by its
intended use case)

None of them are used by libOpenCL.so
None of them are defined in the OpenCL norm.

My question (I do not have the answer) is : is there any useful case
in Debian to link directly with this library ?
And, if the previous answer is yes, is there any symbols other that
the one in libOpenCL (ie most "cl..." function) that are indended to be
used by external application/libraries

> And for 0.12 a few more will go away, even if we ignore these just added in 0.11:
> 
> +#MISSING: 0.12# _ZN4pocl9LocalSizeE at Base 0.10
> +#MISSING: 0.12# pocl_SHA1_Final at Base 0.11
> +#MISSING: 0.12# pocl_SHA1_Init at Base 0.11
> +#MISSING: 0.12# pocl_SHA1_Update at Base 0.11
> +#MISSING: 0.12# pocl_basic_malloc at Base 0.11
> +#MISSING: 0.12# pocl_cpuinfo_append_cpu_name at Base 0.10
> +#MISSING: 0.12# pocl_debug_messages at Base 0.11
> +#MISSING: 0.12# pocl_debug_timespec at Base 0.11
> +#MISSING: 0.12# pocl_sysfs_detect_compute_unit_count at Base 0.11
> +#MISSING: 0.12# supported_image_formats at Base 0.10
> +#MISSING: 0.12# _ZN4pocl9LocalSizeE at Base 0.10
> 
> checking 0.13 is on my todo list
> 
> Should we rename libpocl1 to libpocl1-$UPSTREAMVERSION to handle these?

Wont't be better to add a linker map (the one from ocl-icd for example,
but removing symbols version if not used in pocl) so that only intended
public symbols are kept into the library (the other will become
explicitly private) ?

  Regards,
    Vincent