On Thu, Jan 17, 2019 at 08:04:09PM +0200, Adrian Bunk wrote:
> Source: memkind
> Version: 1.8.0-1
> Severity: serious
>
> https://buildd.debian.org/status/package.php?p=memkind=sid
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/memkind.html
>
> memkind builds for no apparent reason with -msse4.2,
Accent on "no apparent reason" -- there's only a single instruction,
called as : _mm_crc32_u64() -- and it's #ifdefed out.
> which is a baseline violation even on amd64.
I've verified that the 1.8.0-1 packages work ok on an AMD Phenom2 (ie,
without SSE4.2), thus there's no actual violation. You're right that this
causes noise for people doing QA work like you, though, and it'd be good to
patch this away.
> Build failures on other architectures seem to be often
> related to using an internal copy of jemalloc instead
> of the version in Debian.
Yeah, I've looked into using shipped jemalloc; this was not an option at the
time I uploaded this to NEW as memkind needs jemalloc >= 5.0 which wasn't
available then and the transition seemed unlikely in time for Buster. We do
actually have 5.1 in now, though -- but, I'm talking to upstream to see if
patches they applied atop of jemalloc are actually needed. The one for
defrag seems unused, but I'm worried about the dlopen() one -- vanilla
jemalloc can't be dlopened because of something something too much TLS data.
No idea if you've heard of this problem; I'm mentioning this in case you
did.
I prepared _apparently_ ok patches that fix this and all portability
problems for 64-bit archs, but only during some testing I noticed that those
"obviously correct" patches break something. Thus, I'm asking upstream how
to run the testsuite on machines without any kind of special hardware
memkind is meant for so we have at least _some_ automated checks.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.
⠈⠳⣄
