<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">I wonder if we should not move the new
files into a dedicated packages.<br>
<br>
When installing this package, it is installing new packages
(lib32gcc1, lib32stdc++6 and libc6-i386) [1]<br>
This would increase the installation size quite consequently for a
specific case.<br>
<br>
What do you think?<br>
<br>
Thanks<br>
S<br>
<br>
<br>
[1] <br>
Unpacking libclang-common-3.8-dev (1:3.8.1-13) over (1:3.8.1-13)
...<br>
dpkg: dependency problems prevent configuration of
libclang-common-3.8-dev:<br>
libclang-common-3.8-dev depends on lib32gcc1 (>= 1:3.3);
however:<br>
Package lib32gcc1 is not installed.<br>
libclang-common-3.8-dev depends on lib32stdc++6 (>= 4.1.1);
however:<br>
Package lib32stdc++6 is not installed.<br>
libclang-common-3.8-dev depends on libc6-i386 (>= 2.2.4);
however:<br>
Package libc6-i386 is not installed.<br>
<br>
Le 01/11/2016 à 16:31, Norbert Lange a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CADYdroMjwCApSzPQKAs5-ZC6XDXWwXM+iYvmqyCF66ipm2Xc9w@mail.gmail.com">
<pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:sylvestre@mozilla.com"><sylvestre@mozilla.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
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 :
</pre>
<blockquote type="cite">
<pre wrap="">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; <a class="moz-txt-link-abbreviated" href="mailto:841923@bugs.debian.org">841923@bugs.debian.org</a>
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
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Pkg-llvm-team mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pkg-llvm-team@lists.alioth.debian.org">Pkg-llvm-team@lists.alioth.debian.org</a>
<a class="moz-txt-link-freetext" href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-llvm-team">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-llvm-team</a></pre>
</blockquote>
</blockquote>
</blockquote>
<p><br>
</p>
</body>
</html>