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] 

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-,
libclang-compilerrt-

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- and/or libclang-compilerrt- is an
additional step, but you can assume that the user already can link for
this  - 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 :
> I did it and I am rebuilding
>
>
> Le 6 nov. 2016 3:40 PM, "Sylvestre Ledru"  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
 

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

[Sylvestre Ledru]

I did it and I am rebuilding

Le 6 nov. 2016 3:40 PM, "Sylvestre Ledru"  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
>>>
>>>
>>
>

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

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

[Sylvestre Ledru]

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

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

[Norbert Lange]

> 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.
I am not saying to leave it, but to do the bigger change in smaller
steps. You seem to miss, that not only the amd64 package will change,
but any host architecture will aswell. I cant test anything but amd64,
and we might mess thing up for the rest of them, possibly without
noticing

** Example, of what I believe will happen (only for arm64. mips64,
ppc64, sparc64? likewise):
* Now:

arm64 package contains:
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-aarch64.a
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-aarch64.a.syms

armhf package contains:
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armhf.a
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armhf.a.syms

armel package contains (would contain on a jessie backport, just my guess):
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a.syms

* After adding the g++-multilib dependency:
arm64 package contains:
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-aarch64.a
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-aarch64.a.syms
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armhf.a
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armhf.a.syms
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a.syms

armhf package contains:
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armhf.a
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armhf.a.syms
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a.syms

armel package contains (would contain on a jessie backport, just my guess):
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a
/usr/lib/llvm-3.9/lib/clang/3.9.0/lib/linux/libclang_rt.ubsan_standalone-armel.a.syms

** this will affect packaging, and all this is just a GUESS now. We
would know ALOT better what we need to do if we let the build server
run once.
If we start moving around files, we might miss some, or break the build.

> $ debdiff  /tmp/libclang-common-3.8-dev_3.8.1-12_amd64.deb
> libclang-common-3.8-dev_3.8.1-13_amd64.deb
As said, amd64 is just one architecture, I am talking about all of them.

> You are talking about libclang_rt.asan-i386.so and libclang_rt.asan-i686.so,
> right?
These are the ones that add the new lib32* dependencies, and the ones
that are troublesome for dh_shlibdeps

What would you say, if for now we just remove the dependencies to the
lib32* libraries?
You would have to adjust the filter depending on the architecture
(thats exactly what I dont know to figure out easily for other archs).
eg.:
dh_shlibdeps 
-l/buildllvm/llvm-toolchain-3.9-3.9/debian/tmp//usr/lib/llvm-3.9/lib/
-Xlibclang_rt.asan-i686.so -Xlibclang_rt.asan-i386.so

I added a patchv2 for just this. To me this makes alot of sense anyway
since you dont strictly depend on the host toolchain C/C++ libraries.
For example I am using clang with custom toolchains in the /opt
directory and the C/C++ libraries are picked up from there.
They might make sense as recommendations.

