Perl Tests that rely on $Config{perlpath} are failing when calling system() to execute sub-tasks

[pattieja1]

While trying to install perl modules inside of a version of perl (5.38.0) built by App::MechaCPAN (0.29) that is now setting the ./Configure -Dperlpath parameter as /usr/bin/env perl and the modules test files do something like

system($Config{perlpath}, "param1", "param2", "-e", "script to test");

The code is failing with file not found.

I was able to find a version that "works" manually by doing system("/usr/bin/env", "perl", "-v"); as a test and that does work but I don't know how to put that in the perlpath variable that would work as expected (it would need to spit out 2 list entries in the system call).

For these perl modules I end up telling it to --skip-tests so I can get the code installed.

Wouldn't it make more sense to put the full path to the perl interpreter that was being built in perlpath or are you trying to allow the built perl to be moved and still work? In my case it will never be moved as the path is baked into my code, etc.

Module Devel::Checklib was the package I ended up digging into to try and figure out why this keeps happening. It's not anything I created or directly need, it's a sub-dependency of the Dancer2::Session::Cookie module that I was installing.

Thankfully not that many modules appear to be doing these system calls but I've run into a handful.

[pattieja1]

Looking back through releases, it appears this change was made in 0.27. I primarily did most of my initial development and testing w/ App::MechaCPAN up to 0.26 which didn't have the problem. :)

[atrodo]

I suspect that you're running into an issue with a new 0.29 feature that will attempt to pull a pre-built binary. Those binaries are built as relocatable, specifically with the -Duserelocatableinc configure option. This does a couple things, including setting startperl and perlpath to use /usr/bin/env perl. This is done because relocatable perls become significantly less useful if the path to perl in shebang lines are hard-coded to the path it was built with.

The documentation for perlpath says it is "the name of the perl interpreter to be used in shell scripts and in the "eval "exec"" idiom", that is its purpose is for shell scripts, not for execution of perl itself, $^X is more robust for that as it honors the relocatable nature of a perl built to be relocatable.

That said, perls built from source should not have this issue; the decision there is not to build a relocatable binary as the expectation is that it will not be moved from the installed directory. In 0.29, to get that behavior you will need to add the --source-only flag. As of right now, I am expecting 0.30 to stop making the default to pull the prebuilt binaries while I continue to test them, but they will become the default in a future version again.

[pattieja1]

Hi. Thanks for responding.

I'm having to specify --build-reusable to get perl to build from source and not try to download one of your pre-built binaries. I didn't see the --source-only flag while initially troubleshooting the perl build failures in the POD documentation (and it still isn't an option listed). Would I add it in addition to --build-reusable or instead of?

My current Dockerfile is doing the following to get perl built and installed:

RUN MECHACPAN_TIMEOUT=300 mechacpan perl --threads --skip-tests --build-reusable 5.38
RUN MECHACPAN_TIMEOUT=300 mechacpan perl --threads perl-v5.38.*

Not 100% sure I needed the --threads in the second call but figured it wouldn't hurt. :) Prior to version 0.29, I just had the one call without the --build-reusable option specified.

Regarding the unit tests that are referencing $Config{perlpath} as the command to system(), are you suggesting as we encounter a perl module that is doing this, we open a bug with them to tell them to instead use $^X in the system() call?

Thanks

[atrodo]

The --source-only option would be a replacement to --build-reusable, the latter is meant to build a perl that can be used multiple times in different installations to save time. It sounds like that's not a goal of yours, so using source-only would be recommended. You are correct that the documentation doesn't mention that option, I had forgotten that the docs were lacking. 0.30 will include more and better docs.

As for perlpath, it looks like the answer is more complicated than I originally thought. After doing some research, it appears that perlvar actually has some recommendations that suggest using perlpath, but I suspect that recommendation was made before or in spite of the complication of relocatable perls. I was originally thinking of giving you that suggestion, opening bugs about using $^X, but at this point I am unsure so I am going to do some more research and testing.

[pattieja1]

Switching over to --source-only has fixed the problems I'm seeing, as you surmised. Thanks for the pointer.

Do you want to close this ticket or leave it open so you can track the perlpath issue with using /usr/bin/env perl?

[atrodo]

Great to hear that it worked. 0.30 will document that option as well as the other changes add in 0.29. Note that the default behavior is changing in 0.30 to default to --source-only, but a future version will change the default back once I'm more confident that things are working as expected in more cases.

I plan to leave this ticket open for the short term for tracking the $^X vs $Config{perlpath} differences.