Fair enough - the breakage was something that will likely strike you as obvious once you see it: going from 5.8.8 to 5.10.1 - that's not a binary-compatible version change. As I seem to recall, this was one of the biggest binary breakages p5p has ever done, but size doesn't really matter - any breakage is a breakage. Obviously, pure-perl code wasn't impacted, other than the change from 5.8 to 5.10 itself (yay, can now use state variables! -- but I didn't encounter anything significant here), it's the XS code, such as DBD::DB2, as you pointed out. We needed DBI, DBD::DB2, JSON::XS, and various other XS modules, so these got hit. Originally, TPTB wanted to use the same AIX 6 box for compiling both versions of our product, but this forced their hand - we had to get an AIX 7 system to compile.
In addition, we were installing the CPAN modules to the site directory, which, again, changes from 5.8.8 to 5.10.1. If we installed the 5.8.8-compiled XS modules to the 5.8.8 directory on AIX 7, perl 5.10.1 on AIX 7 simply won't see them. If you're installing to a local lib directory, that's not an issue.
So, basically, we had to compile on both AIX 6 (against 5.8.8) and AIX 7 (against 5.10.1) to get our modules working in both places. Going with our own private perl in the future, we could compile the whole stack on an AIX 6 box and use it on both AIX 6 and AIX 7.
So, really, there was nothing here that was unique to AIX per se. Going from RHEL 5 to RHEL 6, for example, could have basically the same issues. It's pretty much all just the fact that we're installing CPAN modules to the system perl pre-compiled and automatically, without any compiler being on the target system.
| [reply] |
| [reply] |