glibc 2.28 autopkgtest failures

[Michael Hudson-Doyle]

tl;dr we should force things through :)

There are at the time of writing two autopkgtest failures preventing glibc
from migrating: r-cran-rgenoud and python-cffi

The r-cran-genoud failure is mystifying in that I have no idea how the
glibc version is affecting the package (it doesn't call many libc or libm
functions!). I've spent far too long trying on this but as the package has
no rdeps we should probably just remove it and whoever brings it back can
try to understand why it changes behaviour with new libc. (The test also
looks a bit fragile, it is asserting that optimizing a particular function
with the rng seeded a particular way finds a different maxima to seeding
the rng a different way, afaict).

The python-cffi is exposing a bug that exists already. A minimal failing
example is this:

root at cosmic32:~# cat n.py
import math
from cffi.backend_ctypes import CTypesBackend
from cffi import FFI
ffi = FFI(backend=CTypesBackend())
ffi.cdef(""" void fabs(double x); """)
ffi.dlopen('m').fabs(1.0)
print(math.cos(1.23))
root at cosmic32:~# python3 n.py
Traceback (most recent call last):
  File "n.py", line 7, in <module>
    print(math.cos(1.23))
ValueError: math domain error

The bug is that when you lie to cffi about the return type of a variable,
in particular when you say a function returning a float does not return a
float, the x87 stack is not wiped to the extent required by the calling
convention. glibc 2.28 rewrote the cos function in a way that apparently
now cares about this (or I guess gcc now compiles the function in a way
that cares about this) but make no mistake, it only ever worked by chance
before. So I think the test_sin_no_return_value test should be skipped on
i386. (I'll file an upstream issue I guess).

Cheers,
mwh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20180904/40acb393/attachment.html>