MAC Perl EXTERN.H Make Issues

[localshop]

Trying to use the system Perl on a new Mac Mojave I had some difficulty getting a XML::LibXML module installed from CPAN module but eventually got it working about a week ago. I remember using brew to install the LIBXML2 libs and fiddling with the paths in a few different ways as well as running a few xcode commands to ensure everything at that end was ok.

Step forward a couple of weeks and I come into the same error when trying to install URL::Encode::XS and figured that I should remember enough to get it build but a few hours later I'm still bumbling about.

I'm guessing that one solution is to use a perlbrew Perl build which should help get around the hard access limits to some of the restricted mac directories ( eg /usr/bin etc ) and I kicked things off down this path but I would still like to understand more about why XS modules are so problematic on MacOSX and have some idea of what is required to work around the system constraints.

Secondly, I'd like to be more confident about the best environment for Perl development on a Mac - do most people step away from the system Perl and use Perlbrew or is there an approach or bunch of knowledge that will allow me to work with system Perl and still be able to build modules with Library dependencies?

NB - Cross post in Stack Overflow Answer

To summarise my findings based on responses here etc the best practice would seem to be:

• Don't use the System Perl on Mac OSX if you require any modules
• do a brew install perl
• then do brew install cpanminus
• then install perlbrew to allow multiple perl setups

If I've missed anything in my findings update let me know so that I can refer ppl here with more confidence.

[Corion]

The system Perl on OSX will be updated/reverted by Apple whenever they want.

While developping WWW::Mechanize::Chrome and getting it to install on OSX, I found that using a Perl provided/compiled by homebrew worked "best" in the sense that the libraries and packages provided by homebrew work together with the Perl provided by homebrew and CPAN.

In my case, Imager::PNG would not compile+install with the system Perl, but does so flawlessly with homebrew.

[1nickt]

Hi, Perlbrew is the *only* way to go!

First, do *not* use the system Perl on MacOS. As Corion says, that is for Apple, not for you. Second, installing with homebrew is all well and good, but what about when you want to test with a different Perl? This is not just a theoretical. I frequently switch Perls, sometimes between versions to test back compatibility, but also because I keep different library collections within the same version. E.g., I have a Perl installation that only ever has the same libraries installed from the same PINTO as our production servers do, but I spend most of my time developing with another Perl installation (of the same version) where I install modules freely, to experiment, run some debug stuff, or whatever.

I've been developing on a Mac for a long time now, as do all my coworkers for the last several years. All use Perlbrew.

Hope this helps!

[tangent]

I use perlbrew for Perl, and I use Homebrew to install external libraries. The key thing I learnt when setting this up was to modify my .profile file - it currently looks like this:

source ~/perl5/perlbrew/etc/bashrc
export PATH="/usr/local/opt/libxml2/bin:$PATH"
export PATH=/usr/local/bin:/usr/local/sbin:~/bin:$PATH

The first line means that when I fire up perl in the terminal it will use the current perlbrew version of Perl, which also means that cpan will install modules in the correct location for that Perl.

The second line I think is a hangover from MacPorts and you probably don't need it.

The third line ensures that Perl can find external libraries installed by Homebrew - I have seen different configurations posted but this one has always worked for me.

[Your Mother]

And for posterity and the record: MacPerl is not Perl. They are not mixable and it’s a bad idea to use the term unless you’re talking about the actual port: http://wiki.c2.com/?MacPerl. OS X Perl is just Perl. MacPerl is/was for OS 9 and friends. The installation issues on Macs today—excepting those revolving around C-libs for things like images, as Corion noted—are the same across almost all OSes that run Perl.

[localshop]

I've found the OSX system Perl more restrictive than most in that even as root you are unable to write to /usr/bin and similar trees which makes the binding of external libraries significantly more problematic.

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.

[stevieb]

"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.

[Your Mother]

…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.