-
Notifications
You must be signed in to change notification settings - Fork 53
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
base: master
Are you sure you want to change the base?
Conversation
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.
@@ -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' }; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Perl-Dist-Strawberry/share/64bit-5.40.1.1.pp
Lines 94 to 113 in 56d14cc
'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.
There was a problem hiding this comment.
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.
This hopefully makes it clearer it is not a standard perl entry.
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. |
Dependency CryptX has recent test failures. DCIT/perl-CryptX#118
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. |
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. |
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.
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.
A beta release of 5.40.2.1 is at https://github.com/StrawberryPerl/Perl-Dist-Strawberry/releases/tag/dev_54021_20250423_gcc13 |
Updates #231 and #124