Oversight, (at least) needed to set PKG_CONFIG_PATH properly.
>=wine-10 can figure it out by itself, but still want to keep
this to setup everything properly rather than leave it to fate.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
To be used by X.Org packages with a meson build system. Largely a copy
of xorg-3.eclass with changes necessary to switch from autotools to
meson.
Compared with xorg-3, I've dropped a few things that I don't think are
necessary (at least initially), namely:
- font support (media-libs/font-* packages); packages change very
rarely and don't have meson build systems upstream.
- XORG_DOC dependencies. This actually looks wrong in xorg-3?
- asciidoc is used to generate docbook documentation (which I
don't think we ever do in the ebuilds)
- xmlto is used to create some man pages from XML, but the man pages
are checked into git so we don't ever need to generate them
Signed-off-by: Matt Turner <mattst88@gentoo.org>
This reverts commit 34b74faa06, i.e.
reapplies the simplified dependency specification.
We had to revert this before because of the collision issues when
switching to slotted Rust where the same Rust version existed before
in a non-slotted variant. We have a sanity check and workaround for that
in pkg_postinst for affected versions now, so there shouldn't be a reason
we can't do this.
This may ease depcleaning older Rust in some cases w/o having to rebuild
packages against new Rust.
Bug: https://bugs.gentoo.org/943143
Bug: https://bugs.gentoo.org/943206
Bug: https://bugs.gentoo.org/953884
Signed-off-by: Sam James <sam@gentoo.org>
chiitoo mentioned that (at least) 10.7 works without this, and
that the last needed fixes were in 10.0-rc1, so I tried 10.0
and it was also fine.
vanilla-9.0.1 does not seem to have received a hotfix for this and
still fails, there's also proton-9.0.4 to worry about so will just
keep passing it for <10 until they're gone.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Otherwise it will try to run inside the build directory if there is a
static-libs use flag which is disabled.
llvm-bitcode-strip: error: './build/obj/lib/x509_x509path.o': The file was not recognized as a valid object file
Signed-off-by: Alfred Wingate <parona@protonmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
Rust 1.71.1 was retained due to games-strategy/ja2-stracciatella
being unable to build with any later version of Rust.
This package has been updated and as 1.71.1 is not in our
bootstrap path it is safe to remove (and remove that slot from
consideration in the eclass).
Signed-off-by: Matt Jolly <kangie@gentoo.org>
This updates the edo function to behave similar to its possible
implementation in the package manager for EAPI 9:
- Backslash-escaping (as einfo does via "echo -e") is not wanted.
- Arguments should be printed in a quoted format that could be reused
as shell input. We quote arguments using the "@Q" operator of Bash
parameter expansion, but avoid excessive quoting by testing each
argument for shell metacharacters. The resulting output should be
very similar to that of the trace obtained with "set -x".
Note that the @Q operator did not exist in Bash 4.2, therefore
arguments are printed literally in EAPI 7.
Bug: https://bugs.gentoo.org/744880#c13
Suggested-by: Eli Schwartz <eschwartz@gentoo.org>
Reviewed-by: Eli Schwartz <eschwartz@gentoo.org>
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
Not sure if the others are right or obsolete now, or what, but
for me, the "prestripped" (but not) files are at e.g.
usr/lib/go/15/x86_64-pc-linux-gnu/crypto.gox.
Followup to ff1f410ec1.
Signed-off-by: Sam James <sam@gentoo.org>
Python 3.14 cleaned up the venv logic, and we have been apparently
relying on some hacks that worked by accident. More specifically:
1. pyvenv.cfg location is used explicitly as sys.prefix, so we can
no longer put it inside bin/ subdirectory (no clue why we did that
-- probably a long chain of historical reasons).
2. "home =" must always be present for venv detection to work.
With these changes, Python 3.14 seems now able to correctly detect
the venv and set prefixes accordingly. Since they improve correctness,
they should also be fine for other Python versions.
Apparently, the pyvenv.cfg file was moved into bindir back in 2022,
for the trivial reason of using a single directory for all created
files. Mea culpa!
Fixes: d5b7d1b425
Signed-off-by: Michał Górny <mgorny@gentoo.org>
Switch `python_optimize()` to use a combination of `-s` and `-p` options
instead of `-d`, since the latter does not seem to work correctly
in some cases, e.g. with `www-servers/uwsgi`:
```
The stripdir path '/tmp/portage/www-servers/uwsgi-2.0.27/image/usr/lib/python3.13/site-packages/' is not a valid prefix for source path '/tmp/portage/www-servers/uwsgi-2.0.27/image/usr/lib/python3.13/site-packages/uwsgidecorators.py'; ignoring
```
These options are supported in all Python versions the eclasses
currently do support.
Signed-off-by: Michał Górny <mgorny@gentoo.org>
Remove the old code paths that used to provide `python_optimize()`
for Python 3.8 and Python 2.7 / PyPy. I thought we were keeping them
for dev-lang/pypy ebuilds but apparently we're calling compileall
directly there.
Signed-off-by: Michał Górny <mgorny@gentoo.org>
Remove special case for '3.10' in _python_impl_matches -- it was only
necessary because we needed to handle 'pypy3' target specially,
and that is no longer the case. Technically, the code checks for
'pypy3_10' but that's not a problem, since there is no such a thing.
Signed-off-by: Michał Górny <mgorny@gentoo.org>
This flag is "safe" for the same reason `-flto` is "safe". Furthermore,
the new dot-a.eclass relies on setting this flag, which `strip-flags` then
deletes again in the event that a package uses both `lto-guarantee-fat` and
`strip-flags`.
End result: static libraries that contain neither LTO nor regular object
code.
Example package that does this: dev-libs/nss
Acked-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
I'm not sure if I made a mistake when testing this before or if it changed
when the strip patch did, but the new behaviour is fine too with the
latest patch for Binutils.
I think what happened is that the patch changed to only mangle with -R ...
where ... is for LTO sections, which is fine for us. But doing this in a
separate commit so I can revert it easily if needed.
See https://sourceware.org/bugzilla/show_bug.cgi?id=21479#c13.
Signed-off-by: Sam James <sam@gentoo.org>
Introduce a new eclass with utility functions for handling LTO bytecode
(or internal representation, IR) inside static archives (.a files).
Static libraries when built with LTO will contain LTO bytecode which is
not portable across compiler versions or compiler vendors. To avoid pessimising
the library and always filtering LTO, we can build it with -ffat-lto-objects
instead, which builds some components twice. The installed part will then
have the LTO contents stripped out, leaving the regular objects in the
static archive.
It's not feasible to make these work otherwise, as we'd need tracking
for whether a library was built by a specific compiler and its version,
and that compatibility can vary based on other factors (e.g. with gcc,
sys-devel/gcc[zstd] controls if it supports zstd compression for LTO). We
also discourage static libraries anyway.
Provide two functions:
* lto-guarantee-fat
If LTO is currently enabled (as determined by `tc-is-lto`, added in
2aea6c3ff2), add `-ffat-lto-objects`
to CFLAGS and CXXFLAGS if supported.
This guarantees that produced archives are "fat" (contain both IR
and regular object files) for later pruning.
* strip-lto-bytecode
Process a given static archive (.a file) and remove its IR component,
leaving a regular object.
This approach is also taken by Fedora, openSUSE, and Debian/Ubuntu. An
honourable mention to `lto-rebuild` which fulfilled the same task for many
in the LTO overlay too.
We did consider an alternative approach where we'd relink objects using
the driver in src_install (or some hook afterwards), but this would be
more brittle, as we'd need to extract the right arguments to use (see
e.g. the recent Wireshark issues in fad8ff8a45
for how this can be subtle) and not PM-agnostic given we don't have portable
hooks right now (and even if we did, suspect they wouldn't work in a way
that facilitated this). It's also not clear if such an approach would've
worked for Clang.
The tests have been quite helpful in debugging this and making sure things
work as expected. They both make sure the eclass does what it ought to,
but also try to capture the expected interaction with the toolchain (which is
why we have the skips depending on tooling & versions) to allow us to test
workarounds and make sure we understand the interactions fully: it made
it easy to test e.g. a patch to Binutils to make strip have plugin/LTO
integration (PR21479).
All of this wasn't worth pursuing until H. J. Lu's patches for Binutils
landed, which they have now in binutils-2.44 [0], which made bfd's handling
of mixed objects much more robust.
[0] https://inbox.sourceware.org/binutils/20250112220244.597636-1-hjl.tools@gmail.com/
Bug: https://bugs.gentoo.org/926120
Thanks-to: Arsen Arsenović <arsen@gentoo.org>
Co-authored-by: Eli Schwartz <eschwartz@gentoo.org>
Signed-off-by: Sam James <sam@gentoo.org>
As the GCC version being used for stage1 may not be the version we think
it is with the bootstrap compiler (i.e. $(gcc-full-version) may not
reflect what we're using because of ada-bootstrap).
Signed-off-by: Sam James <sam@gentoo.org>
For HPPA, the ada-bootstrap binaries seem to default to -fstack-protector still
(maybe because of cross-building) so we need to override it for <13
(which ignores -fstack-protector) as SSP doesn't exist there. The GNAT
configure test gets confused by GCC warning about this otherwise.
Signed-off-by: Sam James <sam@gentoo.org>
For Qt 5, it's best to just disable reduce-relocations, because it
doesn't (unlike Qt 6) support -mno-direct-extern-access, which means
CMake applications building against Qt 5 are prone to all the issues
mentioned in the bug.
Bug: https://bugs.gentoo.org/754021
Signed-off-by: Sam James <sam@gentoo.org>
Only saying "build" given technically won't work out of the
box without the user setting up xtajit.dll themselves.
The 32bit warning could make sense on arm64 too, but given
it's off-by-default and does not work out of the box, nagging
about this every installs would just be annoying.
(the aarch64_CFLAGS changes & friends from the linked PR
were done in a previous commit)
Untested given do not have arm64 hardware, please report if
I overlooked anything.
While here, also add spacing to the warnings for visibility
and to split them if get more than one message.
Closes: https://github.com/gentoo/gentoo/pull/41752
Thanks-to: Sasha Finkelstein <fnkl.kernel@gmail.com>
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
Previously would test flags for only one arch as a best effort, but
this gets messier if adding --enable-archs=i386,aarch64 support where
the two are more likely to need different flags.
Using a function inside $() to avoid the need to preserve CHOST
*FLAGS and also allow e.g. filter-flags -Wl,* (from CFLAGS...)
without mangling LDFLAGS given filter-cflags does not exist.
Adapted from https://github.com/gentoo/gentoo/pull/41752
Thanks-to: Sasha Finkelstein <fnkl.kernel@gmail.com>
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
... just in case it leaks into other parts of the build. Noticed when
looking at Jannik's reported comparison failure.
Signed-off-by: Sam James <sam@gentoo.org>
