Re: Using Perl's cc

[Gavin Smith]

On 3 July 2015 at 14:01, Gavin Smith <address@hidden> wrote:
>>   . the Perl build used while building Texinfo in general is different
>>     from the one that will be used when the built Texinfo is installed
>>     (and thus the C compiler will be different)
>
> The C compiler should not be needed to be installed for using a
> prebuilt Texinfo package. The big question is ABI: will the loadable
> modules that are distributed as part of a binary Texinfo package be
> compatible with the Perl executable?
>
> I think we need the same compiler to build an extension, but I don't
> know about running the extension. It's possible that a module could be
> loaded for a different Perl to the one it was compiled against, but I
> am still trying to find out if this is the case. There are some
> properties which we need, and which are likely: the processor
> architecture being the same, the calling convention being the same,
> the use of system calls matching and so on. It's possible that it
> won't work in spite of that: it depends on whether the Perl developers
> made the ABI between perl executables and loadable modules stable.

It looks as if there is a check in the C glue code generated by xsubpp
(XSParagraph.c from XSParagraph.xs),  XS_APIVERSION_BOOTCHECK.
(Defined in XSUB.h.), and there are some binary incompatibilities
between Perl versions. This check is done in a bootstrap function,
which registers all of the (other) compiled subroutines with the Perl
interpreter. So the module can be loaded, the bootstrap function in
the module can be identified and made available to Perl, and run. It
might be possible simply to remove this check, and hope for the best.

I found an article at
http://modernperlbooks.com/mt/2009/05/perl-5-and-binary-compatibility.html.
I expect functions in the Perl API are more stable than data
structures, but it's likely that we access data structures somewhere
(via a preprocessor macro, for example).