I'd always ended up installing another version on OSX and things would stabilise but I always felt a little dirty running multiple versions. Thanks for the advice - I now at least feel somewhat better informed and now also know not to write the system Perl as Mac Perl.

Another take-away for me was also that brew install perl != perlbrew. I think that spending a little more time exploring these on a new setup has given me a little more confidence as to what is going on. Next on the list is writing some local modules with C library bindings which is something I've always wanted to do but never got around to - while playing around this level and with a little time on my hands I think I'll have a crack.

Thanks for the advice.

"Next on the list is writing some local modules with C library bindings"

I've done this quite a few times.

My WiringPi::API might be a reasonable example for you to have a look at. The API.xs file contains a few custom C functions that are provided to Perl, as well as the list of the majority of functions that are accessed from the shared wiringPi library itself.

The API.pm Perl module file loads the XS file, and provides direct access to the C functions directly, and optionally presents the equivalent Perl wrappers (the software can be used in Object Oriented or functional style).

The Makefile.PL file, specifically the LIBS and INC directives show how to link in the shared libraries, and how to include your required files respectively.

…OSX system Perl more restrictive than most in that even as root you are unable to write to /usr/bin and similar trees…

moo@cow[93]/usr/bin>sudo touch monkey
Password: 🔑
touch: monkey: Operation not permitted

That’s very interesting… I don’t recall bumping up against that in the past. Nice call out.

System Integrity Protection