[Bug 1064271] perl-Net-SSLeay tests failing on s390(x) with glibc-2.18.90-21.fc21

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1064271



--- Comment #32 from Carlos O'Donell <codonell at redhat.com> ---
(In reply to Andreas Krebbel from comment #31)
> Yes.
> 
> This is an expected result of the jmpbuf extension. I've tried to minimize
> the effect by versioning all the accessor functions but symbol versioning is
> not available for data structures. In the end there is just one header file
> defining the structure. Code which uses the old header file is not
> compatible with code using the new header file in case jmpbufs are
> transferred between the two.
> 
> This happened in the past already. E.g. for Power with the introduction of
> Altivec or with the long double 64->128 bit extension.

We can do better though :-)

All of this could have been handled by using the compiler to generate a
.gnu.attribute entry for the new ABI when such a structure was used. Then the
static linker could generate a warning when linking mixed ABI objects
(undefined + new ABI) or an error (old ABI + new ABI). This results in a much
better user experience and the .gnu.attributes track which ABI components are
in use (look at ARM which tracks the size of wchar_t).

Nobody likes to do this because it's work and nobody has yet extended the
compiler to do this kind of suppression of the "don't care" state to make
objects as interoperable as possible.

Background reading:
Binutils documention on attributes:
https://sourceware.org/binutils/docs-2.21/as/GNU-Object-Attributes.html#GNU-Object-Attributes
Discussion around "don't care attributes"
https://www.sourceware.org/ml/libc-alpha/2011-02/msg00130.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=RhVfhrWhFY&a=cc_unsubscribe