C:\_32\C>type try.c

#include <stdio.h>

int main (void) {
#define FOO(s) printf("%s\n", "" s "");
 FOO(VER);

 return 0;
}

C:\_32\C>gcc -o try.exe -DVER="\"0.1\"" try.c

C:\_32\C>try
0.1

C:\_32\C>gcc -o try.exe -DVER=0.1 try.c
try.c: In function 'main':
try.c:5:2: error: expected ')' before numeric constant
[download]

with your little c-program:

gcc -DVER="0.1" -E try.c

does the preprocessor pass and expands FOO to:

printf("%s\n", "" 0.1 "")
[download]

and

gcc -DVER="\"0.1\"" -E try.c

expands it to:

printf("%s\n", "" "0.1" "")
[download]

so, whereas

printf("%s\n", 0.1)
[download]

would have caused just a warning at compile time and a crash later,

printf("%s\n", "" 0.1 "")
[download]

causes an error right away

and

printf("%s\n", "" "0.1" "")
[download]

is legitimate.

bliako

printf("%s\n", "" "0.1" "") didn't immediately look like valid C to me (and it's not valid perl).
But C does allow that type of concatenation - whereas I guess perl doesn't really need to.
Even in assignment one can do char *x = "hello" "0.01" "world";

Cheers,
Rob

    'dist_abstract' => 'Querying your filehandle\'s capabilities',
    'dist_version' => '0.011',
    'build_bat' => 0,
    'dynamic_config' => 1,
    'c_source' => undef,
    'extra_compiler_flags' => [],
    'verbose' => undef,
    'build_class' => 'Module::Build',
    'quiet' => undef,
    'install_sets' => {},
    'use_rcfile' => 1,
    '_added_to_INC' => [
      '/Users/carly/perl5/lib/perl5/5.18.2/darwin-thread-multi-2level'
+,
      '/Users/carly/perl5/lib/perl5/5.18.2',
      '/Users/carly/perl5/lib/perl5/darwin-thread-multi-2level',
      '/Users/carly/perl5/lib/perl5',
      '/Users/carly/src/perl5/lib'
    ],
[download]

# This should have just enough arguments to be able to bootstrap the r
+est.
my $build = Module::Build->resume (
  properties => {
    config_dir => '_build',
    orig_dir => $orig_dir,
  },
);

$build->dispatch;
[download]

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.

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