Closed shawnlaffan closed 1 year ago
What does the following print (the second test from t/90-gh66.t which exited with status 9)
perl -Mblib blib/script/pp -o should-clean --clean -e 'print qq[PAR_TEMP=$ENV{PAR_TEMP}\nPAR_CLEAN=$ENV{PAR_CLEAN}\n]'
./should_clean
The job is killed.
./should-clean
zsh: killed ./should-clean
Here is a dtruss call as an strace analogue in the event it is useful:
sudo dtruss -f -a -s -l ./should-clean
dtrace: system integrity protection is on, some features will not be available
PID/THRD RELATIVE ELAPSD CPU SYSCALL(args) = return
CALL COUNT
Are all executables on MacOS signed nowadays? Can you try the following experiment:
myldr
in your PAR::Packer
build area./boot
will run (it will print a usage message, but otherwise execute normally)perl -0077 -pe 's|__PASS_PAR_CLEAN__..|__PASS_PAR_CLEAN__=1|g' boot > boot.clean
chmod 755 boot.clean
./boot.clean
It's only the cleaning tests that are failing so I assume signing is not required for all executables.
I'll run those checks when I'm next in front of that machine, probably in a few days.
Building and running boot.clean
gives the same error as before. The dtruss
call is the same also.
Calling ./boot
gives the expected usage message.
Building and running boot.clean gives the same error as before. The dtruss call is the same also.
So the perl oneliner above patched 2 bytes in a static string (static char pass_par_clean[] = "__PASS_PAR_CLEAN__xxxxxxxxx\0"
) in boot
and apparently that rendered boot.clean
an invalid executable. Looks like the whole file is protected by some automagically added digest. (This patching is how a packed executable "remembers" that it was packed with --clean
.)
There's pp_osx_codesign_fix.c
in directory contrib/pp_osx_codesign_fix
. Can you compile that and run it over build.clean
with
cd myldr
gcc -std=c99 ../contrib/pp_osx_codesign_fix/pp_osx_codesign_fix.c -o pp_osx_codesign_fix
./pp_osx_codesign_fix build.clean
Does that make build.clean
"work"?
I ran pp_osx_codesign_fix.c
on both boot
and boot.clean
. Both jobs were killed in the same way.
I then edited boot.c to have __PASS_PAR_CLEAN__=1
and recompiled. The result is below, which might well be what is expected:
./boot
Usage: ./boot [ -Alib.par ] [ -Idir ] [ -Mmodule ] [ src.par ] [ program.pl ]
./boot [ -B|-b ] [-Ooutfile] src.par
Undefined subroutine &File::Find::finddepth called at -e line 36.
END failed--call queue aborted.
I also tested pp_osx_codesign_fix
with a normal packed executable (no --clean
argument) and it was killed in the same way.
@shawnlaffan Can you try HEAD from master on M1 Mac?
@plk Can you try HEAD from master on other MacOS platforms? Do pp
generated and then code-signed executables work? Does a variant of t/90-gh66.t work with code-signed executables work wrt --clean
or persistent cache area?
Using HEAD from master, all tests pass fine on MacOS x86_64. pp
created binary after running pp_osx_codesign_fix.c
works fine. I haven't checked an actually codesigned binary as someone else does that with biber
.
All tests pass on my M1 Mac.
PAR binaries built with this pp work.
PERL5LIB=$(pwd)/blib/lib:$(pwd)/blib/arch ./blib/script/pp -e 'print "# works\n"' -o a.out
PERL5LIB=$(pwd)/blib/lib:$(pwd)/blib/arch ./blib/script/pp -e 'print "# works\n"' --clean -o b.out
./a.out
# works
./b.out
# works
Both variants are killed ~when~ after being passed through pp_osx_codesign_fix
but that's likely a different issue.
@shawnlaffan @plk Thanks for testing! I've released a development version to CPAN to get more test coverage on other platforms, looks like Windows needs some more work.
This is with perl 5.36.0 via perlbrew, running on an M1 Mac.
Possibly the fix for #66 is incomplete.
Please let me know what other debugging steps are needed.