A bit of investigation from one of the few logs I did get back from
On Feb 11, 2008, at 7:16 PM, Rachel Blackman wrote:
> I did not have time to track down the cause before I was completely
> eaten alive by work, especially as I have no access to a Panther
> machine to test on (which, well, makes the testing process a bit
> hard)! So while my 1.1.0 attempt worked on Leopard, it broke
> backwards compatibility with Panther utterly.
Panther users leads me to think the issue is that the symbols just
utterly fail to resolve... something's very wrong in the compile
settings for that situation.
I finally got a Panther partition set up on my old G4 and tested this using ShuX, and that's the problem exactly. The framework "stub" chooses the correct platform and Perl version, and loads the correct support bundle. Then, when main.pm
uses CamelBones.pm, which in turn loads the CamelBones.bundle in the Perl module - the one that's built from CamelBones.xs - that's when the undefined symbols happen. There are complaints in the console log that symbols referenced in CamelBones.bundle aren't being found.
I tried adjusting the project settings, Perl SDK for Panther, and the Makefile.PL, so that the Panther build uses GCC 3.3 - which made no difference. I didn't think it would. If I remember the technote correctly, GCC 3.3 is only required if you use C++ and need to support Panther systems that are still on 10.3.8 or older. If you're not using C++, or you are using it and you can require the latest 10.3.9 patch, then GCC 4 should work for Panther.
I tried tweaking some other things too, with no better results.
My next step is to download the old makefile-using version, build it, and compare the build logs to see what's different. While I'm there, I'll also test the built product to verify that this is really a new problem resulting from the switch to Xcode. I truly hope it is, because otherwise we won't have a known-working base against which to compare, which will make diagnosing the problem just that much more difficult...