For splitting the archives, I`d like to write down a scheme, but this
will take a few days. The patchv2 should result in the same
dependencies as before, but still have the multilibs included.
Works correctly on amd64 and should compile on all others, some other
archs might end up with additional dependencies (32/64bit C/C++libs)
like the previous patch - which we can fix by expanding the table of
extensions (MULTILIB_EXTS).

Kind Regards,
Norbert

PS.: an older patch for splitting up the libs is attached by Bug
#829441. But I think a different approach would be better


2016-11-01 21:24 GMT+01:00 Sylvestre Ledru :
> 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 

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

[Sylvestre Ledru]

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

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

[Norbert Lange]

Hi,

we absolutely should do this. I believe we have some communication
problems, because I brought this up multiple times.

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?

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.

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.

2016-11-01 19:33 GMT+01:00 Sylvestre Ledru :
> I wonder if we should not move the new files into a dedicated packages.
>
> When installing this package, it is installing new packages (lib32gcc1,
> lib32stdc++6 and libc6-i386) [1]
> This would increase the installation size quite consequently for a specific
> case.
>
> What do you think?
>
> Thanks
> S
>
>
> [1]
> Unpacking libclang-common-3.8-dev (1:3.8.1-13) over (1:3.8.1-13) ...
> dpkg: dependency problems prevent configuration of libclang-common-3.8-dev:
>  libclang-common-3.8-dev depends on lib32gcc1 (>= 1:3.3); however:
>   Package lib32gcc1 is not installed.
>  libclang-common-3.8-dev depends on lib32stdc++6 (>= 4.1.1); however:
>   Package lib32stdc++6 is not installed.
>  libclang-common-3.8-dev depends on libc6-i386 (>= 2.2.4); however:
>   Package libc6-i386 is not installed.
>
>
> Le 01/11/2016 à 16:31, Norbert Lange a écrit :
>
> Hi,
>
> first, I think this was an issue on my docker installation, it builds
> fine without that option natively. so try without this option
> secondly - yes its discouraged, just as adding libs from different
> architectures in one archive, lint has some more complaints on the
> llvm packages. I`d still prefer getting the libs compiled for now,
> testing if it generally compiles on the supported architectures.
> Ideally we will split the packages later, but Id prefer getting an
> overview on how to do it (what gets built on other archs), an a
> working solution right now.
>
> I also added a new version of the script.
> Run it with 'sh  testclang.sh clang-3.9 -v', will give you a table at
> the end describing the state of the options (compiles, links or
> executes) and the linked clang libs.
>
> Kind Regards,
> Norbert
>
> On Tue, 1 Nov 2016 16:18:57 +0100 Sylvestre Ledru 
> wrote:
>
> Hello,
>
> Thanks for your patch. However, I don't really like the
> --ignore-missing-info option (especially as the doc says
> "Usage of this option is discouraged")
> Any other option?
>
> Cheers,
> Sylvesre
>
>
>
> Le 01/11/2016 à 00:56, Lange Norbert a écrit :
>
> Hello,
>
> I don`t know if the docker installation got messed up (different so versions
> than on my native system), but the dh_shlibdeps step won`t find the correct
> packages for some 32bit libraries.
> In case some packages wont build, those errors could be ignored.
>
>
> diff -burN debian.org/control debian/control
> --- debian.org/control 2016-10-31 23:33:26.307560672 +0100
> +++ debian/control 2016-10-31 23:36:29.861497749 +0100
> @@ -7,7 +7,7 @@
>   cmake, perl, libtool, chrpath, texinfo, sharutils, libffi-dev (>=
> 3.0.9),
>   lsb-release, patchutils, diffstat, xz-utils, python-dev,
>   libedit-dev, swig, python-six, python-sphinx, ocaml-nox, binutils-dev,
> -libjsoncpp-dev,
> +libjsoncpp-dev, g++-multilib,
>   lcov, procps, help2man, dh-ocaml, zlib1g-dev
>   Build-Conflicts: oprofile, ocaml, libllvm-3.4-ocaml-dev,
> libllvm-3.5-ocaml-dev,
> libllvm-3.8-ocaml-dev, libllvm-3.9-ocaml-dev
> diff -burN debian.org/rules debian/rules
> --- debian.org/rules 2016-10-31 23:33:26.307560672 +0100
> +++ debian/rules 2016-11-01 00:48:08.022283769 +0100
> @@ -400,7 +400,7 @@
>
>
>   override_dh_shlibdeps:
> -
> LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/
> dh_shlibdeps
> + dh_shlibdeps -l$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/ --
> --ignore-missing-info
>
>   override_dh_installman:
>   dh_installman
>
> 
> Von: Lange Norbert
> Gesendet: Montag, 31. Oktober 2016 23:58
> An: Sylvestre Ledru; 841...@bugs.debian.org
> Betreff: AW: AW: Bug#841923: libclang-common-3.9-dev: missing multilib
> binaries
>
> Hi,
>
> patch is attached. I tested a clean docker installation of debian-testing,
> adding this dependency generates the additional libraries.
> Having those built once via the debian build machinery should give us an
> idea which subtypes are supported, and wether it crashes and burns an some
> systems (looking at gcc-6 source package theres alot arch.dependend
> libraries there)
>
> I`ll think of some scriptable 

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

[Sylvestre Ledru]

I wonder if we should not move the new files into a dedicated packages.

When installing this package, it is installing new packages (lib32gcc1, 
lib32stdc++6 and libc6-i386) [1]
This would increase the installation size quite consequently for a 
specific case.


What do you think?

Thanks
S


[1]
Unpacking libclang-common-3.8-dev (1:3.8.1-13) over (1:3.8.1-13) ...
dpkg: dependency problems prevent configuration of libclang-common-3.8-dev:
 libclang-common-3.8-dev depends on lib32gcc1 (>= 1:3.3); however:
  Package lib32gcc1 is not installed.
 libclang-common-3.8-dev depends on lib32stdc++6 (>= 4.1.1); however:
  Package lib32stdc++6 is not installed.
 libclang-common-3.8-dev depends on libc6-i386 (>= 2.2.4); however:
  Package libc6-i386 is not installed.

Le 01/11/2016 à 16:31, Norbert Lange a écrit :

Hi,

first, I think this was an issue on my docker installation, it builds
fine without that option natively. so try without this option
secondly - yes its discouraged, just as adding libs from different
architectures in one archive, lint has some more complaints on the
llvm packages. I`d still prefer getting the libs compiled for now,
testing if it generally compiles on the supported architectures.
Ideally we will split the packages later, but Id prefer getting an
overview on how to do it (what gets built on other archs), an a
working solution right now.

I also added a new version of the script.
Run it with 'sh  testclang.sh clang-3.9 -v', will give you a table at
the end describing the state of the options (compiles, links or
executes) and the linked clang libs.

Kind Regards,
Norbert

On Tue, 1 Nov 2016 16:18:57 +0100 Sylvestre Ledru  wrote:

Hello,

Thanks for your patch. However, I don't really like the
--ignore-missing-info option (especially as the doc says
"Usage of this option is discouraged")
Any other option?

Cheers,
Sylvesre



Le 01/11/2016 à 00:56, Lange Norbert a écrit :

Hello,

I don`t know if the docker installation got messed up (different so versions 
than on my native system), but the dh_shlibdeps step won`t find the correct 
packages for some 32bit libraries.
In case some packages wont build, those errors could be ignored.


