build and release 5.34

[shawnlaffan]

We should build and release a version of 5.34, if only for the sake of major version completeness.

This was the original intent of #39 but discussion has become much broader.

The risk is that it won't compile with gcc13, or the patches we are using for 5.36 will not port across. We won't know until we try, though.

[fenginsc]

Is version 5.34 ready now? What's the progress so far?

[shawnlaffan]

No progress yet. I'm busy the next few weeks so the next chance I'll have is late September.

[shawnlaffan]

Just for notes, I did have a go at building 5.34 using the same gcc as for 5.36 but hit all the same patching problems.

If we do build a 5.34 then it will likely be with the same stack used for 5.32.

I'm not sure how much it is needed, though.

[genio]

I get the desire for major version completeness, but I'm also "meh" on this one. We're currently at 5.40, so I don't see much need in a 5.34 realistically.

[ferki]

Some projects have a valid need to support older Perl versions, even if that is not the best, or perhaps even recommended decision for many other projects.

One model to follow was to be in sync with the Lancaster Consensus, which was later obsoleted and modernized by the Lyon Amendment. TL;DR is "support about 10 years old Perl", which is at 5.16/5.18 at the moment.

Wearing my maintainer hat for such a volunteer-driven project, it would be nice to have 5.34 available too. It is currently a blind spot in our automated testing with Strawberry Perl on Windows via GitHub Actions, while other releases proved to be useful to fix missed bugs we missed otherwise, and it also helps prevent introducing further ones.

I'm a long-term Linux user since 15+ years, who currently lacks access to a Windows box, and also experience to build software like Perl on Windows, though I'd be happy to see if there's something I could contribute towards making 5.34 available.

[shawnlaffan]

Once 5.40 is out I'll see if I can do a UCRT for 5.38. Then I'll have a look at 5.34.

I'm again at that stage of the year where things get busier so we'll see how optimistic that plan is.

[shawnlaffan]

I've had a go at building 5.34 with the same stack as used for SP 5.32.

The build completes but then many tests fail. Some are flagged as timeouts but others are Dubious, test returned 255 (wstat 65280, 0xff00).

Setting OPTIMIZE=-Os gets things to pass again, which is interesting given this is gcc-8.3. (Edit - see #232 for some context)

Next is to get the CPAN modules to build.

[sisyphus]

Setting OPTIMIZE=-Os gets things to pass again, which is interesting given this is gcc-8.3.

Indeed.
In my mind, I've always put the need for "-Os" down to some change in gcc - but this suggests that it was triggered by a change in perl source. (I wasn't building devel releases on a regular basis back then.)

I'll identify the first 5.33.x release for which "-O2" fails to work. ( Please let me know if you've already made progress on that - as that might save some duplication of effort.)

[shawnlaffan]

Thanks Rob.

I'm not trying to work out which version caused the issue so you have carte blanche on that front.

This comment from @xenu is relevant: #85 (comment)

[shawnlaffan]

Another data point for the choice between -O2/-Os:

BerkeleyDB fails (crashes) test t/strict.pl with -O2 but passes with -Os when built with 5.34. There are no failures for either optimisation level when built with 5.36 or 5.40.

[shawnlaffan]

A beta release of 5.34.3.1 is now available.

https://github.com/StrawberryPerl/Perl-Dist-Strawberry/releases/tag/dev_5.34.3.1_20250205_gcc8