rschupp / PAR-Packer

(perl) Generate stand-alone executables, perl scripts and PAR files https://metacpan.org/pod/PAR::Packer
Other
48 stars 13 forks source link

t/90-gh66.t fails on M1 Mac #68

Closed shawnlaffan closed 1 year ago

shawnlaffan commented 1 year ago

This is with perl 5.36.0 via perlbrew, running on an M1 Mac.

t/90-gh66.t .............. 6/10 
#   Failed test 'successfully ran "/var/folders/pt/h6h_6z6x5w75jzcd65r_s7zw0000gq/T/teXUNUyait/packed"'
#   at ./t/utils.pl line 39.
#          got: '9'
#     expected: '0'
Use of uninitialized value $_[0] in substitution (s///) at /Users/user/perl5/perlbrew/perls/perl-5.36.0/lib/5.36.0/File/Basename.pm line 341.
fileparse(): need a valid pathname at t/90-gh66.t line 27.
# Looks like your test exited with 25 just after 7.

Possibly the fix for #66 is incomplete.

Please let me know what other debugging steps are needed.

rschupp commented 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
shawnlaffan commented 1 year ago

The job is killed.

./should-clean 
zsh: killed     ./should-clean
shawnlaffan commented 1 year ago

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
rschupp commented 1 year ago

Are all executables on MacOS signed nowadays? Can you try the following experiment:

shawnlaffan commented 1 year ago

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.

shawnlaffan commented 1 year ago

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.

rschupp commented 1 year ago

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"?

shawnlaffan commented 1 year ago

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.

rschupp commented 1 year ago

@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?

plk commented 1 year ago

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.

shawnlaffan commented 1 year ago

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.

rschupp commented 1 year ago

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