diff -burN debian.org/control debian/control
--- debian.org/control 2016-10-31 23:33:26.307560672 +0100
+++ debian/control 2016-10-31 23:36:29.861497749 +0100
@@ -7,7 +7,7 @@
   cmake, perl, libtool, chrpath, texinfo, sharutils, libffi-dev (>= 3.0.9),
   lsb-release, patchutils, diffstat, xz-utils, python-dev,
   libedit-dev, swig, python-six, python-sphinx, ocaml-nox, binutils-dev,
-libjsoncpp-dev,
+libjsoncpp-dev, g++-multilib,
   lcov, procps, help2man, dh-ocaml, zlib1g-dev
   Build-Conflicts: oprofile, ocaml, libllvm-3.4-ocaml-dev, 
libllvm-3.5-ocaml-dev,
 libllvm-3.8-ocaml-dev, libllvm-3.9-ocaml-dev
diff -burN debian.org/rules debian/rules
--- debian.org/rules 2016-10-31 23:33:26.307560672 +0100
+++ debian/rules 2016-11-01 00:48:08.022283769 +0100
@@ -400,7 +400,7 @@


   override_dh_shlibdeps:
- 
LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/ 
dh_shlibdeps
+ dh_shlibdeps -l$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/ -- 
--ignore-missing-info

   override_dh_installman:
   dh_installman


Von: Lange Norbert
Gesendet: Montag, 31. Oktober 2016 23:58
An: Sylvestre Ledru; 841...@bugs.debian.org
Betreff: AW: AW: Bug#841923: libclang-common-3.9-dev: missing multilib binaries

Hi,

patch is attached. I tested a clean docker installation of debian-testing, 
adding this dependency generates the additional libraries.
Having those built once via the debian build machinery should give us an idea 
which subtypes are supported, and wether it crashes and burns an some systems 
(looking at gcc-6 source package theres alot arch.dependend libraries there)

I`ll think of some scriptable tests too, but this will have to smart enough to figure out 
the expected variants for all supported hosts (ie the suported "multilib" 
flags).

Kind regards,
Norbert


___
Pkg-llvm-team mailing list
pkg-llvm-t...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-llvm-team

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

[Norbert Lange]

Hi,

first, I think this was an issue on my docker installation, it builds
fine without that option natively. so try without this option
secondly - yes its discouraged, just as adding libs from different
architectures in one archive, lint has some more complaints on the
llvm packages. I`d still prefer getting the libs compiled for now,
testing if it generally compiles on the supported architectures.
Ideally we will split the packages later, but Id prefer getting an
overview on how to do it (what gets built on other archs), an a
working solution right now.

I also added a new version of the script.
Run it with 'sh  testclang.sh clang-3.9 -v', will give you a table at
the end describing the state of the options (compiles, links or
executes) and the linked clang libs.

Kind Regards,
Norbert

