develooper Front page | perl.perl5.porters | Postings from December 2019

Re: invlist_inline.h crash

Thread Previous | Thread Next
From:
Craig A. Berry
Date:
December 2, 2019 17:19
Subject:
Re: invlist_inline.h crash
Message ID:
CA+vYcVxrvETJMgPKky0nc2y=wnbr4C4w3H+HdUR_O5oe0vq8iQ@mail.gmail.com
On Tue, Nov 26, 2019 at 4:40 PM Steve Hay via perl5-porters
<perl5-porters@perl.org> wrote:
>
> On Tue, 26 Nov 2019 at 10:32, Steve Hay <steve.m.hay@googlemail.com> wrote:
>>
>> On Mon, 25 Nov 2019 at 19:08, Karl Williamson <public@khwilliamson.com> wrote:

>>> I'm not sure how this might affect binary compatibility.  I can't
>>> remember the precise definition for us.  These variables are being
>>> moved, but they are internal variables, and should not be used by any
>>> modules.

>> I'm never clear either. In my mind I've always thought that if you have a working build of perl + XS modules and then install a new perl over the top of it (e.g. upgrading 5.30.0 to 5.30.1) and then find that it doesn't work until you rebuild XS modules then the new perl is not binary compatible with the old. But I never know how to be sure this is not the not case: If you try with lots of XS modules and nothing breaks then hopefully everything is fine, but you never know...!

If an API changes, such as new or removed functions or modified
function signatures, or the size or position of global data changes,
then binary compatibility is broken.  I think that's pretty much all
there is to it but maybe someone else can fill in anything I've left
out.

I think if the size of the interpreter struct or the offset of any of
its members has changed, then binary compatibility is broken.  Unless
there is some guarantee that nothing outside of libperl ever
references or manipulates anything in the interpreter struct, but
that's not the case, is it?

> A rebuild of the same source installed over the top of an existing installation works fine, so the mismatched binaries error is a result of perl having changed. However, if the changes aren't really a problem for binary compatibility, then that seems to imply that more than is really necessary is being taken into account by the handshake check, i.e. that check is causing a failure when really there wouldn't be any problem.

DLL versioning is related to but not the same as binary compatibility.
In principle, on some platforms you can preserve binary compatibility
and add new global symbols by adding them at the end so the offsets of
everything else are still the same, and then tell the linker that
you've taken responsibility for binary compatibility.  The handshake
warnings are probably the linker letting you know that you're linking
against something that was built differently and whether the
differences matter is up to you to sort out.  You would need to
guarantee that all of the same symbols are available at all of the
same offsets, and the answer could be different on different
platforms; on platforms that export all external symbols by default,
moving even "private" variables could change the offsets of other
things.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About