[feature request] don't pollute PATH with mingw toolchain

[rkitover]

The mingw toolchain, compiler, pkg-config, etc.. is in the dist bin folder and so is in your global PATH if you have strawberry in your PATH.

This can cause issues with build tools such as cmake, which find this version of the mingw gcc, pkg-config, etc.; when the user may be wanting to use another toolchain in their PATH such as their own version of mingw or Visual Studio.

What I propose is that the mingw toolchain be stored in a different folder and only added to the PATH on the invocation of a module build toolchain: EU::MM, Module::Build, etc..

I don't honestly know the feasibility of this, what kind of hooks would need to go where.

[LeeThompson]

Strawberry might be able to use "setlocal" at the top of any compiler batch file that would allow PATH and other environment variables to be used as normal but which all go away after the batch file exits.

[kmx]

IMO removing c:\strawberry\c\bin from PATH will break a lot of things.

[rkitover]

The idea is to have it in the PATH for things that need it, started from e.g. some wrapper like EUMM etc.., and not in the user's PATH.

[kmx]

In that case it seems to be rather a feature request for EUMM

[rkitover]

Ok, but do you understand what the problem is. Try running e.g. cmake for a project from powershell with the default strawberry PATH entries, it will find all the mingw crap instead of the user's intended toolchain.

[rkitover]

An update on this. The problem is actually not as bad as I originally thought.

With Strawberry and MinGW installed from chocolatey, the chocolatey MinGW takes precedence in the PATH, with anything missing like gmake being picked up from strawberry/c/bin.

I built and installed an XS module with the chocolatey MinGW in the PATH with no issues.

As for cmake, while it will default to using the MinGW toolchain, simply specifying -DCMAKE_C_COMPILER=cl will make it select the Visual Studio toolchain instead. I will follow up with the cmake project about this default.

Likewise, specifying -DCMAKE_C_COMPILER=gcc will make it select the mingw toolchain, the chocolatey one in this case.

I still think this is bad, but at least not bad enough for me to avoid installing Strawberry entirely.

[sisyphus]

If you're worried about having Strawberry always in your path, install the portable version to the location of your choice.
That location is prepended to the PATH only when portableshell.bat (which is located in the "location of your choice") is executed.

I really don't see any need for Strawberry to do anything differently.

The practice of having the msi install append the relevant directories to the PATH is a long-established one.
If there's already an identical item (eg make, or pk-config, or gcc) in the PATH, then someone must have put it there - and the intent therefore is that the pre-existing item be used in preference to the one provided by Strawberry.

This contrasts with the portable version's portableshell.bat which puts everything at the beginning of the PATH.
In this case, the view is that the user is accepting everything that Strawberry provides.

I think the user should accept responsibility for taking care of these issues when they arise.
It's not always pretty - I can recall renaming Strawberry's pkg-config to pkg-config-hide just to get it out of the way, so the MSYS2 utility of the same name would be used.

Cheers,
Rob

[rkitover]

The issue is having a whole MinGW toolchain in your global PATH, rather than just perl and perl tools like perldoc, which is what people would expect. This can cause all kinds of problems with other tools, and is only done so that perl modules can build themselves. Perl modules should be able to build themselves without doing this.

[genio]

This is not an issue, but a requirement for Perl on Windows. In the unfortunate event that you have an alternate MinGW installed, you will have to be careful about your environment. There's no other way for Perl to function on Windows.

Please close this as there's simply no other way. Your work-around is to use the Portable installs and handle your own PATH how you like, but for the masses, this is how things have to be.

Perl use requires XS modules and third party libraries for developers to be able to write code. XS modules and those third-party libraries require MinGW on Windows as that's what Strawberry is built on. They require that the versions of the compiler used to build Perl and the the ones building the XS/libraries to match up enough that things behave well.

[genio]

You can yank the C compiler out of your own PATH unless you're installing things if that's your preference. However, some FFI modules and others will misbehave if there's no compiler available. https://metacpan.org/pod/FFI::Platypus::Bundle for example

[rkitover]

