[windows-2022] Please remove C:\Strawberry\c\bin from PATH

[galeksandrp]

Description

Some programming languages maintainers love, just love to redistribute GCC toolchain. Some sons of devils* even add it to PATH, borking some innocent dev pipeline.

Don't be bad, cleanup the PATH.

*Do community policy allow this description of Strawberry Perl Windows mantainers?

Virtual environments affected

• Ubuntu 18.04
• Ubuntu 20.04
• macOS 10.15
• macOS 11
• macOS 12
• Windows Server 2019
• Windows Server 2022

Image version and build link

20220426.1

Is it regression?

No response

Expected behavior

I expect do not have not mingw-w64 GCC toolchain in PATH because GCC toolchain just like wife - it's hard to find one compatible and easy to broke.

Actual behavior

Strawberry abusing my Chocolatey PATH.*

*Toilet joke

Repro steps

1. choco uninstall -y mingw
2. get-command gcc

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     gcc.exe                                            0.0.0.0    C:\Strawberry\c\bin\gcc.exe

[miketimofeev]

@galeksandrp nice meme! I'm afraid we can't easily remove strawberry perl from the path due to historical reasons. Many users will be broken if we do this — for example, this was the issue when we occasionally messed up the path #123
The only option I see here is to move perl symlink to some other place in the path and do not expose the whole directory to the path.

[galeksandrp]

@miketimofeev Actually, I don't request removing

• C:\Strawberry\perl\site\bin
• C:\Strawberry\perl\bin where C:\Strawberry\perl\bin\perl.exe is

from PATH, I ask for removing only

• C:\Strawberry\c\bin where C:\Strawberry\c\bin\gcc.exe is.

I'm afraid I'm not so tight with perl so I don't know if removing perl's GCC toolchain from PATH destroys perl ability to compile native modules from CPAN or something.

C:\Program Files\PowerShell\7;C:\Program Files\MongoDB\Server\5.0\bin;C:\aliyun-cli;C:\vcpkg;C:\Program Files (x86)\NSIS\;C:\tools\zstd;C:\Program Files\Mercurial\;C:\hostedtoolcache\windows\stack\2.7.5\x64;C:\cabal\bin;C:\\ghcup\bin;C:\tools\ghc-9.2.2\bin;C:\Program Files\dotnet;C:\mysql\bin;C:\Program Files\R\R-4.2.0\bin\x64;C:\SeleniumWebDrivers\GeckoDriver;C:\Program Files (x86)\sbt\bin;C:\Program Files (x86)\GitHub CLI;C:\Program Files\Git\bin;C:\Program Files (x86)\pipx_bin;C:\hostedtoolcache\windows\go\1.17.9\x64\bin;C:\hostedtoolcache\windows\Python\3.9.12\x64\Scripts;C:\hostedtoolcache\windows\Python\3.9.12\x64;C:\hostedtoolcache\windows\Ruby\3.0.4\x64\bin;C:\tools\kotlinc\bin;C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\8.0.322-6\x64\bin;C:\npm\prefix;C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin;C:\ProgramData\kind;C:\Program Files\Microsoft\jdk-11.0.12.7-hotspot\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\dotnet\;C:\ProgramData\Chocolatey\bin;C:\Program Files\Docker;C:\Program Files\PowerShell\7\;C:\Program Files\Microsoft\Web Platform Installer\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;C:\Program Files\Microsoft SQL Server\150\Tools\Binn\;C:\Program Files\nodejs\;C:\Program Files\OpenSSL\bin;C:\Strawberry\c\bin;C:\Strawberry\perl\site\bin;C:\Strawberry\perl\bin;C:\ProgramData\chocolatey\lib\pulumi\tools\Pulumi\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files\CMake\bin;C:\ProgramData\chocolatey\lib\maven\apache-maven-3.8.5\bin;C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code;C:\Program Files\Microsoft SDKs\Service Fabric\Tools\ServiceFabricLocalClusterManager;C:\Program Files\Git\cmd;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\usr\bin;C:\Program Files\GitHub CLI\;c:\tools\php;C:\Program Files (x86)\sbt\bin;C:\SeleniumWebDrivers\ChromeDriver\;C:\SeleniumWebDrivers\EdgeDriver\;C:\Program Files\Amazon\AWSCLIV2\;C:\Program Files\Amazon\SessionManagerPlugin\bin\;C:\Program Files\Amazon\AWSSAMCLI\bin\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\LLVM\bin;C:\Users\runneradmin\.dotnet\tools;C:\Users\runneradmin\.cargo\bin;C:\Users\runneradmin\AppData\Local\Microsoft\WindowsApps

[mikhailkoliada]

@galeksandrp Hi!

We can’t remove strawberry toolchain from search paths. While Perl is mostly arch-independent in terms of modules, there are also so-called PerlXS modules which (ab)use C/CXX code extensions, plus, strawberry’s toolchain is incompatible with mingw one (and vice versa).
That said, you have to manually eliminate it if you still need to.

