#1 Perl Versions / Locations

[Jon Wright]

I have a customised perl installed:

[jgw@localhost Perl]$ perl -v
This is perl, v5.7.3 built for darwin-64int

As a result when building the example code I get an error:
/usr/bin/ld: warning can't open dynamic library: /System/Library/Perl/darwin/CORE/libperl.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2)

Work around:
sudo ln -s /System/Library/Perl/darwin-64int \ /System/Library/Perl/darwin

Better Solution:
Get CamelBones to identify the location of libperl.dylib by asking Perl instead of hard coding?

[Sherm Pendley]

Logged In: YES
user_id=473550

DynaLoader.a is linked statically, so unless it works with the installed libperl, you'll have trouble loading modules that have an XS component.

It shouldn't be too difficult to identify the Perl being used when the framework is being compiled. At runtime, the framework would still require whatever version of libperl it was linked against, though.

I've a hunch that anyone who's gone to the trouble of building and installing a custom Perl probably won't be bothered much, if they need to compile CamelBones from source as well. In my experience, when you're using bleeding-edge libraries, having to compile applications from source kind of goes with the territory.

[Finlay Dobbie]

Logged In: YES
user_id=142892

Not really possible since it's a link-time decision.

[Sherm Pendley]

Logged In: YES
user_id=473550

The latest version of the installer detects the standard Apple-supplied
Perls, and building from source is much simplified by the use of GNUStep
make file macros instead of PB/Xcode. Until the Perl maintainers find a
way to maintain binary compatibility for libperl - I'm not holding my
breath - I consider this issue closed.