macOS system perl on 10.15+ doesn't allow loading relative paths (from MM_Any.pm)

[nieder]

EU:MM sets INST_ARCHLIB as a relative path, which breaks with the 'latest' release of perl (5.18.4) included with macOS 10.15.

ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm

Line 1915 in 278e457

$self->{INST_ARCHLIB} ||= $self->catdir($Curdir,"blib","arch");

An example failure is this:

cc  -I/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE -bundle -undefined dynamic_lookup -fstack-protector  ReadKey.o  -o blib/arch/auto/Term/ReadKey/ReadKey.bundle  \
	      \
	  
chmod 755 blib/arch/auto/Term/ReadKey/ReadKey.bundle
"/usr/bin/arch" -x86_64 perl5.18 "-Iblib/arch" "-Iblib/lib" ReadKey_pm.PL ReadKey.pm 
Creating ReadKey.pm
Can't load 'blib/arch/auto/Term/ReadKey/ReadKey.bundle' for module Term::ReadKey: dlopen(blib/arch/auto/Term/ReadKey/ReadKey.bundle, 1): no suitable image found.  Did find:
	file system relative paths not allowed in hardened programs at /System/Library/Perl/5.18/darwin-thread-multi-2level/DynaLoader.pm line 194.
 at /System/Library/Perl/5.18/darwin-thread-multi-2level/DynaLoader.pm line 98.
	DynaLoader::croak('Can\'t load \'blib/arch/auto/Term/ReadKey/ReadKey.bundle\' fo...') called at /System/Library/Perl/5.18/darwin-thread-multi-2level/DynaLoader.pm line 194
	DynaLoader::bootstrap('Term::ReadKey') called at ReadKey_pm.PL line 515
Bootstrapping the XS for blockoptions: make: *** [ReadKey.pm] Error 255

In the snippet above from MM_Any.pm, if I change $Curdir to the absolute path above 'blib/arch' in my build tree for Term::ReadKey, then Term::ReadKey builds.

Should EU::MM be patched to provide the full path? If not, is there a local hack I can use to change $Curdir to the full path?

[skaji]

Indeed.

I also noticed that, at runtime, relative paths for include directories did not work.

❯ curl -fsSL https://cpanmin.us | /usr/bin/perl - -Llocal -nq Text::CSV_XS
Successfully installed Text-CSV_XS-1.41
1 distribution installed

❯ /usr/bin/perl -Ilocal/lib/perl5 -MText::CSV_XS -e1
Can't load 'local/lib/perl5/darwin-thread-multi-2level/auto/Text/CSV_XS/CSV_XS.bundle' for module Text::CSV_XS: dlopen(local/lib/perl5/darwin-thread-multi-2level/auto/Text/CSV_XS/CSV_XS.bundle, 1): no suitable image found.  Did find:
	file system relative paths not allowed in hardened programs at /System/Library/Perl/5.18/XSLoader.pm line 71.
 at local/lib/perl5/darwin-thread-multi-2level/Text/CSV_XS.pm line 32.
Compilation failed in require.
BEGIN failed--compilation aborted.

[davehodg]

I'm having this problem too.

perl-5.30
MacOS: 11.4

[davehodg]

Are we anywhere near a resolution for this? It's killing me developing on a Mac.

[bingos]

I, personally, don't have a Mac to do any debugging/testing on, so rely on willing victims^W volunteers to provide the many fixes that Apple have made necessary in the last few years.

If that line in ExtUtils::MM_Any in sub init_INST {} is changed to the following does it do the right thing?

$self->{INST_ARCHLIB} ||= $self->catdir( __PACKAGE__->rel2abs($Curdir),"blib","arch");

I get two failures in EUMM test suite with the above that are easy to mitigate, so this is a possible low-hanging fruit fix.

[davehodg]

Balls. perlbrew here I come.

% ls -l /System/Library/Perl/5.30/ExtUtils/MM_Any.pm
-rw-r--r--  1 root  wheel  82753  1 Jan  2020 /System/Library/Perl/5.30/ExtUtils/MM_Any.pm
% chmod a+rw  /System/Library/Perl/5.30/ExtUtils/MM_Any.pm 
chmod: Unable to change file mode on /System/Library/Perl/5.30/ExtUtils/MM_Any.pm: Operation not permitted

[nieder]

This is the patch the Fink project has been currently using when we package our own perlmods to use against the system-perl:

-    $self->{INST_ARCHLIB} ||= $self->catdir($Curdir,"blib","arch");
+    $self->{INST_ARCHLIB} ||= $self->catdir(File::Spec->rel2abs($Curdir),"blib","arch");

I just tested using __PACKAGE__->rel2abs instead of File::Spec->rel2abs as suggested, and the successful build log for an affected perlmod is the same with either change.

[Leont]

I don't think it's INST_ARCHLIB we should change, but PERLRUNINST and friends