Strawberry Perl POC and Status of 5.34.1 #39
Comments
|
We are trying to get things working. Life has hindered some of us from being able to work on it some. It's in the works, but I can't give an honest estimate of the time it will take at the moment. Apologies for that. |
|
Thank you Genio. I appreciate all the effort involved in a new release. |
|
Perl 5.36.0 released. |
|
Hello :) Same here, I'd love to test Perl 5.34 in order to use, at least, the native try catch blocks :) Hope to see an update soon 🤞 |
|
I would recommend building perl yourself. Start by grabbing the perl source: (It wasn't until I finished writing this that I realized you had specified 5.34.0, not 5.36.0.) Untar that perl source into some directory - say C:\straw-comp. Given that I want to install a 64 bit build of perl-5.36.0 into C:\straw\perl-5.36.0, I'll need to include the following command line argument: (Modify accordingly if you want to install it elsewhere.) I'll also want to specify CCHOME, which is the directory that contains (Modify accordingly if your CCHOME is somewhere else.) ############## Annoyingly, there's some cpan/IO-Compress/t/ tests that hang for me. Then, after I've built perl with 'gmake .... test', I clear that environment variable, cd to 'cpan/IO-Compress', run 'gmake test' and sit back while all test pass. There might also be a hang with IPC-Cmd/t/01_IPC-Cmd.t. (Let me know if you see that one.) And, of course, I also: Then, after I've built perl with 'gmake ... test', and still in the 'win32' folder, I clear that environment variable and run: I can then examine out.txt, whereupon I clearly see that all tests have passed. If a test hangs, you can just kill it using Process Explorer (if you have that). ##### Run 'gmake test': Then run 'gmake install', repeating the same options as were used for 'gmake test'. That's it. Then just run: ############# Not actually necessary, but I recommend adding to the above command line args. If your Strawberry Perl (and therefore gcc also) is 32-bit then you'll need to add to the above command line args. If your Strawberry Perl (and therefore gcc also) is 32-bit and you want 64-bit integers then you'll need to add to the above command line args. Alternatively, if you want your nvtype to be 'long double', then you'll need to add: to the above command line args. Alternatively, if you want your nvtype to be '__float128', then you'll need to add: to the above command line args. If you want to re-use the same source to build a perl with a different configuration, or using a different compiler, just run 'make distclean' first. Cheers, |
|
Besides it could be built own windows perl. The new language version announcement with binaries for major OSes is considered common and basic. See the new kids on the block & hipster language zig's download page( https://ziglang.org/download/ ). Why not for perl itself? I think this is a matter that TPF(the perl foundation) should be concerned about. |
|
@aero It's an extremely complex process being completed by volunteers. The TPF doesn't have anything to do with the Strawberry build of Windows to my knowledge. We're making progress on it every day, but we're trying to do so in a way that will make future builds less opaque and allow more people to work on it. Please don't come in here being rude and saying because others do it, we should be able to with no problem. Understand the entirety of the problem set starting with some of the information here: https://github.com/StrawberryPerl/spbuild and then start working through the steps. None of it's simple on Windows. |
I'm sorry if it felt rude. I hope perl has multiple options like python.
I mentioned TPF because I think TPF needs to support or be responsible for the official windows perl package like other major languages by donation or grant apart from Strawberry perl.
Thank you for your unseen efforts. |
|
@genio, I don't think @aero was being rude. Of course, they never have, and they probably never will - but @aero's POV on this makes reasonable sense to me. I don't think he was suggesting that it was time for the perl developers to take responsibility for the release of Strawberry Perl. Cheers, |
|
Thanks for that great HOWTO, Rob (sisyphus). I decided to have a go myself and managed to build 5.36 starting with my SP 5.32 installation, as you did. Interestingly, I had no problem with IO::Compress, but my build failed on HTTP::Tiny. My solution was to move that folder out of the cpan folder and running gmake again. I'll do some more experimenting when I get time (you asked us to let you know about test failures, but I'm not sure where; I don't think this is the correct forum). As others have pointed out, Strawberry Perl is more than just the latest perl, so I kept the rest of the distribution, swapping the original strawberry/perl folder with the new one. I bootstrapped cpanm by copying the fat-packed script over as cpanm.pl and running After that, I could build and install other modules in the usual way, e.g. I did hit a snag with namespace::clean where it complained about the missing libstdc++-6.dll. I guess this is where SP is more than just perl... Any advice on that? I just copied that and the other additional DLLs over from SP 5.32 and re-ran cpanm. That appeared to work and some simple scripts are running fine, but I just worry that I've left a ticking time bomb in there! |
|
On Sun, Jul 17, 2022 at 10:30 PM blues1875 ***@***.***> wrote:
Thanks for that great HOWTO, Rob (sisyphus). I decided to have a go myself
and managed to build 5.36 starting with my SP 5.32 installation, as you did.
Excellent !! I encourage you to make a habit of repeating the exercise from
time to time.
You'll find basic documentation on those (and other) options that I
mentioned in win32/GNUmakefile in the perl source.
You can even implement those options by editing that file by hand - but I
think it's simpler to just specify them on the command line, especially if
you're doing scripted builds. (Editing the GNUmakefile by hand is tedious.)
Interestingly, I had no problem with IO::Compress, but my build failed on
HTTP::Tiny. My solution was to move that folder out of the cpan folder and
running gmake again. I'll do some more experimenting when I get time (you
asked us to let you know about test failures, but I'm not sure where; I
don't think this is the correct forum).
That's a failure I've not struck.
It should be reported to https://github.com/chansen/p5-http-tiny/issues
As others have pointed out, Strawberry Perl is more than just the latest
perl, so I kept the rest of the distribution, swapping the original
strawberry/perl folder with the new one. I bootstrapped cpanm by copying
the fat-packed script over as cpanm.pl and running
perl cpanm.pl App::cpanminus
After that, I could build and install other modules in the usual way, e.g.
cpanm Moo
I did hit a snag with namespace::clean where it complained about the
missing libstdc++-6.dll.
libstdc++-6.dll is in your strawberry/c/bin folder - alongside other
crucial files like gcc.exe and gmake.exe. You'll want to keep that folder
in your path.
I guess this is where SP is more than just perl... Any advice on that? I
just copied that and the other additional DLLs over from SP 5.32 and re-ran
cpanm. That appeared to work and some simple scripts are running fine, but
I just worry that I've left a ticking time bomb in there!
My StrawberryPerl-5.32.0 installation is from the "portable" distro, and is
located in C:\_64\strawberry-5.32.0.
So, I double-clicked C:\_64\strawberry-5.32.0\portableshell.bat, which
opened up a new shell with an appropriately set PATH
Then I built perl-5.36.0 as previously described, installing it into
C:/ctraw/perl-5.36.0.
Then, all I did, was to prepend my perl-5.36.0 to the already existing
PATH - by running:
set PATH=C:\straw\perl-5.36.0\bin;%PATH%
When I run 'cpan -i namespace::clean' I get the very same error wrt
libstdc++-6.dll as you got - yet I know that libstdc++-6.dll is in my PATH.
Apparently the namespace::clean test suite does abusive stuff to the PATH.
One thing that SP does is to place copies of libgcc_s_seh-1.dll,
libstdc++-6.dll and libwinpthread-1.dll (all of which are found in SP's
c/bin folder) into SP's perl/bin folder.
I suspect they do that to ensure that if something does remove c/bin from
the PATH, then those 3 files will still be found - by virtue of them being
in the same directory as the perl dll.
Anyway ... copying those 3 files across from SP's c/bin to my
perl-5.36.0/bin fixed that issue for me.
I don't think there should be any bombs in there ... of course, I haven't
really played about with this much, so I could be wrong.
I was surprised to find that my Math::GMPz, Math::GMPq, Math::GMPf and
Math::MPFR modules all built straight out of the box on this perl-5.36.0,
using the static gmp and mpfr libraries that shipped with SP-5.32.0.
I had thought that this perl-5.36.0 might not know where to find those
libraries by default ... but it found them just fine.
I was even able to build and install Net-SSLeay-1.92 after setting the
OPENSSL_PREFIX environment variable to C:\_64\strawberry-5.32.0\c.
Of course, it's quite possible that the next SP releases will ship with
more recent versions of those libraries, and hopefully a more recent
version of the gcc toolchain, too.
Cheers,
Rob
|
|
I just hit another problem with my new 5.36 build: Perl-Critic wouldn't build because of a problem with Module-Pluggable, provoked by an update to File-Find. See simonwistow/Module-Pluggable#24 |
|
Interesting. There's a number of Linux smokers that would have detected this problem when File-Find-1.39 was first introduced to bleadperl ...., if it was something that affected Linux. I gather that the problem is not that File::Find is ding something it shouldn't ... instead it's a case of Module::Pluggable making an assumption that it shouldn't ? It took me a bit longer than it should have to work out what the patch at simonwistow/Module-Pluggable#24 actually was. The author of Module::Pluggable hasn't released anything on CPAN for nearly 7 years, so I'm not sure how long we might be waiting for the patch to be implemented and a fixed version of Module::Pluggable released. Cheers, |
|
This has been quite an interesting exercise! I think you are right to encourage others to build their own perl... the devil is in the details, as always! I had problems with Module::Find, too. That module also uses File::Find and is related to symlinks, but that one is a bit harder to figure out. Once SP 5.36 (or even 5.34) is released, I'm sure more people will find more of these problems, but I understand that there is a lot of work involved with putting together a new release of SP--many thanks to you guys. I hope my experience helps, if just a bit. Building our own perl and finding these glitches is a good way for the rest of us to contribute. Glenn |
|
I suspect that the "real spanner in the works" (and the the thing that needs fixing) is File::Find. It doesn't feel right to me that such changes have been made, given that they're breaking both Module::Pluggable and Module::Find. (And I think it's quite possible that the developers who made those changes are not even aware of those breakages.) Should we question the validity of those changes to Find.pm by raising an Issue at https://github.com/Perl/perl5/issues ?? Cheers, |
|
@sisyphus You might want to float this in #p5p on magnet and get some conversation going there before putting in a bug report. They'll help make sure it has all of the info int it that it needs |
|
The change was intentional to support Win32 symlinks, see |
Well, you're getting pretty far away from the original complaint raised in this issue, so you should probably start a fresh ticket somewhere. If you believe the problem is in the Perl core distribution -- as distinct from Strawberry Perl or some (non-core) CPAN module, then you should probably check your results both before and at this commit: |
|
Here is another issue with perl 5.36, @sisyphus. Path-Class fails build tests. See kenahoo/Path-Class#55. Path-Class is a dependency for DBIx-Class-Schema-Loader. |
Yeah ... there's an issue with t/01-basic.t on Windows whereby tests like: To overcome this, t/01-basic.t begins with: and that takes care of that particular issue nicely. (There's at least one other Windows-vs-Unix incompatibility that it also attends to.) I think the first thing that needs to be established is whether this hack of overriding $^O is deemed a valid technique. My reading of the "$^O" documentation in perlvar leads me to think that this technique is invalid - but there's no specific forbidding of overriding it. Have a play around with removing the $^O override in t/01-basic.t. And check it on both perl-5.32 and perl-5.36. Cheers, |
|
I removed the $^O override. It doesn't bale out now on the fatal error, but it does fail 30 if the 78 tests with lots of complaints about backslashes like this: I guess I should report this over on Path-Class issues. |
|
I don't know where to report it.
Also, yesterday I failed to point out that (using un-edited Path-Class-0.37
source with perl-5.34.0 and later) the way in which t/01-basic.t fails
depends upon whether it's run inside or outside the Test::Harness.
'gmake test' will trigger the "Can't call method...." error, but 'perl
-Mblib t/01-basic.t' or 'perl t/01-basic.t' will trigger the failures that
the $^O override is supposed to fix.
I've just created https://www.perlmonks.org/?node_id=11145885 in an attempt
to find out a bit more about what should be done.
Cheers,
Rob
…On Tue, Aug 2, 2022 at 9:58 AM blues1875 ***@***.***> wrote:
I removed the $^O override. It doesn't bale out now on the fatal error,
but it does fail 30 if the 78 tests with lots of complaints about
backslashes like this:
# Test 6 got: "dir\\bar.txt" (t/01-basic.t at line 20)
# Expected: "dir/bar.txt"
I guess I should report this over on Path-Class issues.
—
Reply to this email directly, view it on GitHub
<#39 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAR3PBUHZ53ZWKXSN7HU23VXBQC7ANCNFSM5VAT63HQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Hi all, I also have an interest in seeing new Strawberry dists...OR, in fact I may consider building my own Perl dist given the insights gained here. I already have a complete build process to do that on Linux, while it currently piggybacks on Strawberry, and adds a huge number of modules for our inhouse deployable Perl in order for me to ensure I have 'the same' stuff on our platforms. Regardless of that, I'm interested in helping in various areas to the extent I'm able, with the goal of getting new Strawberry dists out. If that helps me in 'building 'my own dist', so much the better ;-). Since there's such a multitude of things to be aware of, the more of us the merrier I think when ferreting all the itty-bitty issues out in the open... So in regard to that I seem to have a few other issues than already discussed above which I would like to compare notes on with others. ====== I currently see two issues with building perl-5.36.0 ('raw', figure this is best before trying to tackle the Perl::Dist::Strawberry build system): For reference, I use the 'CCHOME' in a portable Strawberry 5.32.1 to build, a freshly unpacked perl-5.36.0.tar.gz and
(note that using 5.34, I was forced to add "USE_64_BIT_INT=define" despite it shouldn't be needed...)
NOTE: this problem will be reported on the https://github.com/Perl/perl5, but if you want to build 5.36.0, it can be patched to work around it. I haven't been able to test yet, but it seems that blead as of now should have the same problem. During build of ext/Errno, the Errno_PL.PM is invoked, which basically as I understand it, collects all the possible include files in The problem (which apparently happens only with 5.36.0 [?]) is that the gcc run commonly errors out with something like this: Unfortunately, this isn't trapped by the code (nor will the make file trap it even if the code would exit with an error exitcode). If someone is working on a perl-5.36.0.pp file in P::D::S, this problem can be patched by making the file list be treated in
Some are inconsequential, but some individual errors, as well as some test runs exiting with 255 indicating some kind of core (seems to be unicode/utf8 related stuff though...some C libs that are broken on win32?). Haven't tried to follow up on them, but anyone seeing the same and/or have some ideas on why? =========== Lastly...this issue seems to be slightly overcrowded in discussing issues a bit beyond tracking the original subject, clouding it a bit. And I do the same...:-) Is there a more convenient forum to discuss selfbuilding perl on win32 considering this? In particular to jointly help with the wish to see new Strawberry dists. ken1 |
Oooo ... alarm bells ... this should only be the case if the gcc compiler is 32 bit. I have struck nothing remotely like the errors you are reporting. It's probably a good idea to create a perl5 issue about this - rather than further pollute this thread. (I will follow that issue with interest.) Cheers, |
|
Rob, thanks for your comment. Re: polluting this thread (in general) - I agree; any suggestions where these type of postings could/should be made 'best'? Having said that I'll give some short replies here: Re: my first problem, I've just filed Perl/perl5#20033; for me it's quite real and very reproducible and I'm guessing you actually can recreate it too; just run the Errno_pm.PL script a number of times per my example if you're curious. Then again, no biggie. Re: 5.34 and USE_64_BIT_INT - I'm 64 bit, Strawberry 5.32.1, Win11 as build toolchain and certainly see that gcc, just as with 5.36 so it's confusing - as you say it shouldn't be necessary. I'll retest and ensure reproducibility and file an issue,,, Finally: apart from the tests you mention giving problems (which they don't for me!), are you otherwise getting a clean test run? Only major difference (?) I can think of is that I'm using Win11...I'll soon be firing up my work computer with Win10 and try things there but...I'm certainly curious what I might be doing different/wrong...:-/ Thanks again, |
|
While I don't mind having this issue open for you to keep the information somewhere, it might be helpful for you to join the #p5p IRC channel as they'd have the most expertise in building Perl in general. |
|
Thank you! |
|
I can reproduce the behaviour with I'll keep an eye on Perl/perl5#20033 and chime in if I've got anything to add - though I might not get a chance until early next week. I've double-checked on the perl-5.36.0 that I built with Strawberry's gcc-8.3.0 toolchain. I definitely didn't explicitly define USE_64_BIT_INT, though $Config{use64bitint} reports 'define', $Config{ivtype} is 'long long' and $Config{ivsize} is 8. Unless that condition is evaluated as false, I don't see how USE_64_BIT_INT could be anything other than 'define'. Cheers, |
|
New dev release for 5.36.1, compiled using gcc-13.1, is at https://github.com/StrawberryPerl/Perl-Dist-Strawberry/releases/tag/dev_5361_20230506_gcc13 |
|
A second dev 5.36.1 dev release is now available from https://github.com/StrawberryPerl/Perl-Dist-Strawberry/releases/tag/dev_5361_20230524_gcc13 The main change is that PDL now builds. The list of open issues is at https://github.com/StrawberryPerl/Perl-Dist-Strawberry/labels/perl5.36 The ones I think we need to resolve for a proper release are BerkeleyDB and DBD::Oracle. |
|
Regarding BerkeleyDB, I don't use it (it came preinstalled with Strawberry), but have successfully upgraded it in 5.24, 5.26, and 5.32. Regarding DBD::Oracle, I don't use it (it came preinstalled with Strawberry), and have never been able to upgrade it. It appears to be missing some sort of Oracle client. I think consideration should be given to omitting it entirely, as most systems are not going to have Oracle installed by default. Ditto for DBD::Pg, as most systems are not going to have PostgreSQL installed by default. At worst, perhaps you could have dummy stubs for DBD::Oracle and DBD::Pg just to tell the user that Perl support is available, but not attempt an upgrade (e.g., an impossibly high version number, and instructions on how to install the real thing)? It would be interesting to see if IPC::Run will install and upgrade, as I have not been able to upgrade it since 0.96. Math::MPFR chronically fails to upgrade earlier than 5.32, but as of 5.32 it appears to be OK. Finally 'B' only upgrades on the current (5.36?) Perl -- I have asked CPAN to consider putting in some guards so |
|
Thanks @PhilterPaper The issue with BerkeleyDB is that it does not build against libdb built with gcc-13. Currently the SP5.36 dev releases are re-using the libdb from SP5.32. This works but some builds show warnings about not being able to find gcc-8 files, warnings I am assuming come from libdb files. WRT DBD::Oracle I'm starting to think the same way as you. If I understand correctly, the license means we cannot redistribute its binaries. They are not provided with SP5.32, and probably earlier. If DBD::Oracle builds cleanly when the binaries are available (and the user sets the right env vars) then we perhaps don't need to provide it. WRT DBD::Pg, Strawberry Perl provides the Postgres binaries. The possible issue is when the user tries to use its PL/Perl interface. FWIW, it seems not to be exercised in the DBD::Pg tests. SP5.36 come with the latest IPC::Run. There is also the spectre of build failures due to changes in gcc-13 (probably anything since gcc-8.3). We already patch in a number of perl 5.37 changes to get things to build (e.g. PDL), and it is possible some other modules will also show similar failures (maybe those for Tk are a manifestation of this). This can perhaps be considered just a normal part of the build cycle and thus not a blocker to any SP releases as those modules will need to update eventually anyway. |
Now fixed in the github repo (https://github.com/sisyphus/math-mpfr), and therefore will be fixed in Math-MPFR-4.27 when it is released. Cheers, |
That worries me. Ideally, you should not custom patch any package to get it to build on Windows/Strawberry, as opposed to a patch (to that package's basic source) that is universally distributed and works on all platforms, or at least, can conditionally build on Strawberry. There's no point in shipping Strawberry with a custom build of some package, when the package's next update on CPAN will then fail. At least, that's how I'm reading (misreading?) the quoted post. Patches to Perl itself, to get it to play nice on Windows, are another matter. Presumably no one with Strawberry Perl installed is going to upgrade their Perl with a non-Strawberry replacement, so as long as Strawberry Perl language and behavior meets specs for Perl programs, that should be OK. There may still be the issue of a program or package developed on Strawberry, failing to run properly on non-Strawberry platforms, but hopefully that can be avoided by either tweaking Strawberry Perl, or doing something with the OS detected in the program. TL;DR: if a package on CPAN can be built (without customization) for shipping with Strawberry, it should be possible to install/update directly from CPAN, and work. |
@PhilterPaper - We're in agreement. Exceptions for patching apply when a module has a reasonable number of dependencies (particularly in the SP builds), the issues have been reported upstream, and where a new release seems unlikely or not imminent. The four I am building patched versions of are There are four others that have been patched for previous builds and which I have not looked into in any detail, except to note most do not have recent releases on CPAN. To see them, search for One point to note from the build config is that tests are skipped, in whole or in part, for many of the modules. Some of these are failures only on docker. Others I have not looked into but I do think it is reasonable to trust the decisions of the previous maintainers. |
|
Good point about the dependencies chain -- I hadn't really considered that. If package X won't build, knocking dependent packages out of the build, and so on and so on, any idea how much of the package list would have to be removed in all? I presume that you're keeping an eye out for problems in the tools themselves, rather than a fault in the end package itself? Compiler and linker bugs, library bugs, etc. Of course, getting such a bug fixed may set off a chain of failures in packages that were "fixed" to get around a tool bug in the first place! |
I'm watching the winlibs repo if that's what you mean. I also have the occasional look at the gcc development but am happy leaving that to the experts. Edit - and winlibs has a new gcc-13.1 release which we need to try StrawberryPerl/spbuild#17 WRT the perl dependency chains, we build more than 230 packages from CPAN, plus their dependencies. The Task::Kensho checks in #103 have also been useful. This gives a pretty good sample. The main breakages for SP 5.36.1 are now related to symlinks and directory separators. The latter is easily worked around by path normalisation. The latter might need more investigation. There are other issues that might be related to memory alignment but which seem to be Strawberry specific. #102, #98, #26 (comment) (Edit - I meant don't seem to be Strawberry specific). |
|
I've just uploaded a new dev release. https://github.com/StrawberryPerl/Perl-Dist-Strawberry/releases/tag/dev_5361_20230609_gcc13 The main change is that we now use release 5 of the winlibs gcc-13 stack. Compilation using its gcc is substantially faster than previous versions. Unless some substantive new issues are identified I am thinking the next will be a proper release. |
|
Perl 5.38.0 RC1 builds with the same test failures as 5.36.1 (#60), which is good news. A portable version is at https://github.com/StrawberryPerl/Perl-Dist-Strawberry/releases/tag/dev_5380RC1_20230618_gcc13 if people want to test their favourite modules. PDL and Inline::C work. I have not tested the Task::Kensho list yet. #103 (comment) |
|
A build of Perl 5.38.0 RC2 is at https://github.com/StrawberryPerl/Perl-Dist-Strawberry/releases/tag/dev_5.38.0_RC2_20230626_gcc13 |
|
A version of Strawberry Perl 5.38.0 is at https://github.com/StrawberryPerl/Perl-Dist-Strawberry/releases/tag/dev_5380_20230704_gcc13 @genio - If no issues are reported then we could likely promote those to final for 5.38.0. A 5.36.1 can follow, and perhaps a 5.34 if there is an actual need and the patches we are applying to 5.36 apply cleanly. |
|
Discussion on this topic has generalised to any release of Strawberry perl, and now that 5.36.1 and 5.38.0 are out the original intent (release a new version) would seem to be satisfied. I've opened #124 for a 5.34 specific release. I will close this issue in a few days unless there is a need to keep it open. |
|
That's wonderful news! I look forward to both versions showing up on StrawberryPerl.com for download and trying out one or both (at least, 5.38). I might wait a few days to see if 5.38.1 comes out; usually .0 releases of any software need to be updated fairly quickly. Thanks for all the effort you've put in! |
|
5.38.1 is likely quite some time off. For example, 5.36.1 was about 11 months after 5.36.0. If you want to avoid .0 releases then Strawberry Perl 5.36.1.1 is available. The website is a work in progress as we don't yet have access. In the meantime you can download from https://github.com/StrawberryPerl/Perl-Dist-Strawberry/releases/tag/SP_5380_5361 |
|
On Thu, 27 Jul 2023 16:01:42 -0700, shawnlaffan wrote:
The website is a work in progress as we don't yet have access. In
the meantime you can download from
https://github.com/StrawberryPerl/Perl-Dist-Strawberry/releases/tag/SP_5380_5361
That's great, thank you!
Are there any plans to release a 32-bit version as well?
Cheers,
gregor
…--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-
|
|
We haven't made any plans to build and test a 32-bit version at this point in time. That being said, are there real world scenarios out there of 32-bit Windows in the wild? Note that this isn't intended to come off as a criticism or plain snide in any way, but a genuine question. I mean, I know there are some "can't ever ever ever upgrade that windows 7 machine that's running my CNC machine" and stuff like that, but are those edge cases actually running/using Perl? Even if so, are those users brave enough to update anything on those machines? I'm asking because it's quite a bit of work. We'd need to rebuild everything with a 32-bit compiler and go through all the testing and whatnot again. That's a lot of work if it's not something used but just kind of, sort of available on someone's testing rig. |
|
A cut down 32-bit version (fewer external libs and perl modules) would likely be sufficient for most needs but it does still involve time on our part. Discussion for a possible 32 bit release is under #96 |
|
Let me first say: === Thanks to everyone involved for the incredible amount of work I suspect has been necessary in getting this on track again! === It is hard to overstate the importance of having a Strawberry dist for me to build on in terms of serving several hundred users in my organization, on both Windows and Linux where I try to make available Perl installations that are as "identical" as possible, from Perl base version to collection of modules. This in order to be as sure as possible that the multiplatform apps and tools we have can be expected to work "everywhere". I have for the past month been busy getting my build system on track for creating the above with 5.38 as the base (building from source on Linux, but "cheating" on Windows by leveraging Strawberry, especially for getting the toolchain and many other libs sorted out). The last I did this with was 5.30 a few years back. Mostly this has been working fine, but I note some modules that I know installed on 5.30 but not now. I'm not organized yet to track things down and properly compare whys and hows, but I expect to report a few later here for a first diagnosis. Again, kudos! ken1 |
|
You're welcome. In terms of the modules, we do have several open issues for those we know to have errors. There is also the Task::Kensho list which is part of a large issue thread but the status of modules is in this comment: #103 (comment) |
|
On Thu, 27 Jul 2023 18:19:11 -0700, Chase Whitener wrote:
We haven't made any plans to build and test a 32-bit version at
this point in time. That being said, are there real world scenarios
out there of 32-bit Windows in the wild?
I'm running a CPAN smoke tester on an old decommissioned laptop
running Windows 10 32-bit.
I guess the machine has a 64-bit CPU but originally it had a 32-bit
Vista or something … and I haven't reinstalled since.
Not a common scenario, and not a typical "production environment".
And this also means that I wouldn't need a full-blown
all-batteries-included Strawberry Perl but just a perl core Windows
32-bit build.
Cheers,
gregor
…--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-
|
The Strawberry Perl developers (of which I am not one) might be too polite to point out that it's really quite easy and straightforward to build such a perl yourself. To put it bluntly and simply, all you need is the gmake utility, the perl-5.38.0 source, and a 32-bit mingw-w64 port of gcc such as UPDATE: One other thing I initially failed to mention in this post is that the changes made by Perl/perl5#21142 need to be made, (The diff is at Perl/perl5@89d9037.) If you need assistance with specifying "args" correctly, just post back here (or even contact me directly) and help will be forthcoming.
Mind you, I'm hoping that SP does release a 32-bit perl - because perl should still support such architectures, and having 32-bit SP builds out and about will help keep 'em honest and on their toes. UPDATE: The PR at Perl/perl5#21324 resolves the following issue with winlibs compilers. With those patches in place, winlibs compilers produce a 32-bit quadmath build of perl, with all tests passing - and the next paragraph can be ignored. In the unlikely event that you want to build a 32-bit perl with nvtype of __float128, don't use the winlibs compilers (as they fail numerous threads-related tests). Disclaimer: I don't really want to make any claims about Windows Vista's capability to build perl. I think it should be ok, but I was unfortunate enough to once have a Vista system, and I well remember that it was a shitheap. Cheers, ' |
|
I'll close this issue now, as promised in #39 (comment) If there are additional problems then please open a new issue. If there is a general question then the discussion forum can be used. https://github.com/StrawberryPerl/Perl-Dist-Strawberry/discussions |
I am preparing to upgrade to the latest release of Strawberry Perl (which shows as 5.32.1.1). I then noticed that Perl itself is at release 5.34.1. I tried to find the name of the POC for Strawberry Perl, but was unsuccessful. What is the contact info for the current manager of Strawberry Perl releases?
I am trying to find out if the upgrade to Strawberry Perl to release 5.34.1 is imminent. If it is, I am happy to wait before upgrading, so I do not have to upgrade twice. Any info you can provide will be most appreciated. Thanks.
The text was updated successfully, but these errors were encountered: