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
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
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
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
> 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
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
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
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
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
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
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:
*
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),
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
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
14 matches
Mail list logo