Get Gentoo!
gentoo.org sites
gentoo.org Wiki Bugs Forums Packages
Planet Archives Sources
Infra Status
summaryrefslogtreecommitdiff
path: root/dev-util/mingw64-toolchain
Commit message (Collapse)AuthorAgeFilesLines
* dev-util/mingw64-toolchain: fix binutils build with c23 (gcc15)Ionen Wolkens2024-11-182-0/+94
| | | | | Closes: https://bugs.gentoo.org/943715 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: remove unused patchMichael Mair-Keimberger2024-10-131-63/+0
| | | | | Signed-off-by: Michael Mair-Keimberger <mmk@levelnine.at> Signed-off-by: Conrad Kostecki <conikost@gentoo.org>
* dev-util/mingw64-toolchain: drop 11.0.0_p2Ionen Wolkens2024-09-032-348/+0
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: Stabilize 12.0.0 x86, #935355Jakov Smolić2024-07-021-1/+1
| | | | Signed-off-by: Jakov Smolić <jsmolic@gentoo.org>
* dev-util/mingw64-toolchain: Stabilize 12.0.0 amd64, #935355Jakov Smolić2024-07-021-1/+1
| | | | Signed-off-by: Jakov Smolić <jsmolic@gentoo.org>
* dev-util/mingw64-toolchain: drop 11.0.1-r1Ionen Wolkens2024-06-062-372/+0
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: restore 12.0.0 keywordsIonen Wolkens2024-06-011-2/+1
| | | | | | | SEem pretty uneventful, old hacky wine-proton-7 still builds with it as-is too (well, with the patch for mingw-11 anyway). Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: add 12.0.0 (unkeyworded)Ionen Wolkens2024-05-302-0/+381
| | | | | | | | | | | | | | | Same gcc+binutils, only bumps runtime. Should be safe, but have not tested it much yet and will wait a bit to keyword and want to spare users from long rebuilds if anything needs fixing. Force msvcrt-os for now (upstream switch to ucrt by default), have not tried ucrt with wine at all and there may be things to consider to switch safely (but less of a hassle than with crossdev given we always bootstrap here). Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: fix ICE with -fno-omit-frame-pointerIonen Wolkens2024-05-212-0/+18
| | | | | | | | If there's a known fix, better to do it here than have every revdeps do workarounds. Closes: https://bugs.gentoo.org/932319 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* Revert "dev-util/mingw64-toolchain: add workaround for gcc14 ICE w/ mingw"Ionen Wolkens2024-05-211-3/+0
| | | | | | | | | This reverts commit b6ca4f9dc1b3e4f9e947e547f9cab2730502de52. A fix was found, so will patch gcc instead. Bug: https://bugs.gentoo.org/932319 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: add workaround for gcc14 ICE w/ mingwIonen Wolkens2024-05-201-0/+3
| | | | | Bug: https://bugs.gentoo.org/932319 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: restore keywords for 11.0.1Ionen Wolkens2024-05-101-2/+1
| | | | | | | Had hoped to get some feedback before wider testing but seems fine from using it a bit myself. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: filter -fstack-protector* againIonen Wolkens2024-05-092-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Used to be done because it was straight up broken (couldn't build), but now it's successfully causing problems and it's not obvious for upstreams to fix these issues with mingw. There may be real issues in dxvk & others, but support for this is new in mingw (also only partial), and believe using this can be considered too experimental/early "here". Still allowing it with USE=custom-cflags for those that really want it and don't mind if it breaks some components they don't use. Skipping revbump given it's an unusual configuration given users normally don't pass this in *FLAGS but rather rely on the toolchain's defaults. mingw64-toolchain-11.0.1 will also be keyworded in not that long for rebuilds. Only needed for mingw runtime, so the toolchain itself is still using it through the system-wide defaults. May revisit eventually. Not doing this for crossdev+mingw64-runtime main package again, these are for more expert use in the first place. Bug: https://bugs.gentoo.org/870136 Closes: https://bugs.gentoo.org/931512 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: IUSE=debug -> +stripIonen Wolkens2024-05-071-2/+2
| | | | | | | | Forgot but meant to do this on a bump to avoid rebuilds, but given this isn't keyworded yet there is little harm in doing it now. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: add IUSE=bin-symlinksIonen Wolkens2024-05-072-1/+34
| | | | | | | | Kept off-by-default given crossdev is still preferred for full featured mingw toolchain usage, just for anyone that wants it (also works out better with ccache). Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: add 11.0.1, unkeyworded for nowIonen Wolkens2024-05-072-0/+342
| | | | | | | mingw64-runtime-11.0.1 makes no difference for the wine use case, but includes gcc-14.1.0 and binutils-2.42 that need testing first. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* */*: inline mirror://sourceforgeLucio Sauer2024-04-301-1/+1
| | | | | | | bump copyright of touched ebuilds to 2024 Signed-off-by: Lucio Sauer <watermanpaint@posteo.net> Signed-off-by: Michał Górny <mgorny@gentoo.org>
* dev-util/mingw64-toolchain: filter -Wl,-z,* ... for CFLAGSIonen Wolkens2024-03-241-0/+5
| | | | | | | | | | | | | | | | | | | strip-unsupported-flags handles this fine in LDFLAGS, but -Wl,* are no-ops during compile-only tests (thus not stripped) and then if a package compiles and links anything at same time it fails. This used not to be a big problem but now that 23.0 profiles do -Wl,-z,pack-relative-relocs (mingw ld has no -z) this is hitting bashrc-mv users that tend to do CFLAGS="${LDFLAGS}" by default. Tempting to ignore it because of how wrong it is, but well. An alternate route could be to eventually have strip-flags and/or strip-unsupported-flags remove -Wl,* from non-LDFLAGS given this could affect more than mingw (e.g. switching to bfd when there is a lld-only option). Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: prevent sys/sdt.h (systemtap) detectionIonen Wolkens2024-02-221-0/+3
| | | | | | | | | | | | | Unsure which conditions are needed to reproduce exactly, (having dev-debug/systemtap is not enough) but failed for a user with USE=systemtap enabled globally (perhaps related to glibc[systemtap] or gcc[systemtap]). --disable-systemtap does not do anything to help here, the header is checked individually by libstdc++ and then fails given it's missing for the mingw target. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: prevent makeinfo usageIonen Wolkens2024-01-161-4/+5
| | | | | | | | | | | | | | | | | | | | This does not install .info pages (that is left to binutils+gcc real packages), so little reason to depend on texinfo(makeinfo) and generate them for nothing. Could possibly come back as an issue if use gcc snapshots (that lack pre-gen info pages), and unsure if this same workaround will work for gcc (currently only binutils is trying to use it). MAKEINFO=: on ./configure is not necessary (and is insufficient to stop usage given it is not respected in Makefiles), but it prevents a command not found QA notice. That aside, generally hard for texinfo to be missing unless depclean build deps, so BDEPEND would not have been too wasteful. Closes: https://bugs.gentoo.org/922230 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: unset DLLTOOL for crossIonen Wolkens2023-12-221-1/+1
| | | | | | | | Rarely set but, if it is, can result in using llvm-dlltool when it should be using mingw's, and ultimately fails. Closes: https://bugs.gentoo.org/920483 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: fix build with libcxx-17Ionen Wolkens2023-09-232-0/+64
| | | | | | | | | | | | | | | | | | | Meant to delay this until it'd be fixed in sys-devel/gcc, but issue unfortunately went under the radar. Tried a snapshot (13-20230916) but still seems broken the same way, and assume sys-devel/gcc likely still has issues too (not tested). For now no harm in just picking/rebasing PR#32249 which is sufficient for what is used here (tested on llvm-musl w/ default-libcxx-17). Technically patch could warrant a revbump like the PR did (and in ~arch), but feels too basic to be worth the extra churn and a long rebuild. Closes: https://bugs.gentoo.org/914565 Closes: https://github.com/gentoo/gentoo/pull/32249 Co-Authored-By: Violet Purcell <vimproved@inventati.org> Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: drop 10.0.0_p1-r2, 11.0.0Ionen Wolkens2023-09-127-733/+0
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: Stabilize 11.0.0_p2 amd64, #913091Sam James2023-08-271-1/+1
| | | | Signed-off-by: Sam James <sam@gentoo.org>
* dev-util/mingw64-toolchain: Stabilize 11.0.0_p2 x86, #913091Sam James2023-08-271-1/+1
| | | | Signed-off-by: Sam James <sam@gentoo.org>
* dev-util/mingw64-toolchain: restore keywords for 11.0.0_p2Ionen Wolkens2023-08-031-2/+1
| | | | | | | binutils:2.41 is keyworded in ~arch too now, and have not seen any issues with wine yet, so let's try it. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: drop 11.0.0_p1Ionen Wolkens2023-08-031-327/+0
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: add 11.0.0_p2 w/ bin-2.41 (unkeyworded)Ionen Wolkens2023-07-302-0/+331
| | | | | | | | Unlike _p1 will likely keyword (and later stable) this one, but have not really tested yet nor looked into if binutils did any notable changes with mingw, so keep unkeyworded for a bit. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: add 11.0.0_p1 w/ gcc-13.2 (unkeyworded)Ionen Wolkens2023-07-282-0/+328
| | | | | | | | | | No known issues at the moment (albeit barely tested), primarily unkeyworded to skip a slow rebuild until the bump can be more useful (e.g. also bump binutils or runtime, and do a _p2). May keyword earlier if it is known to fix notable issues with Wine. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: pass V=1 for binutilsIonen Wolkens2023-07-032-4/+4
| | | | | | | | Overlooked that parts of binutils weren't verbose, so do like the binutils ebuild does. Harmless for gcc/runtime, so can just put it in the generic function. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: pass -mno-avx for mingw crossIonen Wolkens2023-06-262-0/+14
| | | | | | | | | | | | | | | | | | | | AVX issues with mingw-gcc aren't exactly new, e.g. https://bugs.winehq.org/show_bug.cgi?id=45289 Been known to cause issues with dxvk too, albeit unsure if that's still relevant as issues are scattered/lost. Newly, >=wine-8.10 is likely to crash doing anything at all 32bit if used -march=native (w/ avx) and 32bit (e.g. `WINEARCH=win32 winecfg`). Adding this to every packages using mingw as a precaution, not believed there is much to gain from keeping AVX given the fragility here. May revisit eventually with a newer GCC. Not known to have caused issues with this package in particular (unlike wine/dxvk), so skipping a slow rebuild revbump. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: Stabilize 11.0.0 x86, #907368Arthur Zamarin2023-05-291-1/+1
| | | | Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
* dev-util/mingw64-toolchain: Stabilize 11.0.0 amd64, #907368Sam James2023-05-291-1/+1
| | | | Signed-off-by: Sam James <sam@gentoo.org>
* dev-util/mingw64-toolchain: use -j1 for make installIonen Wolkens2023-05-182-3/+5
| | | | | | | | | | Matches the change from bug #906155. This may potentially not be affected with what it builds, but all these packages have a tendendency to be fragile in that regard and there's not much to gain from threads on install. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: drop 10.0.0_p4Ionen Wolkens2023-05-111-321/+0
| | | | Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: add 11.0.0Ionen Wolkens2023-04-292-0/+318
| | | | | | | | | | | | | | | Also remove two obsolete flags filters: * -fstack-clash-protection (bug #758914): ICE was fixed, if still run into this then updating gcc to a newer _p* snapshot should sort it (alternatively, use released >=gcc-13.1.0) * -fstack-protector* (bug #870136): mingw64-runtime-11.0.0 adds its own (partial) ssp support, allowing -D_FORTIFY_SOURCE=3 and -fstack-protector-strong without libssp. Using these to build Wine currently still leads to failure, but we can allow it here. Bug: https://bugs.gentoo.org/758914 Bug: https://bugs.gentoo.org/870136 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: drop 10.0.0_p2, 10.0.0_p3Ionen Wolkens2023-04-263-638/+0
| | | | | | Never keyworded testing versions. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: add 10.0.0_p4 w/ gcc-13.1.0 (keyworded)Ionen Wolkens2023-04-262-0/+322
| | | | | | | | Been using _p3 with a bit earlier 13 pre-release + binutils-2.40 with Wine for a bit and no known issues at the moment. Closes: https://bugs.gentoo.org/898778 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: add 10.0.0_p3 (unkeyworded w/ gcc13)Ionen Wolkens2023-04-183-0/+354
| | | | | | | | Also includes a binutils-2.40 backport needed for dxvk. Will likely keyword in _p4 whenever 13 is released (non-snapshot). Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: cleanup alternate binutils-2.40 src_uriIonen Wolkens2023-02-011-2/+1
| | | | | | Was used because .xz was missing from mirror://, but it's there now. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: add 10.0.0_p2 unkeywordedIonen Wolkens2023-01-152-0/+316
| | | | | | | | | | | | | | | For testing binutils-2.40, but really only unkeyworded because hoping to bump something else at same time (runtime or gcc) before exposing to most users due to the long build time. Also: * switch to --with-gcc-major-version-only, unimportent here but doesn't hurt to be consistent with system's * explicitly filter-lto regardless of custom-cflags as it's guaranteed to not work (would need a USE=lto, and perhaps still skip for mingw static libs as this is fragile) Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: use 32bit wrapper for gas+cpp tooIonen Wolkens2022-11-121-1/+2
| | | | | | | | | | | | Overlooked given gcc normally calls AS the right way itself, but >=wine-7.21 started to use it directly. cpp wrapper isn't needed for wine, but do it anyway to ensure proper macro tests everywhere. Sorry for the large rebuild over this. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: handle two race condition issuesIonen Wolkens2022-11-042-1/+27
| | | | | | | | | Using same --shuffle seed as bug #879537, ran into two different issues. First missing lib32/lib64 dirs when building out-of-source then the missing msvcr*_extra dependency. Closes: https://bugs.gentoo.org/879537 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: filter -mfunction-return=thunk for mingwIonen Wolkens2022-10-301-0/+1
| | | | | | | | | Unfortunately mingw doesn't play well with many security/mitigation flags. May need to consider a mingw.eclass if keep adding more of these to every ebuilds using it. Closes: https://bugs.gentoo.org/878849 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: filter -fstack-clash-protectionIonen Wolkens2022-10-231-0/+1
| | | | | Bug: https://bugs.gentoo.org/758914 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: drop 10.0.0-r2Ionen Wolkens2022-09-273-337/+0
| | | | | | | | Not seeing a motivation to keep/maintain old gcc/binutils with this package for very long. If regression testing is really needed, there's crossdev. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: import drop cflags patch from gccIonen Wolkens2022-09-272-0/+24
| | | | | | | | | Tested this before and it built fine anyway, so thought it wasn't needed for mingw64-toolchain (despite --disabled-bootstrap) -- but seen a user run into it and seems I may have tested wrong back then. Bug: https://bugs.gentoo.org/849722 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: fix lto againIonen Wolkens2022-09-162-6/+4
| | | | | | | | | | | | | | Was wondering why AR was looking for the lto plugin in a non-existing bfd-plugins directory before, turned out it was because gcc resolved its location differently when set as a symlink. In commit c4262506ff492b96cddccb15e1fe1842d8d5a626, reverted to using upstream's intended hardlink but didn't notice this change in behavior and it broke lto again. Bug: https://bugs.gentoo.org/854516 Fixes: c4262506ff492b96cddccb15e1fe1842d8d5a626 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: adjust postinst elogIonen Wolkens2022-09-162-2/+2
| | | | | | | Sounded a bit like doing this was recommended rather than only for a as-needed basis. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
* dev-util/mingw64-toolchain: stabilize 10.0.0_p1 for amd64, x86Ionen Wolkens2022-09-161-1/+1
| | | | | | | | gcc-12/binutils-2.39 been tested more than 11/2.37 lately due to working on new ebuilds and want to get rid of 2.37, should be no reasons to hold this back Signed-off-by: Ionen Wolkens <ionen@gentoo.org>