This is not an issue, but a requirement for Perl on Windows. In the unfortunate event that you have an alternate MinGW installed, you will have to be careful about your environment. There's no other way for Perl to function on Windows.

I respectfully disagree. Perl functions just fine without a compiler, for things involving perl and not installing modules. For the 99% of cases anyway, not including the use case you mentioned.

Quite a lot of people also use Perl as just a tool and don't even care about any non-core modules, many of which come pre-installed with Strawberry anyway.

When I was testing this, I actually had to spend some time searching for an XS module to build, because everything I tried was already pre-installed.

Please close this as there's simply no other way. Your work-around is to use the Portable installs and handle your own PATH how you like, but for the masses, this is how things have to be.

"This is how things have to be" why? There are many other simple alternatives to sticking a non-standard MinGW toolchain in the system global PATH by default. Which is actually quite rude. That is the actual issue.

For example, a shortcut could be installed for using cpan tools that does this. This is what Visual Studio does, I modify my own PowerShell profile to add Visual Studio tools to my PATH.

Or it could be an option that defaults to off, the user could easily modify their own PATH.

Or it could be a separate package entirely, with its own shortcut, etc..

Perl use requires XS modules and third party libraries for developers to be able to write code. XS modules and those third-party libraries require MinGW on Windows as that's what Strawberry is built on. They require that the versions of the compiler used to build Perl and the the ones building the XS/libraries to match up enough that things behave well.

Python on Windows is in a similar situation, it is built with Visual Studio and requires Visual Studio installed to build extensions. But they do not do this for you automatically and stick it in the PATH, though they easily could.

For that matter, why is Strawberry incompatible with the standard MinGW toolchain? I should be able to run something like:

choco install -y StrawberryPerl mingw

and have everything work.

And when I tried everything did in fact work with the standard MinGW gcc at least, some other things like gmake it does not come with.

Feel free to close this, I don't care about this that much, and I have a way to deal with it for myself which I described above, I just think it's wrong, from the perspective of Strawberry being a well-behaved Windows tool and development tool.

[genio]

It matters what version of MinGW the version of Strawberry you're using was built with. Many of them around that are installable on your version of Windows. They're not all built with the same MinGW. That version of MinGW from chocolatey would not work with, say, Strawberry Perl 5.16.

This isn't Python and wasn't built with Visual Studio, so that's not a great comparison. The installer for Strawberry installs a binary of the language as it was built at the time of release. In order to help you with all of the things I mentioned, it provides the packaged up MinGW it used as well.

Again, the fix here is to remove things out of the PATH that you don't want or to use the Portables and only put on the PATH what you want.

[rkitover]

It's true that the path is easily removable in your own environment, for example putting this line into your PowerShell $profile will do it:

$env:PATH = ($env:PATH -split ';' | ?{ $_ -notmatch '\\Strawberry\\c\\bin$' }) -join ';'

[boxerab]

Putting strawberry perl in the path is also a problem for me, as it adds it's own pkg-config binary, and I have my own version of pkg-config, so it messes up my GStreamer build. It should at least be an option during install, with default being to NOT add it to the path.

[genio]

Unfortunately, we can't account for every non-vanilla machine build out there. We need these paths in the environment to allow Perl to function as expected. Knowing how the install works and the paths it puts in your $env:PATH you can alter that path yourself to account for your machine setup after install.

Do note that you may run into issues with installing Perl modules that rely on those things being in the path and being what came with the install.

[boxerab]

Fair enough - how about a large warning during install, stating that the PATH will be modified which may affect the functioning of other programs. And put this in the Release notes too. In my case, after installing Strawberry Perl, my GStreamer build suddenly started failing, and I had no idea why.

[eur2fe]

I second this issue. Here is a little story why:

We have an internal toolchain for unit testing based on MinGW. We use lcov to get the code coverage, which requires Perl. When I upgraded the Perl dependency of our package manager to StrawberryPerl, gcov spit out a bunch of errors. It took me awhile to figure out what happened, but when I realized that StrawberryPerl ships with MinGW, it all made sense, because lcov happened to call the wrong version of gcov.

For somebody like me who merely upgrades a dependency, it is somewhat unexpected that StrawberryPerl is not just Perl, but a collection of tools including Perl. As there are probably many users who migrate from perl-with-an-incompatible-license version to StrawberryPerl, I think it would be great to provide an upgrade path.

I would like to see a StrawberryPerl light version that includes just the core elements of Perl. My gut feeling also tells me that the inclusion of an entire compiler package is going to bite back sooner or later. At the very least, we should get the MinGW folder out of the PATH variable. That would limit the problem that some components accidentally picks up an executable (or worse, just a DLL).

[genio]

The problem is that for Windows, MinGW is a core part of Perl and it has to be the same version of MinGW that Perl was built with. There is no fix to this other than managing your own PATH as we discussed above.

[sisyphus]

On Thu, Apr 22, 2021 at 11:33 PM eur2fe ***@***.***> wrote: I would like to see a StrawberryPerl light version that includes just the core elements of Perl.

You can, of course, just remove or hide (by renaming) Strawberry's "c" folder, and perl will still be functional. That will work because copies of the MinGW dlls that perl needs are also located in Strawberry's perl/bin folder. One of those dlls is libwinpthread-1.dll, which gcov also needs ... so even if you do get rid of Strawberry's MinGW installation, you're still faced with having 2 different (possibly incompatible ?) libwinpthread-1.dll files in your PATH .... unless you instead keep Strawberry's MinGW installation and get rid of that other MinGW (which is how I would be trying to arrange things). Having 2 different dlls with the same name in one's PATH is best avoided, if possible. It can sometimes be difficult (even impossible, as a worst case scenario) to have your app load the one that needs to be loaded What was the actual error you were getting before you worked out what was going wrong ? The other two MinGW dlls in perl/bin are libstdc++-6.dll and libgcc_s_seh-1.dll, though, depending upon which build of Strawberry Perl you have, the second of those 2 files might instead be named libgcc_s_dw2-1.dll or libgcc_s_sjlj-1.dll Cheers, Rob

[eur2fe]

I have read the discussion, and I understand that you want to keep MinGW in the distribution. On the other hand, we have users who have a requirement to choose an arbitrary compiler, which must not conflict with the MinGW distribution used by StrawberryPerl.

I think a solution that serves these two conflicting requirements is to not rely on modifying the system or user PATH variable (BTW, I like the installer modification of the system/user PATH variable to be optional).

Am I correct to assume that MinGW is included to compile stuff on the fly, such as XS modules? That would mean that only the child processes of perl.exe must be able to do so. A quick and dirty solution could be to modify the PATH at runtime, i.e. only in the environment of the child process to be launched for compilation.

[eur2fe]

@sisyphus: Thanks for the reply. I actually did not need any help, I just wanted to provide feedback from a corporate point of view. The thing is that someone at our company maintains perl packages, and that we combine many packages in an environment (including MinGW compilers) to do stuff. It just sucks when certain combinations break. Fiddling with the path may work at home, but it is not a good solution for us.

[eli-schwartz]

The Meson build system looks up dependencies using pkg-config, if pkg-config is available. If not, it will find some things using specialized system probe rules, or fallback to fetching the dependency as a wrapped subproject.

Strawberry Perl breaks this, because the non-functional pkg-config it installs claims that stuff like zlib is successfully found, but then that cannot actually be used during building, and unfortunately that means it didn't try to find a working version instead.

Why is this a problem, you say? Just remove it from your PATH temporarily.

Well, it is a problem because I never heard of Strawberry Perl in my life before, I do not use it, I do not want to use it, and I certainly don't want its pkg-config implementation. So why do I have it anyway? Because... a github actions CI image uses runs-on: windows-latest, and apparently, through the grace of Github, the "windows-latest" CI runner helpfully includes a variety of tools out of the box which includes... perl. Apparently Strawberry Perl at that.

I don't even need or use perl in this CI, but hey, thanks anyway. I guess now I know what Strawberry Perl is, but given the precise manner of my introduction to it, I suspect I'll try to avoid it in future.

This was annoying to debug and it really feels like I should not have to hack my CI because Github is popularizing your bad design decisions.

Please stop adding broken tools to the global environment, which are only intended to be used for a private local environment.

[karenetheridge]

your bad design decisions

The history of this thread contains ample explanation as to why the things that are installed are required.

I would suggest you not let Github Actions CI install things to your main environment; as you noted it installs quite a lot of things, and these may get in the way of your normal preferences.

[xclaesse]

I'm not sure how the pkg-config.bat can be useful to anyone:

PS C:\> pkg-config --libs zlib
-lz
PS C:\> pkg-config --cflags zlib

PS C:\> cat C:\Strawberry\c\lib\pkgconfig\zlib.pc
prefix=/usr/local
exec_prefix=/usr/local
libdir=${pcfiledir}/../../lib
sharedlibdir=${pcfiledir}/../../lib
includedir=${pcfiledir}/../../include

Name: zlib
Description: zlib compression library
Version: 1.2.11

Requires:
Libs: -L${libdir} -lz
Cflags: -I${includedir}

You'll never be able to find headers with that...

[bredelings]

you could solve the problem of polluting the PATH by adding mingw etc to the PATH only when running module compiles

That would be convenient for some users, and terribly inconvenient for others.

Which users is it terribly inconvenient for? Is it users that are installing PERL to get a mingw development environment?

If this is the case, I can see why it should not be part of a github install image.
And... maybe it should be removed from choco?
It sounds like it is not designed to be co-installed with anything?

[Leont]

Which users is it terribly inconvenient for? Is it users that are installing PERL to get a mingw development environment?

People who want a full Perl to work out of the box, one that can install modules they need to get their work done.

If this is the case, I can see why it should not be part of a github install image.

Because some people need a Perl that works on Windows?

And... maybe it should be removed from choco?
It sounds like it is not designed to be co-installed with anything?

What one really wants is a Chocolate Perl, that uses choco packages instead of bundling things.

It must be possible, but I'm guessing it to be a non-trivial amount of work.

[bredelings]

Which users is it terribly inconvenient for? Is it users that are installing PERL to get a mingw development environment?

People who want a full Perl to work out of the box, one that can install modules they need to get their work done.

I think there is some communication problem here. The suggestion was to modify the path only in the forked processes used to compile modules. So, it sounds like this would work fine for users that want to install modules to get their work done.

[eli-schwartz]

Ask github to put it later in path than the pkg-config you want to use.

Or modify the path yourself.

This is why the path environment variable is ordered.

On systems without a pkg-config, the correct outcome is that pkg-config is not detected, and the pkg-config method for dependency resolution is wholly skipped and other dependency resolution methods are chosen (foo-config.cmake, compiler probes for *.dll, etc.)

On systems without a proper pkg-config, but with Strawberry Perl, pkg-config.bat is found no matter where it is on the PATH, because it is the only one on the PATH. This despite that it is last on PATH, and Strawberry Perl's GCC is not detected. If Strawberry Perl's GCC were detected, maybe this wouldn't be such a problem, because Strawberry pkg-config.bat returns output which is only usable for Strawberry GCC, but which (I assume) is indeed usable for Strawberry GCC!

In fact, even if MingGW is not on the PATH, and only Strawberry perl.exe is on the PATH... pkg-config.bat is also on the PATH. You cannot select a subcomponent build to get just perl.exe but not the mingw toolchain! Previous advice in this thread about doing precisely this, is non-functional!

...

The general problem here is that Strawberry Perl is being recommended and used by projects that either want to provide a perl.exe for running perl scripts (Github Actions VM images for Windows) or require a perl.exe for running perl scripts and demand the user install one (an example of this would be the OpenSSL build system, which documents "we recommend Strawberry Perl, since unlike ActiveState Perl it comes with Win32/Console.pm").

The common issue shared by these people having problems is that they don't want "the Strawberry MinGW development environment for perl". They want a perl.exe interpreter (in Github's case, to provide it as a helpful service).

Unfortunately, the Strawberry Perl project appears to be of the very strong opinion that the goal of Strawberry Perl is to provide an integrated Windows Subsystem for Linux as an aid to unlocking the full power and flexibility of CPAN, which is extremely damaging to the use case of "I just want perl.exe without unexpected side effects".

Since the problematic side effect is shipping in the same directory as perl.exe, the only general purpose solution to fine-tuning your Windows install and disabling these side effects (after spending considerable time debugging the problem) is deleting the directory containing perl.exe from PATH, which means you no longer have perl, which may in the end be a reasonable tradeoff for the particular case of Github Actions if you never craved it to begin with.

...

Anecdotally, if I had to guess I'd expect many of the people having problems with cmake and meson finding a broken Strawberry pkg-config.bat had knowingly installed Strawberry Perl, but only did so because they needed to build OpenSSL, and OpenSSL requires a perl.exe (but not compiled XS modules from CPAN) and (perhaps unwisely) recommends Strawberry Perl to Windows users.

At least that (building OpenSSL) is apparently the reason why one meson project got so many "help, zlib.h cannot be found" reports from Windows users with pkg-config.bat installed, that the project added a special configure check to fatally error out if the word "strawberry" is in PATH...

[eli-schwartz]

@bredelings

As mentioned in the original bug report in 2019:

What I propose is that the mingw toolchain be stored in a different folder and only added to the PATH on the invocation of a module build toolchain: EU::MM, Module::Build, etc..

This has been flatly rejected for a long time running, although indeed no one has actually stated what it would break to do so.

[bredelings]

It sounds like it is still possible to move the pkg-config.bat out of the directory that contains perl.exe

[Leont]

I think there is some communication problem here.

I would agree.

The suggestion was to modify the path only in the forked processes used to compile modules. So, it sounds like this would work fine for users that want to install modules to get their work done.

It feels to me like you have a rather specific expectation of how the system works that is different from how it actually works.

What I propose is that the mingw toolchain be stored in a different folder and only added to the PATH on the invocation of a module build toolchain: EU::MM, Module::Build, etc..

This has been flatly rejected for a long time running, although indeed no one has actually stated what it would break to do so.

To turn that question around, what makes you think that would be the right place to fix this?

Also, that would be well outside of the scope of the Strawberry people, so I think you're getting annoyed at the wrong people ;-)

It sounds like it is still possible to move the pkg-config.bat out of the directory that contains perl.exe

Probably. That's likely the best workaround for now.

[sisyphus]

On Tue, Oct 12, 2021 at 6:01 AM Benjamin Redelings ***@***.***> wrote: It sounds like it is still possible to move the pkg-config.bat out of the directory that contains perl.exe

That is certainly possible. However, this pkg-config.bat is a pure perl implementation of pkg-config, and the logical place for it is therefore in perl/bin. ################

pkg-config --help

Name: PkgConfig - Pure-Perl Core-Only replacement for pkg-config ... ################ (Aside: I wonder what "Core-Only" means ... and whether that meaning is being overlooked in this thread.) I, too, have had problems in the past when the gcc toolchain finds Strawberry's pkg-config.bat during the building of a perl (Gtk) extension on Strawberry Perl. My solution was simply to ensure that my MSYS2 pkg-config.exe gets found first. Could it be (untested) that the best solution would be for the Strawberry project to do away with this pkg-config.bat and instead provide a ("proper ") pkg-config.exe, which has been built using the same gcc toolchain that ships with the Strawberry Perl bundle. In that case, the logical location for the pkg-config utility (ie pkg-config.exe) then becomes mingw/bin .... but, of course, if it's a pkg-config.exe that works correctly, then it doesn't matter where it's put.

[sisyphus]

Minor correction to my post: replace "mingw/bin" with "c/bin".

[shadowcat-mst]

Pretty much every suggestion that makes it a better dependency also makes it a worse end-user product and vice versa.

If somebody wanted to propose a patch set that would make the installer have a dependency-optimised mode as well as a user-deployment-optimised mode, and then we were to try and convince downstream projects like choco and github's default build to use that, that might be an interesting option.

They question then would be - what's the solution for people who want to use it as a dependency and be able to depend on cpan modules? - but I guess if we relegate the pkg-config.bat and friends into a separate 'extbin' or something in infrastructure mode they can just add that to their path temporarily while building said modules since that use case is likely to be people who Know What They're Doing, rather than the "possibly naive developer" and "infrastructure person who hadn't really thought about anything except perl.exe" cases that we're currently seeing fight each other.

Another possibility might be to simply have a "justperl" directory, install a second copy of the tools into there, and have infrastructure projects use that instead.

They key thing here from my point of view is that having the default experience for an end-user be as smooth as possible is something a lot of work was put it, and while I'd love to see everybody else's problems fixed as well, regressions in that smoothness of experience for the simple case aren't going to fly as a way to get there.

[eur2fe]

For a possible solution that would probably solve this issue for the majority of the users, you may want to take a look at Git for Windows, which includes the MSYS2 suite: Rather than adding the entire toolchain to the PATH variable (which would create lots of conflicts), the PATH is only modified to point to a folder containing stub executables. When I type 'git', the git.exe stub sets up the proper environment (which includes pointing the PATH to the entire toolchain) and launches the real git.exe.

[shadowcat-mst]

@eur2fe that only works if you fully control which executables are "top level". There are multiple different cpan installers - plus people will often run builds directly - so I'm sadly convinced that's just not going to work out here.

Or at least I spent quite a while pondering if there was somewhere I could shim stuff in that style that would actually work reliably for the "end-user developer" case and my approximate conclusion was "FML". That could be an option for an 'insfrastructure mode' type install, maybe, but at the point at which we're expecting the people doing the builds to be actually sysadmin-shaped I suspect just giving them full control will work out better overall.

(historical note: the installer used to offer a choice as to whether to leave PATH alone ... and the end result was regular confused people who'd unchecked that box during installation and then were confused as to why they couldn't just type 'perl' in a cmd.exe prompt ... much though I am sometimes frustrated at the extent to which this limits our available choices, I'd still rather not go back)

[eur2fe]

@shadowcat-mst: I am not suggesting that this is an optimal solution for everyone. Surely, it is nice if everything works out of the box for everyone. I am assuming that the most common scenario is to run perl.exe. And yes, even with my limited knowledge of Perl I can create scenarios where the stub approach does not work.

The problem remains that Strawberry Perl only achieves its full functionality at the expense of literally breaking Windows for certain users, which is why I think the correct way is to take a safe approach, i.e. remove all the conflicting executables/DLLs from being accessible via the PATH variable. This is the approach many popular packages use, such as Git, Python, etc.

[shadowcat-mst]

@eur2fe Yeah, which is why, as I said, I'm sure we'd accept a patch to add an infrastructure mode option to the installer code that provided for the scenarios you have in mind without screwing over the existing happy userbase.

If anybody wants to make proposals towards such a patch, I'm happy to help them figure out a suitable design.

[bredelings]

If anybody wants to make proposals towards such a patch, I'm happy to help them figure out a suitable design.

Seems reasonable. @xclaesse? @eli-schwartz?

[levicki]

Woudln't the best solution for this problem be to build Strawberry Perl with Visual Studio compiler going forward, and stop relying on and distributing MinGW toolchain with it if you don't want to go Git route and isolate your dependencies to not pollute the global system PATH?

For users who use Perl and also need to compile modules, just point them to download and install Build Tools for Visual Studio and provide a default .config for it with necessary tools selected for building Perl modules if they already don't a have suitable build / development environment set up.

Both Visual Studio Community and build tools are free (as in beer), and there's absolutely no reason not to use them to build binaries for Windows platform in 2021.

[sisyphus]

AFAIK, there's no problem building perl itself with those "Visual Studio Community and build tools".
I regularly build perl with Visual Studio 2019 without any problem.
However, Strawberry Perl also provides a number of third party C libraries (and associated perl extensions).

For example, can you point me to the documentation that tells me how to build the gmp library (https://gmplib.org) using those tools ?
(I think that's a rhetorical question with an answer of "no" ... but you'd definitely be doing me a favour if you could provide a link to such documentation.)

Also, perls built with Visual Studio are limited to having the double precision (8-byte) floating point type (NV).
With MinGW we have the option of having NVs of extended precision long double (10-byte) or __float128 (16-byte) types.
Of course, Strawberry Perl generally provides builds that have only the 8-byte type, but at least the options are always open if they keep using MinGW.

[eli-schwartz]

@levicki Alright, now I'm genuinely curious.

Your suggestion makes it sound like you have, at least once ever, found people using a mingw compilation environment because that was the only way they could conveniently find a build environment at all.

This would presumably be different from the stated purpose of that build environment, which is to provide a POSIX emulation layer.

Is that... Really a thing? TIL.

[eli-schwartz]

(@bredelings I'm not interested in learning the ins and outs of a project I don't use in order to fix work around a bug I am no longer -- after blacklisting it -- affected by.)

[xenu]

Both Visual Studio Community and build tools are free (as in beer), and there's absolutely no reason not to use them to build binaries for Windows platform in 2021.

They aren't free for everyone:

If you are an enterprise, your employees and contractors may not use the software to develop or test your applications, except for: (i) open source; (ii) Visual Studio extensions; (iii) device drivers for the Windows operating system; (iv) SQL Server development; and, (v) education purposes as permitted above.

An “enterprise” is any organization and its affiliates who collectively have either (a) more than 250 PCs or users or (b) one million U.S. dollars (or the equivalent in other currencies) in annual revenues, and “affiliates” means those entities that control (via majority ownership), are controlled by, or are under common control with an organization.

[levicki]

@sisyphus

For example, can you point me to the documentation that tells me how to build the gmp library (https://gmplib.org) using those tools?

That documentation should be provided by the GMP project owners and maintainers, not me.

However, from what I see on their website, they use assembly code which makes it less portable. Specifically x64 build for Windows seems to be impossible with assembler code because of calling convention difference which means you will have to build without assembler code (resulting in worse performance), or simply use a different library such as MPIR which is faster and supports Visual Studio builds out of the box.

As for your gripe about 10 byte long double, see this excellent explanation on why it doesn't make sense to use it in 2021. TL;DR -- you can certainly write and compile code that uses long double with Visual Studio C++ compiler, but it is heavily discouraged because of performance implications of using FPU code instead of SIMD vectors. If standard double is not sufficient, use fixed-range integral types.

Hope that helps.

@eli-schwartz

Alright, now I'm genuinely curious.

I did not say people use MinGW because they can't find free Visual Studio if that is what you are getting from my post.

What I said (or at least what I meant to say) is that Windows platform provides native C++ compiler toolchain. Therefore, if you are porting your project to Windows platform, then you should port it to native C++ compiler toolchain, not port your C++ compiler toolchain of choice with it, and then stick it in global PATH. Even if your intention is to provide free access to your project, the end result is user-hostile and in this case most users seem to be fellow developers.

@xenu

They aren't free for everyone:

If you are an "enterprise" as defined in your quote, then you also have Enterprise Agreement with Microsoft, and you are paying for Visual Studio Professional or Enterprise licenses so that is, in my opinion, a non-issue.

As for whether build tools are free to use, this license agreement is best I could find. Sadly, it is not really clear whether you can legally use them to build binaries for distribution without having at least one Visual Studio Community license.

In any case, Microsoft seems to be much more open-source friendly as of late so maybe ask them for help? Python, CMake, and Git can now be installed with Visual Studio (and are compiled with Visual Studio C++ compiler), I don't see why they would refuse to help bringing Perl in as well.

[genio]

@levicki You've greatly oversimplified the licensing issue with Microsoft Visual Studio. Suffice to say, you're not correct.

[genio]

Microsoft has finally updated their licensing for the Visual Studio Build Tools. https://developercommunity.visualstudio.com/t/CC-compiler-and-linker-free-CLI-only/10042178