search

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

rs6000_71 (AIX) "Not a typewriter" #64

Closed GlennWood closed 2 years ago

GlennWood commented 2 years ago

Thank you for the fix of "bad-header", #62; that was quite a head-scratcher for me.

With this PAR-Packer-1.055 on rs6000_71 (AIX), it seems to have created a new issue. Note: this does not happen in all our build-environments, so there's something here that is probably quite specific to our usage!

I get this in our test-build:

Failed to execute temporary parl (class PAR::StrippedPARL::Static) '/tmp/parlbrxH': $?=10 at /net/dsnetapp11svm01/sandboxes/---/rs6000_71/lib/perl5/PAR/StrippedPARL/Base.pm line 77,  line 1.
/net/dsnetapp11svm01/sandboxes/---/rs6000_71/bin/pp: Failed to extract a parl from 'PAR::StrippedPARL::Static' to file '/tmp/parlaOQzkJk' at /net/dsnetapp11svm01/sandboxes/---rs6000_71/lib/perl5/PAR/Packer.pm line 1216,  line 1.

Earlier I hacked your fix-pp-clean branch to log some information about the temporary file that is being executed here. The properties fo that file were:

-rwxr-xr-x    1 gwood    minstaff   10199068 Jul  2 18:48 /tmp/parlvQ2R

and that logging also reported:

Failed to execute temporary parl (class PAR::StrippedPARL::Static) in file '/tmp/parlvQ2R': Not a typewriter at /home/gwood/sandbox/---/rs6000_71/lib/perl5/PAR/StrippedPARL/Base.pm line 109, <DATA> line 1.
/home/gwood/sandbox/---/rs6000_71/bin/pp: Failed to extract a parl from 'PAR::StrippedPARL::Static' to file '/tmp/parlG3l3rWS' at /home/gwood/---rs6000_71/lib/perl5/PAR/Packer.pm line 1216, <DATA> line 1.

It runs successfully every time in my dev-build environment, and fails every time in our test-build environment.

My speculation is that the {Dynamic,Static}.pm file that /tmp/parlvQ2R is derived from has some operation built into it at PAR-Packer install-time that causes "Not a typewriter", or that something in test-build declares "Not a typewriter" which "Is a typewriter" in dev-build. Would you give me help to locate how {Dynamic,Static}.pm is generated so I can insert some logging? I am quite familiar with the C language, but could use some help finding where to start.

rschupp commented 2 years ago

Don't get hung up on the "Not a typewriter": the error occurs if the call of system() fails and the reason is given in $? (cf. perldoc -f system) and not in $!. $! is the error code of the most recently failed system call (that is "system call" on the C level), so it might be totally unrelated to system() failing. Also this error code is not cleared by any later successful system call. Under the hood system() will at least go thru the following system calls: fork, execve and wait, probably others. In your case, $? is 10, which means that the executable /tmp/parlvQ2R could indeed be executed, but was killed (without any message) by signal 10 (since signal numbers are OS-specific, you'll have to look up what that means on AIX). Anyway, the system calls above where all successful, so ENOTTY ("Not a typewriter") could be caused by perl simply checking some file descriptors using an ioctl only appropriate for a tty. It's probably not even perl, but the C library, if you look at system call traces of any random program, you'll see this error at lot.

Back to the real problem: since you captured /tmp/parlvQ2R, what happens if you try to execute it (esp. in the test-build environment)? Perhaps /tmp in the test-build environment is mounted with noexec? Actually this file should be a copy of myldr/boot (in PAR::Packer's build directory).

GlennWood commented 2 years ago

After a week of trying just about everything, I've stumbled across one thing that actually works - a nice on the system() call of myldr/run_with_inc.pl Yeah, I know; who'da thunk it?

Anyway, this magical fix is required on only one of our build-hosts, on only one of our platforms, for only one of our products; so I don't think it requires any action on your part. Thank you for your help!

Please close this issue.

rschupp commented 2 years ago

After a week of trying just about everything, I've stumbled across one thing that actually works - a nice on the system() call of myldr/run_with_inc.pl Yeah, I know; who'da thunk it?

Whatever it takes... Thanks for following up.