So I'm reading the Perl 5.10 release notes, and it says "The Perl installation is now
Progress is being made on that front.
I started by creating /experimental/static-libperl on SVN, and cloning /CamelBones into that. Never work without a net! :-)
More progress to report.
As is implied by the name of the branch dir, I was doing all of this with a static libperl.a. That approach turned out to have a flaw. The self tests were running perfectly through the initialization code, loading and initializing the XS, but the first call they made into the Perl API from the framework would bomb.
Turns out, there are two copies of libperl.a involved - one copied into the perl binary, and one into the framework. When the tests were running, they'd load the framework, which would bring its own libperl functions with it. The fun begins as soon as the framework tries to call one of its own libperl functions instead of the perl binary's.
I'm going to try a dynamic libperl.dylib. A new Perl build is building and testing while I type this. This should work - A script step can use install_name_tool to adjust the framework to point to an embedded path for
libperl.dylib, and a copy files step can place it there.