gcc: Use WinLibs build and update to 11.2.0

[niheaven]

Change to WInLibs build and update to 11.2.0

Fix #1752 and close #1761

[github-actions]

All changes look good.

Wait for review from human collaborators.

gcc

• Description
• License
• Hashes
• Checkver
• Autoupdate
• Autoupdate Hash Extraction

[rashil2000]

Wow, this looks much much cleaner

[chawyehsu]

I don't think this is the right way to fix the gcc package, people were using MSYS2's mingw64 build may encounter compiling issues because of the compiler changes. These two distributions have differences in the compiler building settings.

There are many different MinGW/GCC distributions, and MSYS2's is the most widely used one because it's packaged by MSYS2, and is fully open-sourced and maintained. You can even choose any other distributions like nuwen's or mstorsjo's I mentioned in #1752 (comment) if it's that simple to fix it by changing distribution.

P.S. the change of the version number is also a breaking change

[niheaven]

I move original one to Versions bucket and if someone request it, we can move it back.

This version can be updated normally and let's wait for user's feedback.

[rashil2000]

I agree that this might be a breaking change - for that we can redirect users to the Versions bucket as @niheaven said.

However, I strongly believe Scoop should not be used to download MSYS2 packages - from a maintenance perspective, it's impossible to keep track of individual versions of the 15-20 different download URLs there. Pacman (widely touted as the most respected package manager out there) in MSYS2 handles dependency trees beautifully; if people need MSYS2 tools they should use it.

It's a similar argument to why Scoop isn't (and shouldn't be) used to download/manage NPM packages, or PIP packages - these are far better managed by their respective package managers.

If applications provide standalone builds (like this WinLibs does), we can use it freely and the manifest will even get autoupdated.

One more problem - currently we have around 10 different manifests in Main which individually download the MSYS2 Runtime - this leads to unnecessary bloat. It might also cause inter-compatibility if someone uses tools from different runtime versions - for example openssh and diffutils.

[pratikpc]

@chawyehsu I personally think we should add Nuwen builds to Scoop as well. They are also pretty popular as far as I know

[rashil2000]

Nuwen's package is only 64bit and does not contain many useful utilities - as mentioned here https://github.com/chawyehsu/dorado#featured-apps

We can add a llvm-mingw.json as well.

[pratikpc]

@rashil2000 it contains both GDB and make.

STL even mentions both in utilities section

Even in 2016 they had both of them

http://web.archive.org/web/20160202170442/https://nuwen.net/mingw.html

[chawyehsu]

Nuwen's package is only 64bit and does not contain many useful utilities - as mentioned here

In fact it does contain some utilities and libraries, you can look at STL's website, what I did for the nuwen's package in my bucket is for minimalist. My variant contains only the essentials section, so that I can install other utilities separately via scoop such as main/gdb, main/make, as per my needs.

I personally think we should add Nuwen builds to Scoop as well.

I am neutral on this. It's ok to add variant builds, but I believe they should all be added into this main bucket instead of the Version bucket, since they are not different versions of the same distribution, but are different distributions with different names. And that's why I mentioned above that it's not the right way of changing gcc.json to the winlibs build, because actually it may be a new package adding to the main bucket, llvm-mingw included.

gcc.json has been changed to winlibs build, then how about gdb.json? Should it be changed to use nuwen build's gdb binary? They were binding to MSYS2, but now I have no idea.

[rashil2000]

The Win Libs distro used in gcc.json includes GDB, Make, Binutils, LLVM etc. everything.

If we want to isolate tools instead (i.e. separate manifests for each tool - GCC, GDB, Binutils, Make etc.), we can look at Win Builds - http://win-builds.org/doku.php/1.5.0_packages - they provide independent binary sources for each.

[pratikpc]

If it includes LLVM then that's a bit of overkill to be honest.

[rashil2000]

That's why it's a distro 😜

That's why I pointed at isolated tools, if they're more suitable.

[pratikpc]

Yeah we should check those out in that case.

Installing GCC and finding LLVM in your path is entertaining.

[rashil2000]

It doesn't put LLVM in path though, at least not this manifest. These are the binaries:

addr2line.exe
ar.exe
as.exe
c++.exe
c++filt.exe
cpp.exe
dlltool.exe
dllwrap.exe
dos2unix.exe
doxygen.exe
elfedit.exe
g++.exe
gcc-ar.exe
gcc-nm.exe
gcc-ranlib.exe
gcc.exe
gcov-dump.exe
gcov-tool.exe
gcov.exe
gdb.exe
gdbserver.exe
gdc.exe
gendef.exe
genidl.exe
gfortran.exe
gprof.exe
iconv.exe
ld.bfd.exe
ld.exe
lto-dump.exe
mac2unix.exe
mingw32-make.exe
ninja.exe
nm.exe
objcopy.exe
objdump.exe
pexports.exe
ranlib.exe
readelf.exe
size.exe
strings.exe
strip.exe
unix2dos.exe
unix2mac.exe
widl.exe
windmc.exe
windres.exe

[pratikpc]

ninja.exe

Now this is an odd choice

[niheaven]

For LLVM, see versions/gcc-llvm.

Versions is for alternative versions, not old, not pre, just ALTERNATIVE, that you can have a different choice: different version, different edition, different build.

Main is for most used ones, and IMO, if MSYS2's is more convenient to maintained, it should be here, and this one should go to Versions

[rashil2000]

The gcc-llvm in Versions (winlibs) is different from the one being discussed here (mstorsjo).

MSYS2's version is most popular, but is unmanageable outside of pacman.

Besides, the official website for MinGW-w64 mentions standalone sources for downloading too - win-builds.org.

[niheaven]

Do you really need a GCC version 4.8.3-2? Win-builds' latest update is in 2015/11/28, and all packages there are outdated.

gcc-llvm in Versions is the same build in WinLibs with LLVM, just for someone that need both GCC and LLVM.

[rashil2000]

Darn! Don't know how I missed it. Their sources are heavily out of date. My bad.

We should stick to Winlibs then.

[chawyehsu]

Versions is for alternative versions, not old, not pre, just ALTERNATIVE, that you can have a different choice: different version, different edition, different build.

This is not true. The Versions bucket was specifically for different actual versions, such as php5 and php6, or the pre-release versions like alpha/beta/nightly/preview. It is not for variants! Then why hugo-extended, git-with-openssh, gradle-bin, rustup-msvc, neovim and etc. were stayed in the main bucket if you believe it's for alternative because you've found there are many mingw/gcc variants...

This breaks the philosophy I think.

[rashil2000]

I agree with @chawyehsu

Only unstable, old, or development builds of apps should stay in Versions (this includes many of the Nightlies currently present in Main and Extras).

If there are two variants of a particular application, (rust-msvc or rust-gnu, llvm-mingw or nuwen-mingw), they all are good contenders for Main.

[niheaven]

See https://github.com/ScoopInstaller/Versions description. I think why there're so many alternative apps or variants in Main bucket is that Versions bucket is unmaintained for an exceptionally long time. We need a discussion for manifests reorganization and clarify each bucket's entrance criteria.

[rashil2000]

If it includes LLVM then that's a bit of overkill to be honest.

I was wrong about this. The manifest added in this PR by @niheaven uses these links, which does NOT contain LLVM stuff: