On Mon, Feb 11, 2008 at 10:33 PM, Rachel Blackman <seattlesparks@mac.com> wrote:

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.

A bit of investigation from one of the few logs I did get back from
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...

 A bit of poking also suggests that
libffi isn't compiling with support for Panther, which may be part of
the problem.

No, libffi is a static library - it's not going to have runtime symbol resolution problems like these. Additionally, the support bundle is the only place where libffi symbols are referenced from, and it loads correctly. The problem hits after that, when libperl tries to load the Perl module and resolve its external references to the public symbols in the framework dylib.

That said, I think it's a good idea to keep the FFI project's settings in line with those of the main project, so I'll change its deployment target anyway.