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



Reply via email to