Skip to content

Strawberry perl 5.40.2.1, 5.38.4.1, 5.34.3.1 #233

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 27 commits into
base: master
Choose a base branch
from
Draft

Conversation

shawnlaffan
Copy link
Contributor

@shawnlaffan shawnlaffan commented Jan 22, 2025

Updates #231 and #124

Otherwise we get errors like

```
..\perl.exe -f ..\pod\buildtoc -q
..\pod\buildtoc: perl5401delta.pod is known by buildtoc but does not exist
..\pod\buildtoc: Can't open file 'pod/perl5401delta.pod' for perl5401delta: No such file or directory
ABORTED
```
We get many test failures with -O2 -fno-inline-functions
Also use libxslt 1.1.39 built with that version of libxml2.
Its version is unchanged.
This allows consistency with 5.40.0.
Temporary code as a proof of concept.

Should either be its own step or an optional argument.
Was a copy-paste error
Adding comments causes downstream issues with a few CPAN mods.
This makes it more obvious that a module is upgraded.

Something in the code is uninstalling the original,
which might not be what we want.
@shawnlaffan shawnlaffan changed the title Strawberry perl 5.40.1 Strawberry perl 5.40.1.1 Jan 30, 2025
@@ -29,7 +29,7 @@ sub run {
# Now go through the loop for each module.
my $i = 0;
for my $module (@list) {
my $item = { module=> $module->{cpan_file}, install_to=>'perl' };

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was deliberate on my part "back in the day..."

Given that, why would we want to pack up and install two versions of the same module?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for noting this. FWIW, I had assumed it was deliberate.

The original motivation for the latest change is in #221 where the Socket build differs when built with core or from CPAN. Perl 5.40 came with the latest version of Socket so it was not updated in the CPAN update step of the SP build.

Having run a few dev builds with this set, the P::D::S code is uninstalling the core modules first so we don't actually package both versions. The directories are left behind, though. I also have not yet tracked down where the uninstall is happening.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The original motivation for the latest change is in #221

I think you could alternatively apply the patch at Perl/perl5@0404e25 - though I'm not sure whether that would count as an improvement over your current option ;-)

I don't know why that PR has not been merged. I presume it's just part of the general arrogant and apathetic disregard for Windows, but maybe it actually poses some problem of which I'm unaware.
I've been using that patch without any issue in my monthly builds of devel perl (beginning with perl-5.41.4 or perl-5.41.5), and it seems to be working fine. (My testing of the functionality is, however, not rigorous.)

I think there are a number of other symbols in those Windows config files that could and should also be defined - but I don't feel confident of being able to correctly identify them.
Besides, if the changes identified by that patch are being ignored, then I don't see much point in identifying other candidates for alteration.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are changing some of the related defines before the build. If there are good reasons then we can add more.

'config_H.gc' => {
I_DBM => 'define',
I_GDBM => 'define',
I_NDBM => 'define',
HAS_BUILTIN_CHOOSE_EXPR => 'define',
HAS_SYMLINK => 'define',
HAS_ISFINITE => 'define', # part of https://github.com/Perl/perl5/pull/22257
},
'config.gc' => { # see Step.pm for list of default updates
d_builtin_choose_expr => 'define',
d_mkstemp => 'define',
d_ndbm => 'define',
d_symlink => 'define', # many cpan modules fail tests when defined
i_db => 'define',
i_dbm => 'define',
i_gdbm => 'define',
i_ndbm => 'define',
d_isfinite => 'define', # part of https://github.com/Perl/perl5/pull/22257
osvers => '10',
},

Installing updated core modules to the vendor dir has the advantage that it is then clear that they are not the versions distributed with that version of perl.

@csjewell raises the valid point that we might be distributing two versions of the same module. This could lead to confusion if users manually set the PERL5LIB paths and switch the order of the perl\vendor\lib and perl\lib dirs, but the build system seems to be uninstalling from perl\lib so this problem should not manifest on users systems. (This does need to be more thoroughly checked, though).

Coming back to Socket, an alternative approach is to force a rebuild in one of the CPAN install steps.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have reverted this in 45c9fc9
The main reason is the possibility that some modules install to vendor/bin, and the great majority of installs do not add this dir to the path. Admittedly it's a low probability but better safe than sorry.
Socket is now re-installed as a normal CPAN module. That will avoid the original problems.

Currently two settings, one for core, one for cpan.
Build core with the same set as SP 5.40.0.1,
and CPAN with -O2.

See discussion and links in #232
This makes it clearer when the core was built with
different flags than the CPAN modules.
Skip tests that fail due to path lengths,
rather than all tests.
This allows separate release notes for the PDL edition, for example.
@shawnlaffan shawnlaffan changed the title Strawberry perl 5.40.1.1 Strawberry perl 5.40.1.1, 5.38.3.1, 5.34.3.1 Feb 5, 2025
@shawnlaffan
Copy link
Contributor Author

Just an update.

I have a 5.34.3 build that can be released and will do so later this week.

The 5.38.3 and 5.40.1 releases are waiting on resolution of Perl/perl5#23022, and related patching of the SP builds.

@mohawk2
Copy link

mohawk2 commented Mar 27, 2025

Would it be possible to include a compiled version of GLFW in Strawberry, at least the PDL edition? I intend soon to switch PDL::Graphics::TriD to use that. It would then be possible (at least for PDL purposes) to drop FreeGLUT, though again on current plans there would need to be an overlap with both.

@shawnlaffan
Copy link
Contributor Author

Would it be possible to include a compiled version of GLFW in Strawberry, at least the PDL edition?

If it is easy to add to the build system then we could look at it. PRs are also always welcome.

Can you open an issue on the https://github.com/StrawberryPerl/build-extlibs repo?

An Alien::GLFW is also an option, although the two approaches are not mutually exclusive.

@shawnlaffan
Copy link
Contributor Author

Perl/perl5#23022 now has a patch which can be applied.

There are also new point releases of 5.38 and 5.40. I will update the build scripts to use these when I get to it, hopefully later this week.

These are adapted from Perl/perl5#23179

Differences are:
1. The perldelta update is removed as it is 5.42 specific.
2. scope_types.h has been regenerated as its patch section did not apply cleanly.
There will be no 5.40.1 release.  5.40.2 is a security update.

The pp file includes some tweaking to get modules to build.
Some of these need to be revisited.
@shawnlaffan shawnlaffan mentioned this pull request Apr 22, 2025
10 tasks
Earlier versions of libxml have CVEs, and XML-LibXML
does not work with later versions.

Disabled modules are mainly due to CryptX failures.
These are in turn related to BigMath changes.
@shawnlaffan
Copy link
Contributor Author

@shawnlaffan shawnlaffan changed the title Strawberry perl 5.40.1.1, 5.38.3.1, 5.34.3.1 Strawberry perl 5.40.2.1, 5.38.4.1, 5.34.3.1 Apr 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants