http://www.perlmonks.org?node_id=11128612

Not sure that anyone here is particularly interested in this, but I'll mention it anyway that, as of the release (on 20.01.2021) of perl-5.33.6, it's possible to build perl on MS Windows with an NV type of __float128.
And it has become a little easier in 5.33.7 with a change to GNUmakefile that removed the need for a somewhat cumbersome configuration argument.
With the release of perl-5.22.0, the NV type of long double was enabled on Windows, and now we finally get the additional option of having the __float128 NV type.
All of this does, of course, rely on using mingw-w64 ports of gcc to build your Windows perl.

I think that many of us, accustomed to simply using Strawberry Perl, don't realize just how easy it is to build perl from source on Windows.
Strawberry Perl, itself, does provide us with the toolchain that's capable of building any recent version of perl (including blead releases) from source.
The latest blead source can be obtained with:
$ git clone https://github.com/sisyphus/perl5.git blead_clone
or the perl-5.33.7 development tarball is available from:
https://cpan.metacpan.org/authors/id/R/RE/RENEEB/perl-5.33.7.tar.gz
Then, I place my C:\_64\strawberry-5.32.0\c\bin folder at the beginning of my PATH, and I have all that I need to build perl.
Simply cd to the perl source's win32 folder and run:
gmake INST_TOP=C:\bleadstraw CCHOME=C:\_64\strawberry-5.32.0\c CCTYPE= +GCC I_QUADMATH=define USE_QUADMATH=define test
Then, to install perl into the location specified by INST_TOP, just run:
gmake INST_TOP=C:\bleadstraw CCHOME=C:\_64\strawberry-5.32.0\c CCTYPE= +GCC I_QUADMATH=define USE_QUADMATH=define install
And that's it - in C:\bleadstraw I now have a Windows perl that has __float128 as its NV.

You may want to alter INST_TOP, and you probably need to alter CCHOME which should specify the full path to gcc's bin directory.
NOTE that CCHOME does not include "\bin". (Failure to get CCHOME right will cause some test failures, but will not affect the perl that has been built.)

If you want to do a 'long double' build instead, you would just remove the 2 gmake arguments that include the string "QUADMATH", and insert the USE_LONG_DOUBLE=define argument.
If you don't request either a 'long double' or a 'quadmath' build, then the nvtype will be 'double'.

If you're using a 32-bit compiler, you'll also need to insert the argument WIN64=undef, and you might also want to add the argument USE_64_BIT_INT=define if you want 64-bit integers and pointers.
With 64-bit compilers, perl's integer and pointer will inevitably be 64-bit.

I think that covers the most commonly exercised options ... but you'll find additional options laid out in the GNUmakefile.

I don't know if it's a general issue, but (on 64-bit builds only) there's usually a couple of test scripts in cpan/IO-Compress/t that hang for me .
Update: This issue is a long-standing one for me, and is not limited to just the "quadmath" builds.
It's generally (but not always) the same test scripts that hang, and it has been happening for a few years. In perl-5.33.7, I'm finding that the problem has moved to a different couple of files.
The Strawberry project have never, to my knowledge, complained about such an issue - so I'm hoping that it's just something in my particular environment.
It would be nice to find out if it is "just me".
It's quite annoying - I have to kill these hangs using process explorer in order to get the test suite to run to completion. (Killing them with Ctrl-C kills the entire 'gmake test' process.)
These test scripts have always passed when run outside of the testing harness, and they've also passed even when I've run make test in the cpan/IO-Compress folder.
There's also the same thing happening in the cpan/IPC-Cmd tests with t/01_IPC-Cmd.t.
If I can find any evidence that it's also an issue for others then I'll try to get it fixed.

Oh, one last thing - if you build a 32-bit perl with I_QUADMATH=define USE_QUADMATH=define but without USE_64_BIT_INT=define, then expect some failing tests in Math::BigFloat due to a Math::BigInt::Calc bug.
This issue has been reported, with a proposed simple fix to Calc.pm.

Cheers,
Rob

Replies are listed 'Best First'.
Re: Quadmath builds of perl for MS Windows
by pmqs (Friar) on Feb 21, 2021 at 16:15 UTC

    I'm the author of IO-Compress, so always interested to hear about the build failures.

    If you have the time to do get me some more details about what is failing, I've created https://github.com/pmqs/IO-Compress/issues/29

      Tried you instructions for building on Windows - the IO-Compress tests all passed.
        Tried you instructions for building on Windows - the IO-Compress tests all passed.

        Thanks for taking the time to try it out, and also for the feedback.
        I'll update that Issue 29 that you've created with improved information later today.

        I think it must be something in my environment that's screwing things up ... or perhaps even this Windows 7 OS itself:
        Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved.
        In itself, it's not much of a problem if you're just building perl once.
        But it does become quite a nuisance if you're building a number of perls with different configurations and/or with different versions of gcc.

        Cheers,
        Rob
Re: Quadmath builds of perl for MS Windows
by danaj (Friar) on Feb 21, 2021 at 11:48 UTC

    Thanks! I'm interested and appreciate the post.

    Now to get it working on MAC M1 :)

    I just solved my main Perlbrew issue. Using '--64all' dies horribly because the hints/darwin.sh file is missing arm64 and then it gets really confused. But just leaving that off seems to build 64all regardless. But that's a digression from quadmath, which was next on my list.

      Now to get it working on MAC M1 :)

      Is it possible to build with -Dusequadmath on any Mac systems at all ?
      I know so little of Mac systems ... beyond claims I've seen stating that they're a "Linux based system".
      That being so, I would have thought that the answer to my question would be "yes".
      But then, I've also seen lots of scathing remarks wrt "Apple compilers" ... to the extent that I don't really know what to expect.

      Using '--64all' dies horribly because the hints/darwin.sh file is missing arm64 and then it gets really confused. But just leaving that off seems to build 64all regardless.

      I hope you're talking there about builds done with 64-bit compilers.
      Given that a 64-bit compiler must inevitably provide 64-bit IVs and pointers, it might come as no surprise that it is confused by being specifically asked to do something that it intended to do in the first place.
      But I would be disappointed if a 32-bit compiler insisted on building a perl with 64-bit IVs and pointers without being specifically asked to do so.

      Anyway ... good luck with the -Dusequadmath aspirations !!

      Last time I checked, it seemed to me that Raku provided neither 'long double' nor '__float128' support on any systems.
      Are we still ahead of them on that score ?

      Cheers,
      Rob