Given that we have nothing to do here I am going to close the issue, but feel free to reach us out again.

[mariusgreuel]

@miketimofeev Can you please reconsider removing Strawberry Perls MinGW distribution from the runners PATH, even if that breaks PerlXS modules?

Having an entire MinGW distribution in the PATH causes all sorts of problems depending on DLL search path order and files being searched for. I have seen problems due to Strawberry Perl pop up consistently, from linkers picking up incompatible libraries, but also hard-to-debug application crashes because executables loaded some incompatible DLL from the Strawberry Perl path. Even CMake is configuring Strawberry Perls libraries when compiling for MSVC: avrdudes/avrdude#1196

Other applications (such as Git for Windows) know how to hide their MinGW distribution properly. They do this for a reason.
The dirty workaround the Strawberry Perl devs implemented comes at the expense and time of many other developers that do not even use Perl. Strawberry Perl had plenty of time to fix this blunder: StrawberryPerl/Perl-Dist-Strawberry#11

[eli-schwartz]

We can’t remove strawberry toolchain from search paths. While Perl is mostly arch-independent in terms of modules, there are also so-called PerlXS modules which (ab)use C/CXX code extensions, plus, strawberry’s toolchain is incompatible with mingw one (and vice versa).
That said, you have to manually eliminate it if you still need to.

@mikhailkoliada,

This seems fairly broken as a concept.

What's the purpose of Strawberry Perl in Github Actions? To provide a full-fledged mingw userland and a perl to go with it (that by the way causes build systems to misdetect the compiler and see Strawberry GCC instead of MSVC!!!) or to provide people with a perl interpreter for the use of running perl scripts?

Which use case is more common? People needing a perl interpreter, or people building PerlXS modules in Github Actions? Why are you optimizing for the latter case, while breaking the former case?

Why, if I use Github Actions to build some C and Python code, and I never knowingly use Perl and didn't ask for it to be installed, do I get my C and Python code attempting to build against Strawberry Perl's private mingw userland? Seriously? What the heck?

Quite frankly it is embarrassing to be told "why yes, our CI images are broken by default, and it is the responsibility of people who have never heard of the perl programming language in the first place to go remove Perl from their build environment in order to stop accidentally building their software against Perl". What kind of footgun is this anyway?

(Yeah, yeah, I have heard of Perl before, I'm not the most confused of the users I'm talking about. But. It's things like this that make me wish I didn't know what Perl is.)

The inclusion of a broken toolchain just... sprinkled... all over the default PATH has been a bug for years, and messed people up for years. It would be great if that were to be solved instead of handwaved away.

I'm afraid we can't easily remove strawberry perl from the path due to historical reasons. Many users will be broken if we do this — for example, this was the issue when we occasionally messed up the path

@miketimofeev,

I'm sorry to hear that messing with the path sometimes caused issues for Perl users wanting a specific Perl.

But I really don't think that's my problem as a non-Perl user, who doesn't want perl at all. I don't care if unused things are in the Actions runner $PATH, if I don't have to use them.

But it's really unfair to have broken stuff in the PATH that actively breaks CI or causes it to produce truly bizarre results. And it's really unfair to tell lots of people "in order to have minimally functional CI, you need to go delete some preinstalled stuff which you weren't using".

I would like Github Actions to provide some solution that doesn't break non-Perl users by default. Breaking the build should be something you opt into.

Breaking the majority of users because "we cannot regress for the minority of PerlXS users" is not a good excuse. This would be true even if we don't count the fact that PerlXS users possess the domain specific knowledge to configure PerlXS to work, while non-Perl users don't usually possess the domain specific knowledge to deconfigure PerlXS.

[CyberShadow]

If you try to run patch on GitHub Actions on Windows, the binary that gets picked up is C:\Strawberry\c\bin\patch.exe. (Posting this here as currently there are zero hits on Google for that path.)

That version of patch.exe is something very non-standard, and it fails with Assertation failed! [sic] when given a standard unified diff.

Workaround:

    - name: Set up PATH on Windows
      # Needed to use GNU patch instead of Strawberry Perl patch
      if: runner.os == 'Windows'
      run: echo "C:\Program Files\Git\usr\bin" >> $env:GITHUB_PATH

[dwidener]

I've been having a hell of a time getting Qt configured on my Windows machine, with a whole bunch of assorted errors during the configuration process. I finally tracked the problem down to this exact issue: the StrawberryPerl MinGW toolchain lurking in PATH was interfering with the MinGW toolchain shipped with Qt. This was an extremely frustrating couple of days, and only now after finally nuking StrawberryPerl's C directory from my toolchain Qt is building just fine.

Now that ActiveStatePerl has gone pay-to-play, StrawberryPerl is the only convenient FOSS Perl interpreter left for Windows. I only need Perl for system requirements for other software. I definitely don't need anything specifically for PerlXS development, and I suspect a lot of other people are in the same boat. At bare minimum, there should be an installer configuration option that asks the user whether or not to slap StrawberryPerl's MinGW into PATH, because for a lot of users that will not be what they want.