| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
The has_version is not *necessary* but will make it easier to
know it's safe to drop when it becomes essentially a no-op.
Bug: https://bugs.gentoo.org/931623
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Bug: https://bugs.gentoo.org/931623
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Hoping it will be a short-lived and that this will be improved/fixed
in clang itself.
(have not tried nor looked at qtwebengine:5)
For some rough explanation from the little I get from this:
clang-18 added -mevex512 (missing from 17), and then -march=native
is a bit quirky in that unlike -march=exact it goes out of its way
to disable it resulting in e.g.
-march=skylake -mavx512f = -mevex512 is auto-enabled
-march=skylake -mevex512 = not "enabled" but can be used
-march=native(skylake) -mavx512f = forced off(!)
And then units that use avx512 / pass -mavx512f (for use with runtime
cpu detection) end in build failure without evex512.
Always passing -mevex512 on a machine without avx512 "seems" safe,
it does not even set __EVEX512__ and believe won't use any avx512
instructions on a whim (__EVEX512__ does get set if add -mavx512f).
Or at least my skylake (not skylake-x) passes test + can use the
qtwebengine built that way.
Considered passing only for files that need it at first with a patch
(sounded safer), but chromium's Gn files don't have a variable to test
clang version that I could see (or at least not in old qtwebengine) and
didn't want this to become more involved nor use conditional patching.
The !avx512 check may not be super necessary, but have not dug into
the implications of forcing it when avx512 is actually enabled (sounds
there are cases where it needs to be off, leaving it to compiler).
Bug: https://bugs.gentoo.org/931623
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Needs more looking into but want a quick workaround before 6.7.1
releases with clang users having started to use 18.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Unknown what is causing this to fail exactly, 6.7.0's USE=webdriver
did build fine with all USE enabled last time tested so it could
be related to disabling something while relying on transitive headers.
Bug: https://bugs.gentoo.org/930107
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Most likely more issues, but should hopefully work in most cases
until figure out the rest. Users really having issues may want to
go back to ~ninja-1.11.1 or even app-alternatives/ninja[samurai]
which is known to work for this.
(if issues are widespread, may set a ninja upper bound if don't
find a proper fix at least before the next Qt bump)
Bug: https://bugs.gentoo.org/930107
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Missed that this is now always used in 6.7, *could* be skipped
by enabling minigbm but that is a intel-only alternative.
Not worth a revbump+rebuild given qtbase[gui] pulls libdrm either
way and unlikely for mesa to be missing.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
"May" be possible to do without, but configure.cmake has an
assert that prevents progressing if Quick+Qml is not found
(even if disabled qml components, not to say something else
may not genuinely need it), but for now hard depend on it.
In that context it may not be super worth keeping USE=qml,
albeit if unneeded it's still a bit less to build/install.
May revisit, but keeping is convenient for webchannel[qml?].
Skip revbump, not worth rebuilds and USE=widgets (default
and rarely disabled) is already pulling qtdeclarative.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
6.7-5 -> 6.7-6 changes:
Updated:
* x11-header.patch -> glx-headers.patch (updated for bug #928508)
Closes: https://bugs.gentoo.org/928508
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
6.6-9 -> 6.6-10 changes:
Added:
* clang18.patch (imported from files/)
Updated:
* cstdint.patch (for bug #928466)
6.7-4 -> 6.7-5 changes:
Added:
* x11-header.patch (imported from files/)
...not adding clang18 given expect it to be fixed upstream soon
Updated:
* cstdint.patch (for bug #928466)
...gcc+musl still untested for 6.7.0, but updating what's known
Closes: https://bugs.gentoo.org/928466
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
