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

[Norbert Lange]

Hi,

Looking at gcc-6, this is what the depency looks like there:
g++-multilib [amd64 i386 kfreebsd-amd64 mips mips64 mips64el mipsel
mipsn32 mipsn32el powerpc ppc64 s390 s390x sparc sparc64 x32] <!cross>

I also found out how to use the libclang_rt.asan-*.so binaries, they
are used via the option "-shared-libasan -fsanitize=address".
The problem is, that the compiled programs won`t find this library
(unless I adjust the LD library path to countain the private libraries
of this package).
There are some more "cons" with using it:
https://github.com/google/sanitizers/wiki/AddressSanitizerAsDso
I really think it would be a good idea to exclude those libraries from
dh_shlibdeps (like in pathv2) (but keep them in the package), If
someone wants to use them, he will have to care that those get loaded
correctly.
Even better would be a separate package (only for the shared libs)

I did not find the time to write down a scheme for the packages. I
will outline it here:

clang-compilerrt-common (all): contains the headers, empty directories symlinks.

clang-compilerrt-dev (any): contains binary, arch specific tools.
   depends on clang-compilerrt-common, clang-compilerrt-dev-<arch>,
libclang-compilerrt-<arch>

clang-compilerrt-dev-[linux_x86_64 | kfreebsd_x86_64 | linux_i386 |
linux_aarch64 | linux_armhf | ...] (all): contain the static libs (*.a
*.a.syms).
   every host-build generates only the fitting native files.

libclang-compilerrt-[linux_x86_64 | kfreebsd_x86_64 | linux_i386 |
linux_aarch64 | linux_armhf | ...] (all): contains the shared libs
   every host-build generates only the fitting native files.
   dh_shlibdeps is overridden to either remove all dependecies, or use
the correct multiarch suffix.

That means you can easisly install the rt libraries for another system
and crosscompile.
if you run on amd64 and install clang-compilerrt-dev-linux_i386 you
will be able to
crosscompile for i386.
Further, the current amd64 build (3.8-14) has the libraries for i386,
splitting up the libraries the above way would allow to build them on
their native environment just once, and also just easily add other
archs which cant be cross-compiled as easily (x32, non-linux, etc...)

The important thing here is that, you can compile for other
architectures anyway, but if you want to link a simple programm (for
linux) on another arch you will need to install the fitting
g++-multilib or a fitting linker anyway. Installing
clang-compilerrt-dev-<arch> and/or libclang-compilerrt-<arch> is an
additional step, but you can assume that the user already can link for
this <arch> - It it either allready covered if he can compile with g++
or he already installed a fitting toolchain and libraries.

Because of this, and the reason that you cant use those shared
libraries *alone*, I think removing the depencies would be best.


For easy installation (also dealing with the 32bit dependencies) of
x64/x86 clang maybe a new clang-multilib package would be the best
way, pulling in even those dependencies:

clang-multiarch (amd64):
  depends on: clang, g++-multiarch, clang-compilerrt-dev-linux_x86_64,
clang-compilerrt-dev-linux_i386,
libclang-compilerrt-dev-linux_x86x86_64,
libclang-compilerrt-linux_i386

Kind Regards,
Norbert

2016-11-06 16:29 GMT+01:00 Sylvestre Ledru <sylvestre at mozilla.com>:
> I did it and I am rebuilding
>
>
> Le 6 nov. 2016 3:40 PM, "Sylvestre Ledru" <sylvestre at mozilla.com> a écrit :
>>
>> 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
>>>>
>>>
>>
>