Re: Plan B for fixing 5.8.2 binary API

[Jan Dubois <jand@ActiveState.com>]

On Mon, 13 Oct 2003 12:12:32 -0400, Chip Salzenberg <chip@debian.org>
wrote:

>Advantages:
>
>  * Maintains full hash seed functionality w/o risky new algorithms.
>  * Achieves binary compatibility back to 5.8.0.
>  * Whatever speed penalty exists is cured with a simple recompilation.
>
>Disadvantages:
>
>  * Crufty code hack.  (Nothing new to Perl of course.)
>  * Speed penalty for the few XS modules that use PERL_HASH() and
>    which will not have been recompiled with 5.8.2.
>
>Comments?

I just changed our build scripts to compile ActivePerl based on 5.8.1 with
-DNO_HASH_SEED to avoid the binary compatibility breakage.

For ActivePerl, binary compatibility is even more restrictive: I also care
about forward compatibility, compiling modules with 5.8.1 and having them
work with 5.8.0.  The reason for this is our PPM repository, which is
essentially a CPAN mirror containing pre-compiled modules.

I want to be able to move the build processes to 5.8.1+ to be able to
compile modules that require 5.8.1+ in their XS code (e.g. use the new
thread hook stuff).  But those that don't need 5.8.1 should still be
installable into 5.8.0 because there is only a single repository for all
of 5.8.x.  This won't work if the 5.8.1 headers redefine standard
functions as macros to new APIs because the dynamic loader will not find
those when loading into 5.8.0.

Therefore I could implement plan A for ActivePerl based on 5.8.1+, but
plan B would still have to wait for ActivePerl based on 5.10.

Cheers,
-Jan