This was previously covered in Class::MOP and MOP.dll. To build a binary for 5.8.x, you need to build it against 5.8.0. Within a given 5.x, newer versions don't break compatibility with older binaries, but newer binaries are not necessarily compatible with older versions of Perl. | [reply] |
That's a misstatement. 5.8.x has only tried to maintain one kind of backwards compatibility: that modules built with older versions continue to run with newer perl versions. Having modules built with newer perls be usable on older perls has never been a goal, so I don't think you can call it breaking binary comptibility.
| [reply] |
Thanks. I just discovered that if I get GD v2.41 from Bribes (instead of Winnipeg) is works fine here, so I guess it depends which version of Perl was used when it was built?
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
it depends which version of Perl was used when it was built?
Yep - if the ppm is built with perl-5.8.0, then there's no problem. But if the ppm is built with perl-5.8.x (where x is non-zero), then it may not work with anything other than perl-5.8.x.
Cheers,
Rob
| [reply] |
I first learned Perl using the ActiveState distribution with Windows. That being said, ActiveState Perl can be pain to manage outside of the default environment. PPM's are not built/updated regularly which means you have always have these quirky issues installing modules and keeping up with dependencies.
I wish that Microsoft would include a decent C compiler like *NIX systems and this sh*t would just go away( I am not talking about that nmake.exe crap either).
Sorry about my off-topic rant, but sometimes Windows can be more trouble that it is worth.
| [reply] |