Front page | perl.perl5.porters |
Postings from November 2008
RE: 5.8.9 RC1
From: Jan Dubois
November 25, 2008 12:05
RE: 5.8.9 RC1
Message ID: 006e01c94f39$3019fef0$904dfcd0$@com
On Tue, 25 Nov 2008, Steve Hay wrote:
> I've been giving this a whirl on Win32 with my own CPAN modules and
> various others, including mod_perl 1 and 2, and haven't had any
> trouble yet. Apache1/mod_perl1 built with VC6 with and without
> ithreads is working, as is Apache2/mod_perl2 built with VC8 :-)
I guess I should have been communicating this too: I'm integrating the
perl-5.8.x branch into the internal ActiveState repository on a daily
basis and build the complete set of ActivePerl binaries with all modules
on the various platforms too and have not seen any problems (except for
some rare and seemingly random failure of some thread tests).
> The other main thing that I want to verify is whether it is binary
> compatible with perl-5.8.8, as it ought to be. I built 5.8.8 and 5.8.9
> with identical build options, then added some CPAN XS modules to the
> 5.8.8 installation, then copied the entire site/lib tree from the
> 5.8.8 installation to the 5.8.9 installation, and then tried using
> that 5.8.9 installation.
> Is that a good test of binary compatibility? If so then it's good news
> again, because that is also working.
It depends on what you mean by "binary compatibility". If you just want
to make sure that modules still load, then this is a somewhat reasonable
test. In the ActivePerl build system we actually check that all symbols
exported by the previous release are still being exported by the current
one, which is a bit more comprehensive (it is not totally comprehensive
as it only covers the combination of build options used by ActivePerl,
so it would not catch if a symbol that used to be always available is now
only exported under ithreads).
I'm not aware of a good way to check that internal data structure haven't
changed. You could write all structure member offsets to a database, and
compare those between builds, but there isn't a good way to even enumerate
all structure members. Trying to find changes in structure layout by running
modules compiled with older perl versions is really hit-and-miss; the problems
might only appear under very particular circumstances. E.g. it was mostly
luck when I detected that the layout of buffers in reentr.h changed between
5.8.0 and 5.8.1 because some test program was calling the right APIs in
the right order to cause some overwriting of "static" buffers that were
still being used by the other functionality.
Recording structure offsets between versions would have caught this problem
right away though.
PS: Note that structure layout changes in reentr.h would hit *all* XS code
using the reentrant functions of the C RTL. We don't protect these
wrappers with an additional API layer but just promise that these
structures won't change in maintenance releases (except by additions
at the end).