| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Patrick Lauer <patrick@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dev-build/slibtool provides an alternative implementation of libtool
which is intended to hook itself into and replace the ltmain.sh-based
./libtool shell scripts installed into an autotools build system.
It has some interesting quirks. In particular, it takes the idea of
"packagers don't want to install libtool archives for random libraries
because nobody uses them and pkg-config is better" and runs with it. It
runs quite far with it, as it doesn't install them at all without a new
flag passed to slibtool. This is redundant with our existing approach of
deleting them in src_install when we know they are useless, and is
downright broken in cases such as GCC, where the libtool archives are
load-bearing and the resultant compiler is, in their absence,
nonfunctional.
slibtool supports a variety of wrappers to enable reasonable
functionality which it by default disabled. The official recommendation
is you are supposed to use "rlibtool" to replace ./libtool as it
performs heuristics based on the generated config. But we actually need
"rclibtool", which both respects the generated config and also generates
the *.la archives and leaves it up to ebuilds to decide whether they
should be removed.
Raise a fatal error if the user has misconfigured slibtool. This
prevents the user from building a broken and malformed GCC.
Closes: https://bugs.gentoo.org/932245
Closes: https://bugs.gentoo.org/924150
Closes: https://bugs.gentoo.org/931268
Closes: https://bugs.gentoo.org/931279
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
Reviewed-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
| |
Bug: https://github.com/pkgcore/pkgcheck/issues/702
Bug: https://github.com/pkgcore/pkgcheck/issues/703
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
| |
Bug: https://github.com/pkgcore/pkgcheck/issues/702
Bug: https://github.com/pkgcore/pkgcheck/issues/703
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
| |
Bug: https://github.com/pkgcore/pkgcheck/issues/702
Bug: https://github.com/pkgcore/pkgcheck/issues/703
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
| |
This change broke all packages using a lower minimum-version. Sigh.
Reverts: 0be38fc6bebba7f193d243a35915f6d393319fd3
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To quote Eli [1] (I can't explain it better than this):
autotools.eclass runs autoheader without options (and in
particular without --force). This will only remake config.h.in
if there are actual changes to the content, which in turn means
that it will be out of date compared to aclocal.m4 (which we very
much expect to have changes).
So `make` sees that the header is out of date, and runs autoheader
yet again, this time updating the timestamp for `make` purposes.
This causes QA warning that "maintainer mode" is detected.
autoheader and autoconf added --force option at the same time [2],
so no reason only autoconf has that option in the eclass and not
autoheader.
Like, autoconf, a check on WANT_AUTOCONF != 2.1 is added because the
feature was added in autoconf 2.52.
[1] https://bugs.gentoo.org/939468#c6
[2] https://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=dbf7fc61
Closes: https://bugs.gentoo.org/939468
Closes: https://bugs.gentoo.org/939535
Signed-off-by: YiFei Zhu <zhuyifei1999@gmail.com>
Closes: https://github.com/gentoo/gentoo/pull/38588
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
| |
Replace `cmake.verbose` with `build.verbose`, following the change
in scikit-build-core 0.10.
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
|
|
| |
Sync from Emacs overlay.
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's not supported on 32-bit kernels anyway.
This got lost in b6bf005b843e3d6ee10aa1f088d93c4f89055cc6 when wiring
up arm64.
Bug: https://bugs.gentoo.org/916381
Closes: https://bugs.gentoo.org/939874
Fixes: b6bf005b843e3d6ee10aa1f088d93c4f89055cc6
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
eb49d171430cc2baffbf9d37493a78cc02b33fe2 dropped old GCC support but
the tests weren't updated.
Closes: https://bugs.gentoo.org/939817
Fixes: eb49d171430cc2baffbf9d37493a78cc02b33fe2
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 992fc2954c2281285bc50156ba12d310a1b434e1.
This should no longer be necessary now that tests are opt-in
with TOOLCHAIN_HAS_TESTS.
Bug: https://bugs.gentoo.org/859157
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In 1d93a491096f1cc0234fcf44458bfec142c213bb, we kind of introduced a
timebomb to all GCC ebuilds.
Switch to making it opt-in by setting TOOLCHAIN_HAS_TESTS in ebuilds
which want to use validate_failures.py. It hasn't been tested and may
not even work with gnat-gpl and kgcc64 so it doesn't make sense
to have it by default, especially for gnat-gpl which is now just
a bootstrap package anyway.
Bug: https://bugs.gentoo.org/934124
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
toolchain.sh test script requires PYTHON_COMPAT array since commit
1d93a491096f ("toolchain.eclass: rework tests more") otherwise it dies
with
die: PYTHON_COMPAT not declared.
error.
Bug: https://bugs.gentoo.org/859157
Signed-off-by: Petr Vaněk <arkamar@gentoo.org>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
|
| |
einstalldocs notably benefits from the PWD being the correct source
directory.
Signed-off-by: Alfred Wingate <parona@protonmail.com>
Signed-off-by: Arsen Arsenović <arsen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We ship the kernel in gentoo-kernel-bin in the form of an UKI, using
objcopy we extract from this the kernel image (and if desired the
generic initramfs).
However, llvm-objcopy does not properly handle the -O argument and as a
result the extracted kernel image is of the same file type as the UKI
(i.e. a PE32+ executable) instead of a regular kernel image. This causes
issues in bootloader such as grub which differentiate between loading
a normal kernel image and loading an EFI executable (such as an UKI).
And also causes the signature verification to fail since the kernel
image is bigger then it should be due to the additional headers.
Using the --dump-section argument instead resolves this problem.
See-also: https://github.com/llvm/llvm-project/issues/108946
Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org>
Closes: https://github.com/gentoo/gentoo/pull/38643
Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org>
|
|
|
|
|
|
|
|
| |
For toolchain eclasses we usually keep generic stuff like this
for e.g. cross but there's no benefit to leaving it in non-toolchain
eclasses like this.
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GCC doesn't build in Gentoo at least without GNU Binutils. It is possible
but it requires some work. It's not clear to me if some of that work
needs to happen in LLVM upstream too (see below).
In commits 7011340a0f13dcada6f3be48054957035bc6e01a and
a7c27596827072f586dc07e6d53531ecb2c7cd6e, I tried to get things building
with Clang's assembler but didn't get it over the line. I think I remember
Arfrever and I coming up with a few later drafts (?) on IRC in #gentoo-hardened
but I didn't commit any of it as it didn't work in the end anyway.
But see https://briancallahan.net/blog/20240122.html which tackles at least
one of the issues I ended up hitting before.
In any case, add the dependency for now to keep things working.
Closes: https://bugs.gentoo.org/936271
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
| |
Signed-off-by: Volkmar W. Pogatzki <gentoo@pogatzki.net>
Closes: https://github.com/gentoo/gentoo/pull/38544
Signed-off-by: Miroslav Šulc <fordfrog@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
|
|
| |
Signed-off-by: Volkmar W. Pogatzki <gentoo@pogatzki.net>
Closes: https://github.com/gentoo/gentoo/pull/37338
Signed-off-by: Miroslav Šulc <fordfrog@gentoo.org>
|
|
|
|
|
|
| |
Bug: https://bugs.gentoo.org/936099
Signed-off-by: Sv. Lockal <lockalsash@gmail.com>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Normally, failing to run cargo_gen_config results in an error, but that
is unhelpful for ebuilds with optional Cargo support.
Closes: https://bugs.gentoo.org/938764
Signed-off-by: James Le Cuirot <chewi@gentoo.org>
Signed-off-by: Michał Górny <mgorny@gentoo.org>
Closes: https://github.com/gentoo/gentoo/pull/38041
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
| |
Closes: https://bugs.gentoo.org/937642
Signed-off-by: Michał Górny <mgorny@gentoo.org>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|