On Sun, Sep 05, 2010 at 05:17:45PM -0700, Darren Duncan wrote: > Okay, I'm not sure I understand the problem here. > > I thought that the point of PERL_POLLUTE was to provide things that > were removed from the Perl core so that code which depends on the > old removed APIs would continue to work with newer Perls that > removed them if said code enables PERL_POLLUTE.
PL_sv_undef, for example, used to be called just sv_undef many years ago. When it was decided to to add the PL_ prefix the PERL_POLLUTE #define was added as a way for old code to keep working without changes. It does #define sv_undef PL_sv_undef etc etc. Perl 5.13.4+ removes that mechanism and those #defines so code still using the non-prefixed names will break. > DBD::SQLite *does* define PERL_POLLUTE, but if I take it out, then > it still builds fine otherwise as-is on Perl 5.13.4 with DBI > 1.613_71. So DBD::SQLite already appears to use the newer PL_ > versions, so hence what is PERL_POLLUTE for? Looks like DBD::SQLite doesn't need it. That's good. > I found that under Perl 5.12.1, just removing PERL_POLLUTE caused > build failures, which cited old versions without the PL_, but then I > found that these old versions weren't in the DBD::SQLite source at > all, but rather were being added by ppport.h. So then when I also > removed ppport.h (and PERL_POLLUTE), then DBD::SQLite built with > Perl 5.12.1 and DBI 1.613_71. Okay. If your ppport.h isn't recent that may suggest a bug in ppport.h. > So, in light of this, should I actually be changing anything in > DBD::SQLite? Or should it be retaining both the PERL_POLLUTE and > ppport.h? You can remove PERL_POLLUTE. ppport.h has other uses and should be kept. (Though ppport.h can tell you that for itself when you run in on the code.) > You seemed to be saying that including PERL_POLLUTE means broken on > Perl 5.13.4 but that doesn't seem to be the case. No, including PERL_POLLUTE simply becomes ineffective on 5.13.4+. So _if_ your driver _needed_ PERL_POLLUTE then it'll fail on 5.13.4+. Tim.
