Strawberry Perl 32bit version

[aero]

Will the 32-bit version also be included in the next 5.36 release? just like previous versions of Strawberry Perl did.

There are some legacy Windows OLE/COM components that only support 32-bit versions, so that case needs a 32-bit version of Perl.
So, even Python and Ruby continue to release 32-bit versions along with their official distributions.

[AgostinoSturaro]

About #94
I have the same question, the 64-bit Win32::OLE module cannot load 32-bit dlls
https://www.perlmonks.org/?node_id=824725

For example, the InstallShield 2022 automation interface is still 32-bit
https://docs.revenera.com/installshield28helplib/helplibrary/IHelpAutomation.htm

[shawnlaffan]

@AgostinoSturaro - the perlmonks node you link to is more than ten years old. Is it still correct?

It might be that we can release a cut-down version for 32-bit. For example, there is no point releasing a 32 bit PDL version so that reduces the number of external libs that would need to be built. And it is the external libs that are the main sticking point.

I'll give this some thought but without any promises for when.

[AgostinoSturaro]

@shawnlaffan Yes, it is still valid, I found that page searching for an error we got when we tried to run InstallShield automation using 64-bit Perl. Moving to 32-bit (same distro and version) solved it.

[wchristian]

I think a 32 bit version may be necessary.

I just tried to install IO::AIO with the newest portable 5.38 64 bit strawberry perl and got this install error:

AIO.xs: In function 'req_invoke':
AIO.xs:778:30: error: incompatible types when assigning to type 'struct w32_stat' from type 'struct _stat64'
  778 |               PL_statcache = *(EIO_STRUCT_STAT *)(req->ptr2);
      |                              ^

Edit: It works under 5.28 64 bit portable, so maybe something to do with the higher versions, or changes in 64 bit handling since then?

[genio]

Newer GCC since back then... ?

Maybe reach out to MLEHMANN to see if you can work with him on it? It's very hard to know what's going on in that particular author's dists since he doesn't use any public issue tracking system that I'm aware of.

I see there was already an issue created on RT over 2 years ago: https://rt.cpan.org/Public/Bug/Display.html?id=138060 but there's no way to tell if anything was ever done with it.

[tonycoz]

AIO.xs:778:30: error: incompatible types when assigning to type 'struct w32_stat' from type 'struct _stat64

32-bit builds won't fix this. We switched to our own stat struct in 5.34 for the stat rewrite, since the MSVCRT/UCRT stat struct uses short for st_dev and st_ino.

[AgostinoSturaro]

We still need a 32-bit version to run the InstallShield automation, which is 32-bit COM stuff.
https://docs.revenera.com/installshield28helplib/helplibrary/AutomationInterface64Bit.htm#automatingbuildprocesses_355067736_1031239

[sisyphus]

We still need a 32-bit version to run the InstallShield automation, which is 32-bit COM stuff

Which of the modules from strawberry perl's vendor/lib are required to run this "InstallShield automation" ?
I'm thinking it's probably much simpler for you to build perl yourself and use the cpan utility to install any extra modules that are needed .... but that depends upon the answer to the question I've just asked.

[AgostinoSturaro]

@sisyphus we need the 32-bit version of the Win32::OLE module to load InstallShield's 32-bit COM stuff, like this

use Win32::OLE;
my $dev = Win32::OLE->new(“IswiAuto17.ISWiProject”);

Here is an example
https://www.revenera.com/blog/software-installation/getting-started-with-installshield-automation-and-perl/

The issue is that we can't use the 64-bit version of Win32::OLE because it can't load the 32-bit COM stuff.
So we need the 32-bit Win32::OLE module.

[genio]

Out of curiosity, would not Wix or the MS Visual Studio Installer Project be easier to deal with at this point than the necessity for a 32-bit Perl for InstallShield?

[AgostinoSturaro]

@genio Not sure what you mean. If you start from scratch, of course you can avoid Perl entirely.
If you have old projects that need to keep working, then no.