On Tue, 1 Nov 2016 16:18:57 +0100 Sylvestre Ledru  wrote:
>
> Hello,
>
> Thanks for your patch. However, I don't really like the
> --ignore-missing-info option (especially as the doc says
> "Usage of this option is discouraged")
> Any other option?
>
> Cheers,
> Sylvesre
>
>
>
> Le 01/11/2016 à 00:56, Lange Norbert a écrit :
> > Hello,
> >
> > I don`t know if the docker installation got messed up (different so 
> > versions than on my native system), but the dh_shlibdeps step won`t find 
> > the correct packages for some 32bit libraries.
> > In case some packages wont build, those errors could be ignored.
> >
> >
> > diff -burN debian.org/control debian/control
> > --- debian.org/control 2016-10-31 23:33:26.307560672 +0100
> > +++ debian/control 2016-10-31 23:36:29.861497749 +0100
> > @@ -7,7 +7,7 @@
> >   cmake, perl, libtool, chrpath, texinfo, sharutils, libffi-dev (>= 
> > 3.0.9),
> >   lsb-release, patchutils, diffstat, xz-utils, python-dev,
> >   libedit-dev, swig, python-six, python-sphinx, ocaml-nox, binutils-dev,
> > -libjsoncpp-dev,
> > +libjsoncpp-dev, g++-multilib,
> >   lcov, procps, help2man, dh-ocaml, zlib1g-dev
> >   Build-Conflicts: oprofile, ocaml, libllvm-3.4-ocaml-dev, 
> > libllvm-3.5-ocaml-dev,
> > libllvm-3.8-ocaml-dev, libllvm-3.9-ocaml-dev
> > diff -burN debian.org/rules debian/rules
> > --- debian.org/rules 2016-10-31 23:33:26.307560672 +0100
> > +++ debian/rules 2016-11-01 00:48:08.022283769 +0100
> > @@ -400,7 +400,7 @@
> >
> >
> >   override_dh_shlibdeps:
> > - 
> > LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/
> >  dh_shlibdeps
> > + dh_shlibdeps -l$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/ -- 
> > --ignore-missing-info
> >
> >   override_dh_installman:
> >   dh_installman
> >
> > 
> > Von: Lange Norbert
> > Gesendet: Montag, 31. Oktober 2016 23:58
> > An: Sylvestre Ledru; 841...@bugs.debian.org
> > Betreff: AW: AW: Bug#841923: libclang-common-3.9-dev: missing multilib 
> > binaries
> >
> > Hi,
> >
> > patch is attached. I tested a clean docker installation of debian-testing, 
> > adding this dependency generates the additional libraries.
> > Having those built once via the debian build machinery should give us an 
> > idea which subtypes are supported, and wether it crashes and burns an some 
> > systems (looking at gcc-6 source package theres alot arch.dependend 
> > libraries there)
> >
> > I`ll think of some scriptable tests too, but this will have to smart enough 
> > to figure out the expected variants for all supported hosts (ie the 
> > suported "multilib" flags).
> >
> > Kind regards,
> > Norbert


testclang.sh
Description: Bourne shell script

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

[Sylvestre Ledru]

Hello,

Thanks for your patch. However, I don't really like the 
--ignore-missing-info option (especially as the doc says

"Usage of this option is discouraged")
Any other option?

Cheers,
Sylvesre

 


Le 01/11/2016 à 00:56, Lange Norbert a écrit :

Hello,

I don`t know if the docker installation got messed up (different so versions 
than on my native system), but the dh_shlibdeps step won`t find the correct 
packages for some 32bit libraries.
In case some packages wont build, those errors could be ignored.


diff -burN debian.org/control debian/control
--- debian.org/control  2016-10-31 23:33:26.307560672 +0100
+++ debian/control  2016-10-31 23:36:29.861497749 +0100
@@ -7,7 +7,7 @@
  cmake, perl, libtool, chrpath, texinfo, sharutils, libffi-dev (>= 3.0.9),
  lsb-release, patchutils, diffstat, xz-utils, python-dev,
  libedit-dev, swig, python-six, python-sphinx, ocaml-nox, binutils-dev,
-libjsoncpp-dev,
+libjsoncpp-dev, g++-multilib,
  lcov, procps, help2man, dh-ocaml, zlib1g-dev
  Build-Conflicts: oprofile, ocaml, libllvm-3.4-ocaml-dev, 
libllvm-3.5-ocaml-dev,
libllvm-3.8-ocaml-dev, libllvm-3.9-ocaml-dev
diff -burN debian.org/rules debian/rules
--- debian.org/rules2016-10-31 23:33:26.307560672 +0100
+++ debian/rules2016-11-01 00:48:08.022283769 +0100
@@ -400,7 +400,7 @@
  
  
  override_dh_shlibdeps:

-   
LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/ 
dh_shlibdeps
+   dh_shlibdeps -l$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/ -- 
--ignore-missing-info
  
  override_dh_installman:

dh_installman


Von: Lange Norbert
Gesendet: Montag, 31. Oktober 2016 23:58
An: Sylvestre Ledru; 841...@bugs.debian.org
Betreff: AW: AW: Bug#841923: libclang-common-3.9-dev: missing multilib binaries

Hi,

patch is attached. I tested a clean docker installation of debian-testing, 
adding this dependency generates the additional libraries.
Having those built once via the debian build machinery should give us an idea 
which subtypes are supported, and wether it crashes and burns an some systems 
(looking at gcc-6 source package theres alot arch.dependend libraries there)

I`ll think of some scriptable tests too, but this will have to smart enough to figure out 
the expected variants for all supported hosts (ie the suported "multilib" 
flags).

Kind regards,
Norbert

PS. I would have an idea for the generic multiarch support too. Since clang is 
a 'native' crosscompiler, it should be possibly to eg. compile a firmware for 
ARM quite easily, aslong a linker and the support libraries are installed.
Is there interest in getting this easily done in debian, or something underway 
already (to your knowledge)?
Would take some time to think through and propose.

--- debian.org/control  2016-10-31 23:33:26.307560672 +0100
+++ debian/control  2016-10-31 23:36:29.861497749 +0100
@@ -7,7 +7,7 @@
  cmake, perl, libtool, chrpath, texinfo, sharutils, libffi-dev (>= 3.0.9),
  lsb-release, patchutils, diffstat, xz-utils, python-dev,
  libedit-dev, swig, python-six, python-sphinx, ocaml-nox, binutils-dev,
-libjsoncpp-dev,
+libjsoncpp-dev, g++-multilib,
  lcov, procps, help2man, dh-ocaml, zlib1g-dev
  Build-Conflicts: oprofile, ocaml, libllvm-3.4-ocaml-dev, 
libllvm-3.5-ocaml-dev,
libllvm-3.8-ocaml-dev, libllvm-3.9-ocaml-dev



Von: Sylvestre Ledru [sle...@mozilla.com] im Auftrag von Sylvestre 
Ledru [sylves...@mozilla.com]
Gesendet: Montag, 31. Oktober 2016 18:32
An: Lange Norbert; 841...@bugs.debian.org
Betreff: Re: AW: Bug#841923: libclang-common-3.9-dev: missing multilib binaries

Hello

If you give me a patch for 3.8 and / or 3.9 and a way to test the new
usage [1], I would be happy to apply it immediatly.

Thanks
Sylvestre
[1]
https://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/qualify-clang.sh?view=markup
=> integrated this way :)
Le 31/10/2016 à 18:29, Lange Norbert a écrit :

Hello,

yes I know and the bug is for an older version and I added information (that 
most likely just the build depency is missing).
I am not really looking through the debian bug report system and how its 
supposed to be used for this,

Further, the patch I proposed there wouldn`t be needed currently.

For testing... the libraries are plainly missing. I suppose its the automatic 
build system than just installs the build depencies and nothing else.
I built the debian source archive locally and it works fine.

Whats left is splitting out the i386 (and i686) libraries, or deciding wether 
this is actually necessary (debian guidelines about non-native libs?).
But IMHO this could be done independently.

I am happy to help out, but the mailing list seems to be too high-latency for 
this. Any proposition how we should go about this?
If you add the build depencies, I should finally get libraries from the 
repository just like I built them locally and 

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

[Norbert Lange]

Hi,

I attached a script for an exhaustive run of arguments, with the aim
to link all existing libraries from this package once.
As you will see, there are alot failure, most of which arent a problem
of the packaging. We would need to figure out which
features should work.
So far this should be:
* everything on amd64
* rtlib and address- / undefined-sanitizer on x86
* rtlib on x32

Usage is for ex.:
sh  testclang.sh clang-3.9
or (adds -v option everywhere so you see the linked libs):
sh  testclang.sh clang-3.9 -v

Some points
* if being a full replacement for gcc is the aim, x32 should be
supported too (-sanitizer=undefined)
* I don`t know how the i686 libraries are picked up, I thouhgt
--march=i686 would do the trick, but it still uses the i386 variants.
maybe need to set clang to a i686 toolchain like
'--gcc-toolchain=/usr/lib/gcc/i686-linux-gnu/6' ?
* Also it seems, that sanitizers always are linked statically, even if
eg. asan has a shared library aswell.
* memory sanitizer (Bug #842642) and efficiency sanitizer segfault on
the simple test. (the later is still WIP, but maybe it would be best
to not build/include it for now?)

Maybe you can bring the discussion upstream, for what should be
supported, and wether some libs are`nt used at all

Kind regards,
Norbert

On Tue, 1 Nov 2016 08:25:08 +0100 Sylvestre Ledru  wrote:
> Hello
>
> Thanks for the patch. How do I test this change from the user perspective?
>
> Thanks
> Sylvestre
>
> Le 1 nov. 2016 00:56, "Lange Norbert"  a écrit :
>
> > Hello,
> >
> > I don`t know if the docker installation got messed up (different so
> > versions than on my native system), but the dh_shlibdeps step won`t find
> > the correct packages for some 32bit libraries.
> > In case some packages wont build, those errors could be ignored.
> >
> >
> > diff -burN debian.org/control debian/control
> > --- debian.org/control  2016-10-31 23:33:26.307560672 +0100
> > +++ debian/control  2016-10-31 23:36:29.861497749 +0100
> > @@ -7,7 +7,7 @@
> >  cmake, perl, libtool, chrpath, texinfo, sharutils, libffi-dev (>=
> > 3.0.9),
> >  lsb-release, patchutils, diffstat, xz-utils, python-dev,
> >  libedit-dev, swig, python-six, python-sphinx, ocaml-nox, binutils-dev,
> > -libjsoncpp-dev,
> > +libjsoncpp-dev, g++-multilib,
> >  lcov, procps, help2man, dh-ocaml, zlib1g-dev
> >  Build-Conflicts: oprofile, ocaml, libllvm-3.4-ocaml-dev,
> > libllvm-3.5-ocaml-dev,
> >libllvm-3.8-ocaml-dev, libllvm-3.9-ocaml-dev
> > diff -burN debian.org/rules debian/rules
> > --- debian.org/rules2016-10-31 23:33:26.307560672 +0100
> > +++ debian/rules2016-11-01 00:48:08.022283769 +0100
> > @@ -400,7 +400,7 @@
> >
> >
> >  override_dh_shlibdeps:
> > -   
> > LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/
> > dh_shlibdeps
> > +   dh_shlibdeps -l$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/ --
> > --ignore-missing-info
> >
> >  override_dh_installman:
> > dh_installman
> >
> > 
> > Von: Lange Norbert
> > Gesendet: Montag, 31. Oktober 2016 23:58
> > An: Sylvestre Ledru; 841...@bugs.debian.org
> > Betreff: AW: AW: Bug#841923: libclang-common-3.9-dev: missing multilib
> > binaries
> >
> > Hi,
> >
> > patch is attached. I tested a clean docker installation of debian-testing,
> > adding this dependency generates the additional libraries.
> > Having those built once via the debian build machinery should give us an
> > idea which subtypes are supported, and wether it crashes and burns an some
> > systems (looking at gcc-6 source package theres alot arch.dependend


testclang.sh
Description: Bourne shell script

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

[Sylvestre Ledru]

Hello

Thanks for the patch. How do I test this change from the user perspective?

Thanks
Sylvestre

Le 1 nov. 2016 00:56, "Lange Norbert"  a écrit :

> Hello,
>
> I don`t know if the docker installation got messed up (different so
> versions than on my native system), but the dh_shlibdeps step won`t find
> the correct packages for some 32bit libraries.
> In case some packages wont build, those errors could be ignored.
>
>
> diff -burN debian.org/control debian/control
> --- debian.org/control  2016-10-31 23:33:26.307560672 +0100
> +++ debian/control  2016-10-31 23:36:29.861497749 +0100
> @@ -7,7 +7,7 @@
>  cmake, perl, libtool, chrpath, texinfo, sharutils, libffi-dev (>=
> 3.0.9),
>  lsb-release, patchutils, diffstat, xz-utils, python-dev,
>  libedit-dev, swig, python-six, python-sphinx, ocaml-nox, binutils-dev,
> -libjsoncpp-dev,
> +libjsoncpp-dev, g++-multilib,
>  lcov, procps, help2man, dh-ocaml, zlib1g-dev
>  Build-Conflicts: oprofile, ocaml, libllvm-3.4-ocaml-dev,
> libllvm-3.5-ocaml-dev,
>libllvm-3.8-ocaml-dev, libllvm-3.9-ocaml-dev
> diff -burN debian.org/rules debian/rules
> --- debian.org/rules2016-10-31 23:33:26.307560672 +0100
> +++ debian/rules2016-11-01 00:48:08.022283769 +0100
> @@ -400,7 +400,7 @@
>
>
>  override_dh_shlibdeps:
> -   
> LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/
> dh_shlibdeps
> +   dh_shlibdeps -l$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/ --
> --ignore-missing-info
>
>  override_dh_installman:
> dh_installman
>
> 
> Von: Lange Norbert
> Gesendet: Montag, 31. Oktober 2016 23:58
> An: Sylvestre Ledru; 841...@bugs.debian.org
> Betreff: AW: AW: Bug#841923: libclang-common-3.9-dev: missing multilib
> binaries
>
> Hi,
>
> patch is attached. I tested a clean docker installation of debian-testing,
> adding this dependency generates the additional libraries.
> Having those built once via the debian build machinery should give us an
> idea which subtypes are supported, and wether it crashes and burns an some
> systems (looking at gcc-6 source package theres alot arch.dependend
> libraries there)
>
> I`ll think of some scriptable tests too, but this will have to smart
> enough to figure out the expected variants for all supported hosts (ie the
> suported "multilib" flags).
>
> Kind regards,
> Norbert
>
> PS. I would have an idea for the generic multiarch support too. Since
> clang is a 'native' crosscompiler, it should be possibly to eg. compile a
> firmware for ARM quite easily, aslong a linker and the support libraries
> are installed.
> Is there interest in getting this easily done in debian, or something
> underway already (to your knowledge)?
> Would take some time to think through and propose.
>
> --- debian.org/control  2016-10-31 23:33:26.307560672 +0100
> +++ debian/control  2016-10-31 23:36:29.861497749 +0100
> @@ -7,7 +7,7 @@
>  cmake, perl, libtool, chrpath, texinfo, sharutils, libffi-dev (>=
> 3.0.9),
>  lsb-release, patchutils, diffstat, xz-utils, python-dev,
>  libedit-dev, swig, python-six, python-sphinx, ocaml-nox, binutils-dev,
> -libjsoncpp-dev,
> +libjsoncpp-dev, g++-multilib,
>  lcov, procps, help2man, dh-ocaml, zlib1g-dev
>  Build-Conflicts: oprofile, ocaml, libllvm-3.4-ocaml-dev,
> libllvm-3.5-ocaml-dev,
>libllvm-3.8-ocaml-dev, libllvm-3.9-ocaml-dev
>
>
> 
> Von: Sylvestre Ledru [sle...@mozilla.com] im Auftrag von
> Sylvestre Ledru [sylves...@mozilla.com]
> Gesendet: Montag, 31. Oktober 2016 18:32
> An: Lange Norbert; 841...@bugs.debian.org
> Betreff: Re: AW: Bug#841923: libclang-common-3.9-dev: missing multilib
> binaries
>
> Hello
>
> If you give me a patch for 3.8 and / or 3.9 and a way to test the new
> usage [1], I would be happy to apply it immediatly.
>
> Thanks
> Sylvestre
> [1]
> https://anonscm.debian.org/viewvc/pkg-llvm/llvm-
> toolchain/branches/qualify-clang.sh?view=markup
> => integrated this way :)
> Le 31/10/2016 à 18:29, Lange Norbert a écrit :
> > Hello,
> >
> > yes I know and the bug is for an older version and I added information
> (that most likely just the build depency is missing).
> > I am not really looking through the debian bug report system and how its
> supposed to be used for this,
> >
> > Further, the patch I proposed there wouldn`t be needed currently.
> >
> > For testing... the libraries are plainly missing. I suppose its the
> automatic build system than just installs the build depencies and nothing
> else.
> > I built the debian source archive locally and it works fine.
> >
> > Whats left is splitting out the i386 (and i686) libraries, or deciding
> wether this is actually necessary (debian guidelines about non-native
> libs?).
> > But IMHO this could be done independently.
> >
> > I am happy to help out, but the mailing list seems to be too
> high-latency for this. Any proposition how we 

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

[Lange Norbert]

Hello,

I don`t know if the docker installation got messed up (different so versions 
than on my native system), but the dh_shlibdeps step won`t find the correct 
packages for some 32bit libraries.
In case some packages wont build, those errors could be ignored.


diff -burN debian.org/control debian/control
--- debian.org/control  2016-10-31 23:33:26.307560672 +0100
+++ debian/control  2016-10-31 23:36:29.861497749 +0100
@@ -7,7 +7,7 @@
 cmake, perl, libtool, chrpath, texinfo, sharutils, libffi-dev (>= 3.0.9),
 lsb-release, patchutils, diffstat, xz-utils, python-dev,
 libedit-dev, swig, python-six, python-sphinx, ocaml-nox, binutils-dev,
-libjsoncpp-dev,
+libjsoncpp-dev, g++-multilib,
 lcov, procps, help2man, dh-ocaml, zlib1g-dev
 Build-Conflicts: oprofile, ocaml, libllvm-3.4-ocaml-dev, libllvm-3.5-ocaml-dev,
   libllvm-3.8-ocaml-dev, libllvm-3.9-ocaml-dev
diff -burN debian.org/rules debian/rules
--- debian.org/rules2016-10-31 23:33:26.307560672 +0100
+++ debian/rules2016-11-01 00:48:08.022283769 +0100
@@ -400,7 +400,7 @@
 
 
 override_dh_shlibdeps:
-   
LD_LIBRARY_PATH=$$LD_LIBRARY_PATH:$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/ 
dh_shlibdeps
+   dh_shlibdeps -l$(DEB_INST)/usr/lib/llvm-$(LLVM_VERSION)/lib/ -- 
--ignore-missing-info
 
 override_dh_installman:
dh_installman


Von: Lange Norbert
Gesendet: Montag, 31. Oktober 2016 23:58
An: Sylvestre Ledru; 841...@bugs.debian.org
Betreff: AW: AW: Bug#841923: libclang-common-3.9-dev: missing multilib binaries

Hi,

patch is attached. I tested a clean docker installation of debian-testing, 
adding this dependency generates the additional libraries.
Having those built once via the debian build machinery should give us an idea 
which subtypes are supported, and wether it crashes and burns an some systems 
(looking at gcc-6 source package theres alot arch.dependend libraries there)

I`ll think of some scriptable tests too, but this will have to smart enough to 
figure out the expected variants for all supported hosts (ie the suported 
"multilib" flags).

Kind regards,
Norbert

PS. I would have an idea for the generic multiarch support too. Since clang is 
a 'native' crosscompiler, it should be possibly to eg. compile a firmware for 
ARM quite easily, aslong a linker and the support libraries are installed.
Is there interest in getting this easily done in debian, or something underway 
already (to your knowledge)?
Would take some time to think through and propose.

--- debian.org/control  2016-10-31 23:33:26.307560672 +0100
+++ debian/control  2016-10-31 23:36:29.861497749 +0100
@@ -7,7 +7,7 @@
 cmake, perl, libtool, chrpath, texinfo, sharutils, libffi-dev (>= 3.0.9),
 lsb-release, patchutils, diffstat, xz-utils, python-dev,
 libedit-dev, swig, python-six, python-sphinx, ocaml-nox, binutils-dev,
-libjsoncpp-dev,
+libjsoncpp-dev, g++-multilib,
 lcov, procps, help2man, dh-ocaml, zlib1g-dev
 Build-Conflicts: oprofile, ocaml, libllvm-3.4-ocaml-dev, libllvm-3.5-ocaml-dev,
   libllvm-3.8-ocaml-dev, libllvm-3.9-ocaml-dev



Von: Sylvestre Ledru [sle...@mozilla.com] im Auftrag von Sylvestre 
Ledru [sylves...@mozilla.com]
Gesendet: Montag, 31. Oktober 2016 18:32
An: Lange Norbert; 841...@bugs.debian.org
Betreff: Re: AW: Bug#841923: libclang-common-3.9-dev: missing multilib binaries

Hello

If you give me a patch for 3.8 and / or 3.9 and a way to test the new
usage [1], I would be happy to apply it immediatly.

Thanks
Sylvestre
[1]
https://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/qualify-clang.sh?view=markup
=> integrated this way :)
Le 31/10/2016 à 18:29, Lange Norbert a écrit :
> Hello,
>
> yes I know and the bug is for an older version and I added information (that 
> most likely just the build depency is missing).
> I am not really looking through the debian bug report system and how its 
> supposed to be used for this,
>
> Further, the patch I proposed there wouldn`t be needed currently.
>
> For testing... the libraries are plainly missing. I suppose its the automatic 
> build system than just installs the build depencies and nothing else.
> I built the debian source archive locally and it works fine.
>
> Whats left is splitting out the i386 (and i686) libraries, or deciding wether 
> this is actually necessary (debian guidelines about non-native libs?).
> But IMHO this could be done independently.
>
> I am happy to help out, but the mailing list seems to be too high-latency for 
> this. Any proposition how we should go about this?
> If you add the build depencies, I should finally get libraries from the 
> repository just like I built them locally and have used for a long time. I 
> can then use this to start some builds.
>
> If its necessary to split out the libraries, I can work on that if I get some 
> definitive rules ("clang-multiarch" meta-package and lib32 variants?). See 
> 

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

[Lange Norbert]

Hi,

patch is attached. I tested a clean docker installation of debian-testing, 
adding this dependency generates the additional libraries.
Having those built once via the debian build machinery should give us an idea 
which subtypes are supported, and wether it crashes and burns an some systems 
(looking at gcc-6 source package theres alot arch.dependend libraries there)

I`ll think of some scriptable tests too, but this will have to smart enough to 
figure out the expected variants for all supported hosts (ie the suported 
"multilib" flags).

Kind regards,
Norbert

PS. I would have an idea for the generic multiarch support too. Since clang is 
a 'native' crosscompiler, it should be possibly to eg. compile a firmware for 
ARM quite easily, aslong a linker and the support libraries are installed.
Is there interest in getting this easily done in debian, or something underway 
already (to your knowledge)?
Would take some time to think through and propose.

--- debian.org/control  2016-10-31 23:33:26.307560672 +0100
+++ debian/control  2016-10-31 23:36:29.861497749 +0100
@@ -7,7 +7,7 @@
 cmake, perl, libtool, chrpath, texinfo, sharutils, libffi-dev (>= 3.0.9),
 lsb-release, patchutils, diffstat, xz-utils, python-dev,
 libedit-dev, swig, python-six, python-sphinx, ocaml-nox, binutils-dev,
-libjsoncpp-dev,
+libjsoncpp-dev, g++-multilib,
 lcov, procps, help2man, dh-ocaml, zlib1g-dev
 Build-Conflicts: oprofile, ocaml, libllvm-3.4-ocaml-dev, libllvm-3.5-ocaml-dev,
   libllvm-3.8-ocaml-dev, libllvm-3.9-ocaml-dev



Von: Sylvestre Ledru [sle...@mozilla.com] im Auftrag von Sylvestre 
Ledru [sylves...@mozilla.com]
Gesendet: Montag, 31. Oktober 2016 18:32
An: Lange Norbert; 841...@bugs.debian.org
Betreff: Re: AW: Bug#841923: libclang-common-3.9-dev: missing multilib binaries

Hello

If you give me a patch for 3.8 and / or 3.9 and a way to test the new
usage [1], I would be happy to apply it immediatly.

Thanks
Sylvestre
[1]
https://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/qualify-clang.sh?view=markup
=> integrated this way :)
Le 31/10/2016 à 18:29, Lange Norbert a écrit :
> Hello,
>
> yes I know and the bug is for an older version and I added information (that 
> most likely just the build depency is missing).
> I am not really looking through the debian bug report system and how its 
> supposed to be used for this,
>
> Further, the patch I proposed there wouldn`t be needed currently.
>
> For testing... the libraries are plainly missing. I suppose its the automatic 
> build system than just installs the build depencies and nothing else.
> I built the debian source archive locally and it works fine.
>
> Whats left is splitting out the i386 (and i686) libraries, or deciding wether 
> this is actually necessary (debian guidelines about non-native libs?).
> But IMHO this could be done independently.
>
> I am happy to help out, but the mailing list seems to be too high-latency for 
> this. Any proposition how we should go about this?
> If you add the build depencies, I should finally get libraries from the 
> repository just like I built them locally and have used for a long time. I 
> can then use this to start some builds.
>
> If its necessary to split out the libraries, I can work on that if I get some 
> definitive rules ("clang-multiarch" meta-package and lib32 variants?). See 
> https://packages.debian.org/source/sid/gcc-6 how this is done for gcc
> This sure will get tricky, since some libs dont build on x86, some more dont 
> build on mips, etc...
>
>
> Kind Regards,
> Norbert
> 
> Von: Sylvestre Ledru [sylves...@debian.org]
> Gesendet: Montag, 31. Oktober 2016 11:51
> An: Lange Norbert; 841...@bugs.debian.org
> Betreff: Re: Bug#841923: libclang-common-3.9-dev: missing multilib binaries
>
> Hello Norbert,
>
> Le 24/10/2016 à 15:28, Norbert Lange a écrit :
>> Package: libclang-common-3.9-dev
>> Version: 1:3.9-2
>> Severity: important
>>
>> Dear Maintainer,
>>
>> On plattforms such as amd64, the libraries necessary to build for other 
>> architectures (i386 in this case) are missing.
>>
>> A local build of the package will however result in those libraries beeing 
>> built and packaged,
>> so I believe that the build-depencies for creating the libraries are missing 
>> (g++multilib?) and the
>> lvvm build will just silently skip over the libraries it can`t build
>> (this bug is going back to atleast llvm 3.7)
> You already reported bug #829441 about that. I am happy to apply this but I 
> need help for testing it.
>
> Sylvestre
>
>
>
> #
>
> This message and any attachments are solely for the use of the intended 
> recipients. They may contain privileged and/or confidential information or 
> other information protected from disclosure. If you are not an intended 
> recipient, you are hereby notified that you