zlib fails to build on s390x on oracular with gcc 14
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu on IBM z Systems |
Fix Released
|
Critical
|
bugproxy | ||
gcc-14 (Ubuntu) |
Fix Released
|
Undecided
|
Matthias Klose | ||
zlib (Ubuntu) |
Invalid
|
Critical
|
Simon Chopin |
Bug Description
Rebuilding zlib for s390x on oracular fails to build, probably due to gcc 14 usage (since it became more strict).
Full build log can be found here:
https:/
erroneous lines are:
D_LARGEFILE64_
contrib/
contrib/
91 | v1 = (uv2di)
| ^~~~~
| |
| uv16qi {aka __vector(16) unsigned char}
contrib/
contrib/
92 | v2 = (uv2di)
| ^~~~~
| |
| uv16qi {aka __vector(16) unsigned char}
contrib/
contrib/
93 | v3 = (uv2di)
| ^~~~~
| |
| uv16qi {aka __vector(16) unsigned char}
contrib/
contrib/
94 | v4 = (uv2di)
| ^~~~~
| |
| uv16qi {aka __vector(16) unsigned char}
contrib/
contrib/
105 | v1 = (uv2di)
| ^~~~~~~~~~
| |
| __vector(16) unsigned char
contrib/
contrib/
106 | v1 = (uv2di)
| ^~~~~~~~~~
| |
| __vector(16) unsigned char
contrib/
contrib/
107 | v1 = (uv2di)
| ^~~~~~~~~~
| |
| __vector(16) unsigned char
contrib/
contrib/
114 | v1 = (uv2di)
| ^~~~~~~~~~
| |
| __vector(16) unsigned char
contrib/
contrib/
161 | v1 = (uv2di)
| ^~~~~~~~~~
| |
| __vector(16) unsigned char
contrib/
contrib/
192 | v2 = (uv2di)
| ^~~~~~~~~~
| |
| __vector(16) unsigned char
contrib/
make[1]: *** [Makefile:180: crc32-vx.o] Error 1
Changed in ubuntu-z-systems: | |
assignee: | nobody → bugproxy (bugproxy) |
Changed in zlib (Ubuntu): | |
assignee: | bugproxy (bugproxy) → nobody |
Changed in ubuntu-z-systems: | |
importance: | Undecided → High |
Changed in zlib (Ubuntu): | |
importance: | Undecided → Critical |
assignee: | nobody → Simon Chopin (schopin) |
status: | New → Triaged |
tags: | added: architecture-s39064 bugnameltc-208475 severity-high targetmilestone-inin--- |
tags: | added: ftbfs update-excuse |
Changed in ubuntu-z-systems: | |
status: | Triaged → Fix Released |
Frank, can you confirm that you got in touch with the upstream author about it?
I probably could "fix" it by sprinkling casts all over the place, which could be wildly unsafe depending on the exact properties of __int128, or by actually using a local __int128 variable and memcpy it or something like that, which might destroy performance? (I recall something like that being a problem in some glibc routines on ARM where moving data from SIMD registers was *really* slow on the Pis)
As you see, I'm in much doubt so knowledge from the people who wrote the patch (and own the hardware) would be greatly appreciated!