Package Details: mingw-w64-gcc 9.3.0-1

Git Clone URL: https://aur.archlinux.org/mingw-w64-gcc.git (read-only, click to copy)
Package Base: mingw-w64-gcc
Description: Cross GCC for the MinGW-w64 cross-compiler
Upstream URL: https://gcc.gnu.org
Licenses: GPL, custom, LGPL, FDL
Groups: mingw-w64, mingw-w64-toolchain
Provides: mingw-w64-gcc-base
Submitter: Barthalion
Maintainer: xantares
Last Packager: xantares
Votes: 54
Popularity: 2.00
First Submitted: 2018-01-07 17:33
Last Updated: 2020-03-13 20:37

Required by (190)

Sources (3)

Pinned Comments

xantares commented on 2018-03-07 17:54

To install this package from source I recommend to use:

aurman -S --noedit --solution_way --pgp_fetch mingw-w64-gcc

For a binary install I recommend to use Martchus ownstuff repo:

https://wiki.archlinux.org/index.php/unofficial_user_repositories#ownstuff

Latest Comments

1 2 3 4 5 6 ... Next › Last »

Martchus commented on 2020-02-10 18:41

@xantares I suppose I'll be busy when GCC 10 comes out. At least too busy to rebuild all mingw-w64 package to use DW2 exception handling and fix possible build errors. So I guess I'll be using SJLJ a little bit longer in my binary repository and do the rebuild probably in June. I see no problem if you already enable DW2 when updating the AUR package to GCC 10. Just be aware that I'll need a little bit longer to adapt. But then I can finally add rust to update librsvg.


Because I've read about adding an interactive option in the previous comments: It is generally possible to use an environment variable for making things configurable. One can then define this variable in makepkg.conf to override the default. It might also make sense to simply provide an alternative PKGBUILD, e.g. mingw-w64-gcc-win32.

lberrymage commented on 2019-10-17 00:39

Thank you, that does make sense. I just didn't see anything in the wiki page on package guidelines.

Edit: I take that last sentence back. For anyone who stumbles across this and wishes to know where this is stated officially: https://wiki.archlinux.org/index.php/Creating_packages#Warnings

Morganamilo commented on 2019-10-17 00:35

PKGBUILDS should never be interactive

lberrymage commented on 2019-10-17 00:34

Would the maintainer be interested in putting an interactive option in the PKGBUILD to decide whether to build the package with posix or win32 thread support? It defaults to posix, and this can easily be changed in the PKGBUILD, but an interactive option would be nice for those of us who use AUR helpers primarily.

Icemole commented on 2019-09-29 13:02

So if I understood it correctly, I should install first base and then this package, right? I mean, the installation is not automated, right? Sorry for the newbie questions but I'm still learning how to use the AUR effectively.

xantares commented on 2019-09-29 12:59

@icemole, mingw-w64-gcc-base is built first, then mingw-w64-gcc, which replaces it (they conflict each other)

Icemole commented on 2019-09-29 12:36

@xantares ok, so should I install mingw-w64-gcc-base as well and then delete it? Or keep it installed along with this package?

xantares commented on 2019-09-29 12:21

@icemole mingw-w64-gcc-base is the first stage of bootstrap then it's replaced by mingw-w64-gcc

Icemole commented on 2019-09-29 10:31

It says I need to install mingw-w64-gcc-base as well as this package. I was using yay. Shouldn't it be considered a dependency, or am I doing something wrong?

Edit: Output of yay:

[...]
==> Lacking dependencies:
 -> mingw-w64-gcc-base
==> ERROR: some dependencies could not be solved.
Error making: mingw-w64-crt

Martchus commented on 2019-09-07 12:07

I guess I can scrap the plan of untieing the architectures on the next rebuild. It would work in theory to automatically create distinct packages by using some regex magic in my build scripts. However, my repo would then be unusable for anybody who needs additional mingw-64 packages. So I'll just keep them together.

But I still need to mess with the sources to increment the pkgrel of the packages. Previously I sometimes "added 0.1" to the version so it is still lower than the next version the maintainer would possibly update the package to. It will look very ugly if then every package has such a weird pkgrel but it is the best solution I can think of. Other ideas are welcome but I think we can forget that every maintainer will update all of the packages accordingly.