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 <sylves...@mozilla.com>: > 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 <sylves...@mozilla.com> > 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 > >
