As <<syphilis>> said:

I notice that XS_VERSION_BOOTCHECK has changed since perl-5.18 and no longer directly calls STR_WITH_LEN.

If I were you I would upgrade my perl and never think about it again.

In OSX something that really works for me well is:

1. perlbrew (note Homebrew and perlbrew are not the same thing, perlbrew allows you to select which version of perl to use and also downloads, installs and uses any version of perl you instruct it to),
2. cpanm for installing perl modules,
3. important: if using perlbrew, shebang should now be: #!/usr/bin/env perl

#1 makes a lot of difference and definetely pokes a wooden pole in the chest of apple's perl.

glad you found a solution.

Hello bliako,

Perlbrew is cool! I tried it and it worked, right out of the box to build 5.20.3. First time I've built Perl from sources and it is amazing. I initially got two failed tests in Memoize but I believe the tests failed due to a time out. I found the failed tests and ran their .t file manually and they passed. Just to be sure, I ran all the tests for that module with a find command with -exec to have perl read all of the test files in that directory and all passed, so I forced the install of 5.20.3.

However, I can't totally give up on installing PerlIO::Layers in the native perl that ships with High Sierra, as others may be struggling with this too. The problem is that 'version' is defined in only one place and is used to initialize both the .pm file and the .o file by way of compiler -D macros. Setting it for the compiler hoses the .pm and setting it for the module causes the compiler to choke. There is no way to set XS_VERSION and VERSION manually, only indirectly by way of 'dist_version'. Therefore, the automated build/test process is broken. ExtUtils::CBuilder::Base sets compiler -D macros with this fragment of perl I modified:

#!/usr/bin/env perl -w
##!/usr/bin/env perl -wd

use strict;
use Data::Dumper;

$Data::Dumper::Purity = 1;

my %args = (
    XS_VERSION => '\'"0.011"\'',
    VERSION    => '\'"0.011"\'',
);

print arg_defines(%args), "\n";

exit 0;

sub arg_defines {
  my (%args) = @_;
#  my ($self, %args) = @_;
  return map "-D$_=$args{$_}", keys %args;
}
__END__
[download]

which when run yields:

$ macro-D.pl
-DXS_VERSION='"0.011"'-DVERSION='"0.011"'
[download]

Data::Dumper is syntactic sugar for when I run in Perl's debugger. Whenever anything like these strings is set in 'dist_version', the build fails and 00-compile.t fails.

To manually build the module and its shared library do: ./Build clean and then ./Build and extract the two cc commands, one to compile and one to link in the bundle, run them manually and all will be well. With this work-around I was able to do what triggered this thread, namely, build PDL.

So, it isn't absolutely necessary in macOS High Sierra to resort to perlbrew but it is a whole lot easier. I am a hacker at heart but I suspect most mac users are not.

That's great perlboy_emeritus

As you previously said, it looks like apple prefers to keep their perl (and cc and and and) untouched, frozen (and they have good reasons from their point of view - compare this with open source OSs and how often their perl or cc upgrades).

On the one hand, they probably don't want the system to break with any new addition or upgrade to their perl.

On the other, it is they who insist users should upgrade their OS (I will do it if you guarantee my systems will not break) and when they don't, users find themselves they live in the caves with all these messages 'this program needs at least OSX so and so'. cf skype

So, great! but keep an ear for any cling-clang noises coming from the engine room, you don't want to break other things down there with this hack.

bw

bliako

For Perl on MacOS I use the Homebrew version with a local::lib, which works great.

Rats! I am now running Perl 5.26.1 in Homebrew and building PerlIO::Layers is still broken, only at this point my work-around of editing version => '0.011' expressions and making them "0.011" (three places, *.yml files and ./_build/build_params) and then doing perl ./Build.PL, ./Build and Build test does not yield a shared object. Indeed, Layers.o in this latest build is a file size = 5048 bytes while the one I built using that work-around with Perl 5.18.2 is size = 92676 bytes. The 00.compile.t test fails even though there is a Layers.o file in ../lib. That test uses -Mblib to find the shared object, which obviously isn't a loadable object. And as was noted, XS_VERSION_BOOTCHECK does not appear to be invoked, which means now there is some other reason why the module will not build. Back to the drawing board...

And as was noted, XS_VERSION_BOOTCHECK does not appear to be invoked

But if XS_VERSION is being defined in the command line (and I gather that is still happening here), then XS_VERSION_BOOTCHECK should be invoked.
It's just that STR_WITH_LEN no longer gets called directly by XS_VERSION_BOOTCHECK.

Cheers,
Rob