| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Jakov Smolić <jsmolic@gentoo.org>
|
|
|
|
| |
Signed-off-by: Jakov Smolić <jsmolic@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
Bug: https://bugs.gentoo.org/932319
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
bump copyright of touched ebuilds to 2024
Signed-off-by: Lucio Sauer <watermanpaint@posteo.net>
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
Never keyworded testing versions.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
Was used because .xz was missing from mirror://, but it's there now.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
Bug: https://bugs.gentoo.org/758914
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
Sounded a bit like doing this was recommended rather
than only for a as-needed basis.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit d06a9cf2f29ca13694007493173a9ebe304005de.
This turned out to be fine, was misled that it may have leaked
to gcc's own libraries rather than just mingw's crt.
Still require filtering ssp on every mingw packages though,
strip-unsupported-flags can't pickup that this will fail with
a basic `int main(void) { return 0; }` compiler test.
Closes: https://bugs.gentoo.org/870136
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 26b669479490ec1d679bdbd38b836d6782f1e6c0.
Will try to get libssp to work, better reverted+failing for now given
this can create a unusable build if used ssp. Could filter further to
include gcc but will also need to filter on about every mingw packages.
For those just wanting this to work meanwhile, just don't enable ssp
on neither this nor wine.
Bug: https://bugs.gentoo.org/870136
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
| |
Closes: https://bugs.gentoo.org/870136
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|