Bug#841923: AW: AW: Bug#841923: libclang-common-3.9-dev: missing multilib binaries

[Sylvestre Ledru]

I guess limiting the declaration of this package in the build dep should 
be enough

S

Le 06/11/2016 à 13:34, Sylvestre Ledru a écrit :
> Looks lile g++-multilib is not available on many archs
>
> https://buildd.debian.org/status/package.php?p=llvm-toolchain-3.8
>
> could you have a look?
>
> Thanks
>
> S
>
>
>
> Le 01/11/2016 à 21:24, Sylvestre Ledru a écrit :
>> Le 01/11/2016 à 19:56, Norbert Lange a écrit :
>>> Hi,
>>>
>>> we absolutely should do this. I believe we have some communication
>>> problems, because I brought this up multiple times.
>> Probably me, sorry :/
>>> I am not sure how to solve it, I can think of multiple ways. But it
>>> would help if you just apply this path as it is, and let it build for
>>> the ~10 architectures. Can you do this somehow, maybe just keep it in
>>> experimental?
>> I don't think this is reasonable leave it as it.
>> I would like to see this changes in 3.8 and this will impact too much 
>> Debian.
>>
>> So, we should find a proper solution.
>> However, I "only" saw the i386 files, not armel or others.
>> What should be the result on arm archs?
>>
>>> First, it helps if we know we start with a working build (on all
>>> platforms) before modifying it, and which libraries would normally be
>>> built.
>>> Then I would like to be able to make a list of libraries for all
>>> architectures, since I believe this will differ alot.
>>
>> $ debdiff  /tmp/libclang-common-3.8-dev_3.8.1-12_amd64.deb 
>> libclang-common-3.8-dev_3.8.1-13_amd64.deb
>> [The following lists of changes regard files as different if they have
>> different names, permissions or owners.]
>>
>> Files in second .deb but not in first
>> -------------------------------------
>> -rw-r--r--  root/root 
>> /usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.asan-i386.a
>> -rw-r--r--  root/root 
>> /usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.asan-i386.so
>> -rw-r--r--  root/root 
>> /usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.asan-i686.a
>> -rw-r--r--  root/root 
>> /usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.asan-i686.so
>> -rw-r--r--  root/root 
>> /usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.asan-preinit-i386.a
>> -rw-r--r--  root/root 
>> /usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.asan-preinit-i686.a
>> -rw-r--r--  root/root 
>> /usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.asan_cxx-i386.a
>> -rw-r--r--  root/root 
>> /usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.asan_cxx-i686.a
>> -rw-r--r--  root/root 
>> /usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.builtins-i386.a
>> -rw-r--r--  root/root 
>> /usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.builtins-i686.a
>> -rw-r--r--  root/root 
>> /usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.cfi-i386.a
>> -rw-r--r--  root/root 
>> /usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.cfi-i686.a
>> -rw-r--r--  root/root 
>> /usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.cfi_diag-i386.a
>> -rw-r--r--  root/root 
>> /usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.cfi_diag-i686.a
>> -rw-r--r--  root/root 
>> /usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.profile-i386.a
>> -rw-r--r--  root/root 
>> /usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.profile-i686.a
>> -rw-r--r--  root/root 
>> /usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.safestack-i386.a
>> -rw-r--r--  root/root 
>> /usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.safestack-i686.a
>> -rw-r--r--  root/root 
>> /usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.ubsan_standalone-i386.a
>> -rw-r--r--  root/root 
>> /usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.ubsan_standalone-i686.a
>> -rw-r--r--  root/root 
>> /usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.ubsan_standalone_cxx-i386.a
>> -rw-r--r--  root/root 
>> /usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/libclang_rt.ubsan_standalone_cxx-i686.a
>>
>> this could be the opportunity to move them into a (or several) 
>> dedicated packages.
>>
>> So, we could create:
>> libclang-sanitizer => with the libraries for the arch
>> and
>> libclang-sanitizer-multilib => with the libraries for the other 
>> supported archs (i386 for amd64, arm* for other I guess)
>>
>>  I don't think we can use some voodoo-multiarch magic here :/
>>
>>> Also (I brought this up before): I dont know if the shared sanitizer
>>> libraries are actually used anywhere. The static libraries dont make
>>> problems, so if we can drop the shared ones then this is one problem
>>> solved.
>> You are talking about libclang_rt.asan-i386.so and 
>> libclang_rt.asan-i686.so, right?
>>
>> S
>>
>