perlboy_emeritus has asked for the wisdom of the Perl Monks concerning the following question:

Hello Monks,

I try to upgrade perl once a year or so using perlbrew on macOS 12.7.2. My last was 5.36.1 in August 2023, a flawless build. Today I tried 5.38.2 to get the latest stable release with all the security fixes, and when that failed, tried 5.36.3, which also failed. Interestingly, both failed for exactly the same build steps, To wit:

Test Summary Report    perl 5.36.3
-------------------
op/magic.t                                     (Wstat: 0 Tests: 208 Failed: 10)
  Failed tests:  181-184, 186-187, 190, 193, 197, 199
Files=2767, Tests=1206617, 935 wallclock secs (65.29 usr 13.91 sys + 570.01 cusr 79.49 csys = 728.70 CPU)
Result: FAIL
make: *** test_harness Error 10
##### Brew Failed #####


Test Summary Report     perl 5.38.2
-------------------
op/magic.t                                     (Wstat: 0 Tests: 208 Failed: 10)
  Failed tests:  181-184, 186-187, 190, 193, 197, 199
Files=2767, Tests=1183648, 874 wallclock secs (61.53 usr 13.42 sys + 513.09 cusr 79.00 csys = 667.04 CPU)
Result: FAIL
Finished test run at Thu Jan 25 12:50:13 2024.
make: *** test_harness Error 10
##### Brew Failed #####


# Failed test 181 - setting $0 does not break %ENV at op/magic.t line 87
#      got "foo foo"
# expected "foo"
# Failed test 182 - setting a key as undef does not delete it at op/magic.t line 87
#      got " "
# expected ""
# Failed test 183 - ENV store of stringified glob at op/magic.t line 87
#      got "*main::TODO *main::TODO"
# expected "*main::TODO"
#  diff at 11
#    after "*main::TODO *main::TODO"
#     have " *main::TODO"
#     want ""
# Failed test 184 - ENV store of stringified ref at op/magic.t line 87
#      got "ARRAY(0x7fadc3259390) ARRAY(0x7fadc3259390)"
# expected "ARRAY(0x7fadc3259390)"
#  diff at 21
#    after "ARRAY(0x7fadc3259390) ARRAY(0x7fadc32593"
#     have " ARRAY(0x7fadc3259390)"
#     want ""
# Failed test 186 - ENV store downgrades utf8 in setenv at op/magic.t line 87
#      got "eh zero <A0> eh zero <A0>"
# expected "eh zero <A0>"
# Failed test 187 - ENV store downgrades utf8 key in setenv at op/magic.t line 87
#      got "widekey widekey"
# expected "widekey"
# Failed test 190 - ENV store takes utf8-encoded key in setenv at op/magic.t line 87
#      got "widekey widekey"
# expected "widekey"
# Failed test 193 - ENV store encodes high utf8 in SV at op/magic.t line 87
#      got "X-Day ᦘ X-Day ᦘ"
# expected "X-Day ᦘ"
# Failed test 197 - at op/magic.t line 87
#      got "foo foo"
# expected "foo"
# Failed test 199 - at op/magic.t line 87
#      got "foo foo"
# expected "foo"
op/magic.t ........................................................... 
Failed 10/208 subtests

Any suggestions? I hate being stuck at 5.36.1. Thanks for your priceless help.

U P D A T E

Apple and macOS are driving me crazy. I purchased a second (refurbished) laptop to run Monterey, as I was maxed out with High Sierra on my go-to machine. I needed to run PDL and it would not build in 10.13.6, and now Perl > 5.36.1 will not build in Monterey. Perlbrew Perl 5.38.2 builds correctly in MacOS 10.13.6. op/magic-27839.t and op/magic.t pass all tests. The changes made to mg.c after 5.36.1 are extensive, more than 3k new code, so the devs broke something. I have little expectation now this will ever be fixed as support for macOS is low-priority. That PDL problem was never addressed to my satisfaction since the way PDL implements macros causes pdlcore.c to segmentation fault in Apple compilers, both clang and gcc. Bummer...

Filed bug report at GitHub

A N O T H E R  U P D A T E

I was asked by Leont at GitHub to try another compiler, so... I downloaded gcc-13 with Homebrew and aliased gcc, cc and clang to gcc-13. I then downloaded a fresh copy of Perl 5.36.3. Unfortunately, there is no diff with gcc-13. op/magic.t still barfs as described above. I see no way forward without help from Perl devs.

F I N A L  U P D A T E

See my reply to syphilis below. I fouled my anchor by writing my own env command and placing it forward of the native macOS env command. That broke the tests. Removing access to my env solved the problem.

  • Comment on op/magic.t fails to build in perl > 5.36.1

Replies are listed 'Best First'.
Re: op/magic.t fails to build in perl > 5.36.1
by choroba (Cardinal) on Jan 26, 2024 at 10:27 UTC
    Please, fix the link to the GitHub issue:

    [https://github.com/Perl/perl5/issues/21890|#21890]#21890

    Also, please fix the formatting there as recommended by ikegami.

    map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
Re: op/magic.t fails to build in perl > 5.36.1
by syphilis (Archbishop) on Jan 26, 2024 at 13:00 UTC
    Apple and macOS are driving me crazy

    I don't know what you should do, but it seems to me that Apple/macOS has a long history of being recalcitrant - which is not perl's fault.
    OTOH, wrt perl, things are generally fine with both Linux and Windows.

    Cheers,
    Rob

      Hot damn! I figured it out! In studying t/op/magic.t, the failing tests when I build 5.36.3 and 5.38.2, or even 5.30.3, to find a version of Perl that works with PDL-2.084, are focused on various ways to manipulate %ENV. An interesting key is {__NoNeSuCh} which I assume is deep in perlguts and relates to how $0 gets set. The test does `env` but in my infinite wisdom I wrote my own env command and placed it forward of /usr/bin/env, the native env in macOS/Linux. Obviously, now it's clear that mine does not run early enough in process creation, so it fails to capture the true environment needed for those tests to run successfully. When I remove access to my env and let perlbrew use macOS env, those tests pass 100% correctly. Boy, it's really easy to shoot oneself in the foot :-( My apologies to all monks who wasted their valuable time looking at this classic example of pilot error. I will now revisit building PDL.

Re: op/magic.t fails to build in perl > 5.36.1
by InfiniteSilence (Curate) on Jan 26, 2024 at 00:29 UTC

    How I handle updates:

    • Create a sandbox for all of my stuff (virtual machine, container, etc)
    • Install everything, run all of the tests
    • On failures, ask a) whether I actually use that functionality b) whether I agree with the failure -- it might be some garbage test that is checking for POD completeness

    I install a lot of modules but only really need a certain number of them. I know which ones are which by adding Test::More and use_ok() calls inside of all my projects for the important ones.

    Celebrate Intellectual Diversity

      Thanks, but in no way does this address my issue, which is fatal to build, and if you look at mg.c you can see how dense and central that code is to Perl op-code processing at run-time.