The problem is needing 32-bit Win32::OLE to use 32-bit COM, which is an issue with InstallShield's automation and any other program using COM stuff.

[sisyphus]

So we need the 32-bit Win32::OLE module

If that's all you need, then I would certainly recommend that you build and install your own perl-5.38.0 from source and then run cpan -i Win32::OLE
There's not a lot to it.
If you're interested, start by downloading and unpacking:
https://github.com/brechtsanders/winlibs_mingw/releases/download/13.1.0-16.0.5-11.0.0-msvcrt-r5/winlibs-i686-posix-dwarf-gcc-13.1.0-mingw-w64msvcrt-11.0.0-r5.7z
and
https://cpan.metacpan.org/authors/id/R/RJ/RJBS/perl-5.38.0.tar.gz

Put your winlibs/mingw32/bin folder at the start of your PATH
Then cd to perl-5.38.0/win32 source directory and run:
gmake CCTYPE=GCC CCHOME=path_to_winlibs/mingw32 WIN64=undef INST_TOP=path_to_install_perl_into test
When that completes, re-run the same command but replace "test" with "install".
(Copy a strawberry perl gmake.exe to your winlibs/mingw32/bin folder if gmake isn't already in your path.)

However, if you need to also use other modules that Strawberry Perl provides in vendor/lib, then things might become a little troublesome for you if any of those modules need to be built against a 3rd party C library.
The great value of Strawberry Perl is not the "Perl" - it's all of those 3rd party libraries, and the modules provided in vendor/lib that build against one or more of those libraries.
Which other vendor/libs (apart from Win32::OLE) do you need ?

[shawnlaffan]

I ran the code snippet from #96 (comment) through pp_autolink under a 32 bit portable version 5.32. It detected the following dependent DLLs.

c:/perls/strawberry-perl-5.32.1.1-32bit-portable/perl/bin/libgcc_s_dw2-1.dll 
c:/perls/strawberry-perl-5.32.1.1-32bit-portable/c/bin/libssl-1_1_.dll 
c:/perls/strawberry-perl-5.32.1.1-32bit-portable/c/bin/zlib1_.dll 
c:/perls/strawberry-perl-5.32.1.1-32bit-portable/c/bin/libcrypto-1_1_.dll

So any 32-bit perl would also need to provide ssl, zlib and libcrypto.

One option is to use the compiler and libs that come with SP 5.32 as that would avoid potential headaches with building using a more recent GCC. We had to handle a few such issues with GCC-13 for SP 5.36 and 5.38.

[shawnlaffan]

I went ahead and generated a 32-bit version of 5.38.1 using the gcc stack and other libs from SP 5.32.1. The build went relatively smoothly with most CPAN failures being the same as for the 5.38 builds, and thus having the same workarounds.

https://github.com/StrawberryPerl/Perl-Dist-Strawberry/releases/tag/dev_5381_32bit

@AgostinoSturaro and @aero - can you please download and test for your use cases?

If it all works well enough then I'll run a new build when the Perl 5.38.1 release is stabilised (probably as 5.38.2: https://www.nntp.perl.org/group/perl.perl5.porters/2023/11/msg267372.html ).

[aero]

@shawnlaffan
I am compiling 32bit perl 5.38 and using it myself as @sisyphus taught me
but I also tested your https://github.com/StrawberryPerl/Perl-Dist-Strawberry/releases/tag/dev_5381_32bit and Win32::OLE for 32bit COM components works well.
(Except issue like #119 is still exist.)

[shawnlaffan]

Thanks for confirming @aero.

This release will not address #119 since it uses the MSVCRT runtime. I have started building with UCRT that will hopefully do so, but it's still a work in progress. Updates will be under #152 (see also discussion in #150).

[tonycoz]

UCRT makes no difference to #119, it's a core perl issue

[shawnlaffan]

UCRT makes no difference to #119, it's a core perl issue

It seems my optimism has proven unfounded once more.

I guess we wait for the issue to be handled in core perl.

[tonycoz]

The issue is how to handle it, there's been some discussion at Perl/perl5#21562

[gregoa]

I went ahead and generated a 32-bit version of 5.38.1 using the gcc stack and other libs from SP 5.32.1. The build went relatively smoothly with most CPAN failures being the same as for the 5.38 builds, and thus having the same workarounds.

Thank you very much!

Installed, and my old laptop is sending its first CPAN smoke test reports :)
Nothing unusual so far …

[shawnlaffan]

A 32-bit version of 5.38.2 can be downloaded from https://github.com/StrawberryPerl/Perl-Dist-Strawberry/releases/tag/SP_5382_32bit

[AgostinoSturaro]

Awesome! I'll try it next week.

[shawnlaffan]

Flagging issue as closable, pending confirmation from AgostinoSturaro

[AgostinoSturaro]

BTW we also use many other packages. It's just that one that keeps us on 32-bit.
Still terribly buzy, but planning on trying the zip.

[shawnlaffan]

Still terribly buzy, but planning on trying the zip.

No rush - you did say next week. I just flagged the issue so I remember to close it when you respond.

[AgostinoSturaro]

I checked. The Win32::OLE package works.

We also use (among others)
Win32, Win32::API, Win32::File, Win32::Process, Win32::TieRegistry.

During my test, I had to bypass calls to Win32::API and Win32::File, because those packages are not part of the build.
We use many packages, but these were the ones that I had to work around for my quick test case.

It would be nice to have a full 32-bit build with all packages.
Thank you.

[shawnlaffan]

Win32::API and Win32::File are both part of the build.

perl -v | findstr version
This is perl 5, version 38, subversion 2 (v5.38.2) built for MSWin32-x86-multi-thread-64int

perl -MWin32::File -E"say $Win32::File::VERSION"
0.07

perl -MWin32::API -E"say $Win32::API::VERSION"
0.84

We are unlikely to build the full set of packages for 32-bit. However, the stack does include all the external libs from the 5.32 release so it is possible to build packages locally.

[AgostinoSturaro]

That's odd. I had errors about the Dynaloader not being able to load them.
I'll take a look at my lib paths (next week), maybe it was looking for the wrong thing.

Still, I can't advocate using a test build in production, and we need to all use the same package internally, so a local build wouldn't be practical.
Please consider making an official 32-bit release.

[shawnlaffan]

Please consider making an official 32-bit release.

This is an official release. It just does not contain as many pre-built packages as the 64 bit version.

[AgostinoSturaro]

Win32::API and Win32::File are both part of the build.

perl -v | findstr version
This is perl 5, version 38, subversion 2 (v5.38.2) built for MSWin32-x86-multi-thread-64int

perl -MWin32::File -E"say $Win32::File::VERSION"
0.07

perl -MWin32::API -E"say $Win32::API::VERSION"
0.84

We are unlikely to build the full set of packages for 32-bit. However, the stack does include all the external libs from the 5.32 release so it is possible to build packages locally.

OK, I tested again with a simpler env and they work.
If this is an official release, please make it available in the Downloads page.
Thank you.

[shawnlaffan]

OK, I tested again with a simpler env and they work.

Thanks for confirming.

If this is an official release, please make it available in the Downloads page.

The release notes were updated in StrawberryPerl/strawberryperl.com#45 but it looks like they have not been published yet. @genio - fyi

[genio]

Yeah, that table still needs to be updated manually. If one of y'all wants to throw in a PR for that, I'll gladly merge and update. I've been fairly busy with life kicking me as hard as possible lately. Apologies.

[shawnlaffan]

I've added issues to update the release table and releases.json files. See StrawberryPerl/strawberryperl.com#47 and #163

I'll close this issue now as we have an open PR for the 32-bit 5.38 release notes update.