Re: PerlIO::Layers 0.011 fails to build in macOS 10.13.3

It's rather odd.
AFAICT, the XS_VERSION_BOOTCHECK macro (in XSUB.h) is the same for all systems, as is also the case for the STR_WITH_LEN macro (in handy.h). And both macros are correctly stated in the output you provided.

If it were me, I'd try removing the -DXS_VERSION="0.011" argument from the command that's producing the error.
I don't know if that will allow the build to succeed, but I do know that it will avoid the error you're getting (because XS_VERSION_BOOTCHECK is a noop if XS_VERSION is not defined).

AIUI, defining XS_VERSION to VERSION allows a mismatch of XS component and Perl component to be detected at boot. Otherwise, such a mismatch will lead to confusing runtime errors or crashes.
So, if my suggested approach does succeed, you lose the re-assurance of that check at boot.

<afterthought>
Given the nature of this error, I'm thinking it should occur every time you build a module that defines XS_VERSION prior to the inclusion of XSUB.h (which is what is happening here).
I don't think there are a lot of modules that do that, though I haven't checked on that. (Correction ... seems to be defined for modules containing XS files.)
I notice that XS_VERSION_BOOTCHECK has changed since perl-5.18 and no longer directly calls STR_WITH_LEN.
Perhaps this means that updating to perl 5.26 would avoid the issue you've struck.
</afterthought>

Cheers,
Rob

Comment on Re: PerlIO::Layers 0.011 fails to build in macOS 10.13.3 Download Code

Replies are listed 'Best First'.

Re^2: PerlIO::Layers 0.011 fails to build in macOS 10.13.3
by perlboy_emeritus (Scribe) on Mar 26, 2018 at 16:32 UTC

https://groups.google.com/forum/#!msg/perl.perl5.porters/mKhKYbPqrmQ/2Z7rAsyJOsMJ

Notice Hafen McCormick's reference to a 'diagnostic wrapper', presumably a Perl shared library built from an .xs file that would appear to have shipped with the writer's Perl distro from Apple. That wrapper may be mangling the output from the STR_WITH_LEN macro. I am giving up on Perl from Apple, especially in High Sierra, given the huge number of bugs reported by HS users, particularly the almost totally broken backward support for USB 3.0. For example, I have an On-The-Go external enclosure I use to clone/backup my mac with Carbon Copy Cloner. I can clone to a drive in that enclosure but I can't boot from it. If my internal SSD were to fail, I could move the drive from the enclosure to inside the mac and boot from it while waiting for a replacement SSD. Then, clone to the SSD in the enclosure and reverse the process. Apple has yet to respond to my bug report or to the numerous others from USB 3.0 users whose backups are hosed. No point in shopping for/buying a new enclosure since all with firmware prior to High Sierra are probably broken and their seller's don't know it and/or can't or won't certify it as bootable. But I digress...

I looked at several Perls I have access to and as you reported, all have identical XSUB.h and handy.h headers, at least as they relate to macro XS_VERSION_BOOTCHECK, which means the problem must be something either compiled into my Perl or a shared library.

Damn, something just occurred to me. Apple does not want macOS users to install additional bits in Apple protected directories, where Perl is installed, so, deliberately hosing the XSUB build process is one way to do that, and then ignore all bug reports related to it. Even Apple recommends installing Perl with brew. I am not a conspiracy theorist but dealing with Apple has made me very paranoid :-(

[reply]


Keep It Simple, Stupid
	PerlMonks