Re: [gentoo-dev] [PATCH] lua-utils.eclass: use BROOT or ESYSROOT where appropriate
On Sun, 2024-08-18 at 14:31 -0400, Mike Gilbert wrote:
> The LUA variable points to a lua binary that is likely to be executed by
> the build system. Use BROOT for this.
>
> Use ESYSROOT for the pkg-config symlink, since this is likely used for
> linking a library.
>
> Signed-off-by: Mike Gilbert
> ---
> eclass/lua-utils.eclass | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
> index 0ff36734dc8f..c63ec369c1c2 100644
> --- a/eclass/lua-utils.eclass
> +++ b/eclass/lua-utils.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 1999-2023 Gentoo Authors
> +# Copyright 1999-2024 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
>
> # @ECLASS: lua-utils.eclass
> @@ -144,18 +144,18 @@ _lua_wrapper_setup() {
> _lua_export "${impl}" ELUA LUA
>
> # Lua interpreter
> - ln -s "${EPREFIX}"/usr/bin/${ELUA} "${workdir}"/bin/lua || die
> + ln -s "${LUA}" "${workdir}"/bin/lua || die
>
> # Lua compiler, or a stub for it in case of luajit
> if [[ ${ELUA} == luajit ]]; then
> # Just in case
> - ln -s "${EPREFIX}"/bin/true "${workdir}"/bin/luac || die
> + ln -s "${BROOT}"/bin/true "${workdir}"/bin/luac || die
> else
> - ln -s "${EPREFIX}"/usr/bin/${ELUA/a/ac}
> "${workdir}"/bin/luac || die
> + ln -s "${BROOT}"/usr/bin/${ELUA/a/ac}
> "${workdir}"/bin/luac || die
> fi
>
> # pkg-config
> - ln -s "${EPREFIX}"/usr/$(get_libdir)/pkgconfig/${ELUA}.pc \
> + ln -s "${ESYSROOT}"/usr/$(get_libdir)/pkgconfig/${ELUA}.pc \
> "${workdir}"/pkgconfig/lua.pc || die
> fi
>
> @@ -264,7 +264,7 @@ _lua_export() {
> debug-print "${FUNCNAME}: ELUA = ${ELUA}"
> ;;
> LUA)
> - export LUA="${EPREFIX}"/usr/bin/${impl}
> + export LUA="${BROOT}"/usr/bin/${impl}
> debug-print "${FUNCNAME}: LUA = ${LUA}"
> ;;
> LUA_CFLAGS)
Looks good!
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 2/2] cargo.eclass: Preserve project-specific [build] flags by reading config
On Wed, 2024-08-07 at 19:39 +0200, Michał Górny wrote:
> On Wed, 2024-08-07 at 16:52 +0100, James Le Cuirot wrote:
> > The flags we set an a target-specific environment variable override any
> > generic [build] flags set by the project, requiring ebuilds to set these
> > themselves, which is undesirable. Work around this by using tomlq to
> > read the flags from the config files checked by Cargo and prepending
> > them to our environment variable.
> >
> > Signed-off-by: James Le Cuirot
> > ---
> > eclass/cargo.eclass | 28 +---
> > 1 file changed, 17 insertions(+), 11 deletions(-)
> >
> > diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
> > index 6d4cf1b425eb..dea8c49e4585 100644
> > --- a/eclass/cargo.eclass
> > +++ b/eclass/cargo.eclass
> > @@ -36,7 +36,8 @@ esac
> >
> > inherit flag-o-matic multiprocessing rust-toolchain toolchain-funcs
> >
> > -[[ ! ${CARGO_OPTIONAL} ]] && BDEPEND="${RUST_DEPEND}"
> > +# app-misc/yq is needed for tomlq.
> > +[[ ! ${CARGO_OPTIONAL} ]] && BDEPEND="${RUST_DEPEND} app-misc/yq"
> >
>
> Doesn't this imply that all ebuilds using CARGO_OPTIONAL will now have
> to explicitly depend on yq?
Good catch, thanks. I can update the eclass docs accordingly. I count 23
ebuilds across 8 packages, and this can be done without a revbump, so it's not
too bad. Even if it were missing, it would just continue without applying
these extra flags.
I have also noticed that yq will need some keywording first.
I considered some inline Python with just tomli instead, but then you get into
the mess of micro-managing the Python versions. I don't think there's a way to
say "use whatever Python tomli is installed for".
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH 2/2] cargo.eclass: Preserve project-specific [build] flags by reading config
The flags we set an a target-specific environment variable override any
generic [build] flags set by the project, requiring ebuilds to set these
themselves, which is undesirable. Work around this by using tomlq to
read the flags from the config files checked by Cargo and prepending
them to our environment variable.
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 6d4cf1b425eb..dea8c49e4585 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -36,7 +36,8 @@ esac
inherit flag-o-matic multiprocessing rust-toolchain toolchain-funcs
-[[ ! ${CARGO_OPTIONAL} ]] && BDEPEND="${RUST_DEPEND}"
+# app-misc/yq is needed for tomlq.
+[[ ! ${CARGO_OPTIONAL} ]] && BDEPEND="${RUST_DEPEND} app-misc/yq"
IUSE="${IUSE} debug"
@@ -566,21 +567,26 @@ cargo_env() {
# It has been common for users and ebuilds to set RUSTFLAGS, which would
# have overridden whatever a project sets anyway, so the least-worst
option
# is to include those RUSTFLAGS in target-specific config here, which
will
- # merge with any the project sets. Only flags in generic [build] config
set
- # by the project will be lost, and ebuilds will need to add those to
- # RUSTFLAGS themselves if they are important.
- #
- # We could potentially inspect a project's generic [build] config and
- # reapply those flags ourselves, but that would require a proper toml
parser
- # like tomlq, it might lead to confusion where projects also have
- # target-specific config, and converting arrays to strings may not work
- # well. Nightly features to inspect the config might help here in
future.
+ # merge with any the project sets. Flags in generic [build] config set
by
+ # the project would then be overridden, but we preserve them by reading
them
+ # from config files and prepending them to RUSTFLAGS.
#
# As of Rust 1.80, it is not possible to set separate flags for the
build
# host and the target host when cross-compiling. The flags given are
applied
# to the target host only with no flags being applied to the build
host. The
# nightly host-config feature will improve this situation later.
- #
+
+ # Iterate over all the config.toml files that Cargo will read except
for our
+ # own, prepending any build.rustflags to our environment variable so
that
+ # they don't get overridden by our other flags. Skip any flags with an
+ # explicit space in them because we cannot handle those via our
variable.
+ local DIR=${PWD}
+ while true; do
+ RUSTFLAGS="$(tomlq -r '.build.rustflags | if type == "array"
then map(select(contains(" ") | not)) else [.] end | join(" ")'
"${DIR}"/.cargo/config.toml 2>/dev/null) ${RUSTFLAGS# }"
+ [[ -d ${DIR} ]] || break
+ DIR=${DIR%/*}
+ done
+
# The default linker is "cc" so override by setting linker to CC in the
# RUSTFLAGS. The given linker cannot include any arguments, so split
these
# into link-args along with LDFLAGS.
--
2.45.2
[gentoo-dev] [PATCH 1/2] cargo.eclass: Change RUSTFLAGS approach following recent build failures
Cargo turned out to be even worse at handling flags than I thought.
Target-specific flags set by projects were overriding our own, and Cargo
was bailing out when faced with merging a string of flags with an array
of flags.
After weighing up the poor set of options, I've found that it is better
to always set flags via a target-specific environment variable for
reasons set out in comments added here. This approach was previously
just used for cross-compiling, but now we do it unconditionally.
It has the downside of overriding generic [build] flags set by projects,
but these were already being overridden by users and ebuilds setting
RUSTFLAGS themselves.
Closes: https://bugs.gentoo.org/937453
Closes: https://bugs.gentoo.org/937470
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 65 +++--
1 file changed, 39 insertions(+), 26 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index c360c2a6c419..6d4cf1b425eb 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -259,19 +259,6 @@ cargo_crate_uris() {
cargo_gen_config() {
debug-print-function ${FUNCNAME} "$@"
- # The default linker is "cc" so override by setting linker to CC in the
- # RUSTFLAGS. The given linker cannot include any arguments, so split
these
- # into link-args along with LDFLAGS. Also include external RUSTFLAGS.
- # Note that as of Rust 1.80, the build host RUSTFLAGS are ignored when
- # cross-compiling unless you use the unstable host-config feature
available
- # with USE=nightly. There is no simple way around this.
- tc-export_build_env
- local LD_A=( $(tc-getBUILD_CC) ${BUILD_LDFLAGS} )
- local MY_BUILD_RUSTFLAGS="-C strip=none -C linker=${LD_A[0]}"
- [[ ${#LD_A[@]} -gt 1 ]] && MY_BUILD_RUSTFLAGS+="$(printf -- ' -C
link-arg=%s' "${LD_A[@]:1}")"
- MY_BUILD_RUSTFLAGS+=" ${RUSTFLAGS} ${BUILD_RUSTFLAGS}"
- tc-is-cross-compiler || MY_BUILD_RUSTFLAGS+=" ${TARGET_RUSTFLAGS}"
-
mkdir -p "${ECARGO_HOME}" || die
cat > "${ECARGO_HOME}/config.toml" <<- _EOF_ || die "Failed to create
cargo config"
@@ -286,7 +273,6 @@ cargo_gen_config() {
offline = true
[build]
- rustflags = "${MY_BUILD_RUSTFLAGS}"
jobs = $(makeopts_jobs)
incremental = false
@@ -541,10 +527,11 @@ cargo_src_configure() {
# @USAGE: Command with its arguments
# @DESCRIPTION:
# Run the given command under an environment needed for performing tasks with
-# Cargo such as building. RUSTFLAGS is used for both the build and target host.
-# BUILD_RUSTFLAGS and TARGET_RUSTFLAGS are used for just the build host and
-# target host respectively. Ensure these are set consistently between Cargo
-# invocations, otherwise rebuilds will occur.
+# Cargo such as building. RUSTFLAGS are appended to additional flags set here.
+# Ensure these are set consistently between Cargo invocations, otherwise
+# rebuilds will occur. Project-specific rustflags set against [build] will not
+# take affect due to Cargo limitations, so add these to your ebuild's RUSTFLAGS
+# if they seem important.
cargo_env() {
[[ ${_CARGO_GEN_CONFIG_HAS_RUN} ]] || \
die "FATAL: please call cargo_gen_config before using
${FUNCNAME}"
@@ -569,14 +556,40 @@ cargo_env() {
HOST_CFLAGS=${BUILD_CFLAGS}
HOST_CXXFLAGS=${BUILD_CXXFLAGS}
- if tc-is-cross-compiler; then
- local -x CARGO_BUILD_TARGET=$(rust_abi)
- local TRIPLE=${CARGO_BUILD_TARGET//-/_}
- local TRIPLE=${TRIPLE^^} LD_A=( $(tc-getCC) ${LDFLAGS} )
- local -x CARGO_TARGET_"${TRIPLE}"_RUSTFLAGS="-C strip=none -C
linker=${LD_A[0]}"
- [[ ${#LD_A[@]} -gt 1 ]] && local
CARGO_TARGET_"${TRIPLE}"_RUSTFLAGS+="$(printf -- ' -C link-arg=%s'
"${LD_A[@]:1}")"
- local CARGO_TARGET_"${TRIPLE}"_RUSTFLAGS+=" ${RUSTFLAGS}
${TARGET_RUSTFLAGS}"
- fi
+ # Unfortunately, Cargo is *really* bad at handling flags. In short, it
uses
+ # the first of the RUSTFLAGS env var, any target-specific config, and
then
+ # any generic [build] config. It can merge within the latter two types
from
+ # different sources, but it will not merge across these different
types, so
+ # if a project sets flags under [target.'cfg(all())'], it will override
any
+ # flags we set under [build] and vice-versa.
+ #
+ # It has been common for users and ebuilds to set RUSTFLAGS, which would
+ # have overridden whatever a project sets anyway, so the least-worst
option
+ # is to include those RUSTFLAGS in target-specific config here, which
will
+ #
[gentoo-dev] [PATCH 0/2] cargo.eclass: Change RUSTFLAGS approach following recent build failures
Unfortunately, my recent cargo.eclass changes didn't fare so well, despite me testing it on a good handful of packages. I've had to sharply change tack to work around Cargo's shortcomings. The first commit has the main change. I'd like to merge that very soon to put out the immediate fire. The second commit tries to address a lingering downside where project-specific flags may get overridden by our own. This was happening, even before I changed anything for users or ebuilds setting RUSTFLAGS, but now it is more likely to happen. I'm unsure of this change because it is a little controverial, using app-misc/yq's tomlq (a jq wrapper) to read flags from the project's config files. On the plus side, it should avoid upstreams complaining that we're not using their flags. See what you think. I've kept it in a separate commit so that it can easily be backed out. James Le Cuirot (2): cargo.eclass: Change RUSTFLAGS approach following recent build failures cargo.eclass: Preserve project-specific [build] flags by reading config eclass/cargo.eclass | 73 - 1 file changed, 46 insertions(+), 27 deletions(-) -- 2.45.2
[gentoo-dev] Last rites: media-tv/v4l-utils
# James Le Cuirot (2024-07-29) # Superseded by media-libs/libv4l[utils]. # Removal on 2024-08-29. Bug #936674. media-tv/v4l-utils signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH 8/8] distutils-r1.eclass: Support cross-compiling with PyO3
Only one variable needs to be set. For details, see
https://pyo3.rs/latest/building-and-distribution.html#cross-compiling.
Signed-off-by: James Le Cuirot
---
eclass/distutils-r1.eclass | 3 +++
1 file changed, 3 insertions(+)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 743242b2acee8..9289392f84b38 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1390,6 +1390,9 @@ distutils_pep517_install() {
;;
esac
+ # https://pyo3.rs/latest/building-and-distribution.html#cross-compiling
+ tc-is-cross-compiler && local -x
PYO3_CROSS_LIB_DIR=${SYSROOT}/$(python_get_stdlib)
+
local build_backend=$(_distutils-r1_get_backend)
einfo " Building the wheel for ${PWD#${WORKDIR}/} via ${build_backend}"
cmd+=(
--
2.45.2
[gentoo-dev] [PATCH 7/8] distutils-r1.eclass: Add python_get_stdlib helper function
This is just like python_get_sitedir, but it returns the stdlib
directory such as /usr/lib/python3.12. This is useful for locating the
sysconfigdata file.
Signed-off-by: James Le Cuirot
---
eclass/python-utils-r1.eclass | 23 +++
1 file changed, 23 insertions(+)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index c47565fa1db2a..b544f52312880 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -332,6 +332,17 @@ _python_export() {
export
PYTHON=${BROOT-${EPREFIX}}/usr/bin/${impl}
debug-print "${FUNCNAME}: PYTHON = ${PYTHON}"
;;
+ PYTHON_STDLIB)
+ [[ -n ${PYTHON} ]] || die "PYTHON needs to be
set for ${var} to be exported, or requested before it"
+ PYTHON_STDLIB=$(
+ "${PYTHON}" - "${EPREFIX}/usr" <<-EOF
|| die
+ import sys, sysconfig
+
print(sysconfig.get_path("stdlib", vars={"installed_base": sys.argv[1]}))
+ EOF
+ )
+ export PYTHON_STDLIB
+ debug-print "${FUNCNAME}: PYTHON_STDLIB =
${PYTHON_STDLIB}"
+ ;;
PYTHON_SITEDIR)
[[ -n ${PYTHON} ]] || die "PYTHON needs to be
set for ${var} to be exported, or requested before it"
PYTHON_SITEDIR=$(
@@ -466,6 +477,18 @@ _python_export() {
done
}
+# @FUNCTION: python_get_stdlib
+# @USAGE: []
+# @DESCRIPTION:
+# Obtain and print the 'stdlib' path for the given implementation. If no
+# implementation is provided, ${EPYTHON} will be used.
+python_get_stdlib() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ _python_export "${@}" PYTHON_STDLIB
+ echo "${PYTHON_STDLIB}"
+}
+
# @FUNCTION: python_get_sitedir
# @USAGE: []
# @DESCRIPTION:
--
2.45.2
[gentoo-dev] [PATCH 6/6] distutils-r1.eclass: Use cargo_env when appropriate for flag handling
cargo_env handles linker flags and enables cross-compiling. It also
handles LTO filtering, so we can remove that from this eclass.
Signed-off-by: James Le Cuirot
---
eclass/distutils-r1.eclass | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index fa8edb5cdfb77..743242b2acee8 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1251,7 +1251,9 @@ distutils_pep517_install() {
die "mydistutilsargs are banned in PEP517 mode (use
DISTUTILS_ARGS)"
fi
- local config_settings=
+ local cmd=() config_settings=
+ has cargo ${INHERITED} && cmd+=( cargo_env )
+
case ${DISTUTILS_USE_PEP517} in
maturin)
# `maturin pep517 build-wheel --help` for options
@@ -1390,7 +1392,7 @@ distutils_pep517_install() {
local build_backend=$(_distutils-r1_get_backend)
einfo " Building the wheel for ${PWD#${WORKDIR}/} via ${build_backend}"
- local cmd=(
+ cmd+=(
"${EPYTHON}" -m gpep517 build-wheel
--prefix="${EPREFIX}/usr"
--backend "${build_backend}"
@@ -1792,16 +1794,6 @@ distutils-r1_run_phase() {
# bug fixes from Cython (this works only when setup.py is using
# cythonize() but it's better than nothing)
local -x CYTHON_FORCE_REGEN=1
-
- # Rust extensions are incompatible with C/C++ LTO compiler
- # see e.g. https://bugs.gentoo.org/910220
- if has cargo ${INHERITED}; then
- local x
- for x in $(all-flag-vars); do
- local -x "${x}=${!x}"
- done
- filter-lto
- fi
fi
# silence warnings when pydevd is loaded on Python 3.11+
--
2.45.2
[gentoo-dev] [PATCH 5/6] cargo.eclass: Shadow flag variables so that LTO filtering remains local
This is currently done for Cargo by distutils-r1.eclass. The next commit
will remove that code, leaving cargo_env responsible for it.
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 9 +
1 file changed, 9 insertions(+)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 84f72168fbb3c..25acf010287d8 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -549,7 +549,16 @@ cargo_env() {
[[ ${_CARGO_GEN_CONFIG_HAS_RUN} ]] || \
die "FATAL: please call cargo_gen_config before using
${FUNCNAME}"
+ # Shadow flag variables so that filtering below remains local.
+ local flag
+ for flag in $(all-flag-vars); do
+ local -x "${flag}=${!flag}"
+ done
+
+ # Rust extensions are incompatible with C/C++ LTO compiler see e.g.
+ # https://bugs.gentoo.org/910220
filter-lto
+
tc-export AR CC CXX PKG_CONFIG
# Set vars for cc-rs crate.
--
2.45.2
[gentoo-dev] [PATCH 4/6] cargo.eclass: Explicitly tell rustc not to strip binaries
Most projects don't strip binaries in release mode by default, but there
are exceptions like app-misc/broot.
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 6ea37ec5e4e4b..84f72168fbb3c 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -267,7 +267,7 @@ cargo_gen_config() {
# with USE=nightly. There is no simple way around this.
tc-export_build_env
local LD_A=( $(tc-getBUILD_CC) ${BUILD_LDFLAGS} )
- local BUILD_RUSTFLAGS="-C linker=${LD_A[0]}"
+ local BUILD_RUSTFLAGS="-C strip=none -C linker=${LD_A[0]}"
[[ ${#LD_A[@]} -gt 1 ]] && BUILD_RUSTFLAGS+="$(printf -- ' -C
link-arg=%s' "${LD_A[@]:1}")"
BUILD_RUSTFLAGS+=" ${RUSTFLAGS} ${CARGO_BUILD_RUSTFLAGS}"
tc-is-cross-compiler || BUILD_RUSTFLAGS+=" ${CARGO_TARGET_RUSTFLAGS}"
@@ -564,7 +564,7 @@ cargo_env() {
local -x CARGO_BUILD_TARGET=$(rust_abi)
local TRIPLE=${CARGO_BUILD_TARGET//-/_}
local TRIPLE=${TRIPLE^^} LD_A=( $(tc-getCC) ${LDFLAGS} )
- local -x CARGO_TARGET_"${TRIPLE}"_RUSTFLAGS="-C
linker=${LD_A[0]}"
+ local -x CARGO_TARGET_"${TRIPLE}"_RUSTFLAGS="-C strip=none -C
linker=${LD_A[0]}"
[[ ${#LD_A[@]} -gt 1 ]] && local
CARGO_TARGET_"${TRIPLE}"_RUSTFLAGS+="$(printf -- ' -C link-arg=%s'
"${LD_A[@]:1}")"
local CARGO_TARGET_"${TRIPLE}"_RUSTFLAGS+=" ${RUSTFLAGS}
${CARGO_TARGET_RUSTFLAGS}"
fi
--
2.45.2
[gentoo-dev] [PATCH 3/6] cargo.eclass: Handle LDFLAGS and RUSTFLAGS better
LDFLAGS are not currently honoured by Cargo builds at all. It would be
particularly advantageous to honour -fuse-ld because alternative linkers
like mold are known to be significantly faster at handling Rust.
As things stand, the eclass sets the linker to CC when cross-compiling,
but it does so erroneously due to a shell quoting issue. If CC includes
arguments, an error occurs when setting the CARGO_TARGET_*_LINKER
variable. Even with the right quoting, Cargo still fails because this
variable is not allowed to include arguments. They have to be specified
via RUSTFLAGS instead.
The build host linker is frequently invoked due to the use of build
scripts by some crates. We would therefore also like to configure the
build host linker properly when cross-compiling, but unfortunately there
is currently no way to do this without using a Rust nightly feature.
The build host linker is now configured in the cargo_gen_config function
because this configuration is static. Conversely, the target host linker
is configured with environment variables in the cargo_env function
because the target may change.
Some ebuilds already set RUSTFLAGS, so some consideration was given to
how to handle these. When set, Cargo prioritises RUSTFLAGS and similar
over specific configuration for the build and target hosts, so these
must be unset. We can still include their contents in that configuration
for convenience though. CARGO_BUILD_RUSTFLAGS can be used by ebuilds to
set flags only for the build host.
It should not be necessary for ebuilds to figure out which Rust ABI is
applicable in order to set flags only for the target host, so the helper
reads from a simple CARGO_TARGET_RUSTFLAGS variable without the triple
for convenience.
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 65 +
1 file changed, 42 insertions(+), 23 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index d598af8825adf..6ea37ec5e4e4b 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -109,7 +109,7 @@ ECARGO_VENDOR="${ECARGO_HOME}/gentoo"
#
# If you enable CARGO_OPTIONAL, you have to set BDEPEND on virtual/rust
# for your package and call at least cargo_gen_config manually before using
-# other src_functions of this eclass.
+# other src_functions or cargo_env of this eclass.
# Note that cargo_gen_config is automatically called by cargo_src_unpack.
# @ECLASS_VARIABLE: myfeatures
@@ -259,6 +259,19 @@ cargo_crate_uris() {
cargo_gen_config() {
debug-print-function ${FUNCNAME} "$@"
+ # The default linker is "cc" so override by setting linker to CC in the
+ # RUSTFLAGS. The given linker cannot include any arguments, so split
these
+ # into link-args along with LDFLAGS. Also include external RUSTFLAGS.
+ # Note that as of Rust 1.80, the build host RUSTFLAGS are ignored when
+ # cross-compiling unless you use the unstable host-config feature
available
+ # with USE=nightly. There is no simple way around this.
+ tc-export_build_env
+ local LD_A=( $(tc-getBUILD_CC) ${BUILD_LDFLAGS} )
+ local BUILD_RUSTFLAGS="-C linker=${LD_A[0]}"
+ [[ ${#LD_A[@]} -gt 1 ]] && BUILD_RUSTFLAGS+="$(printf -- ' -C
link-arg=%s' "${LD_A[@]:1}")"
+ BUILD_RUSTFLAGS+=" ${RUSTFLAGS} ${CARGO_BUILD_RUSTFLAGS}"
+ tc-is-cross-compiler || BUILD_RUSTFLAGS+=" ${CARGO_TARGET_RUSTFLAGS}"
+
mkdir -p "${ECARGO_HOME}" || die
cat > "${ECARGO_HOME}/config.toml" <<- _EOF_ || die "Failed to create
cargo config"
@@ -273,6 +286,7 @@ cargo_gen_config() {
offline = true
[build]
+ rustflags = "${BUILD_RUSTFLAGS}"
jobs = $(makeopts_jobs)
incremental = false
@@ -527,27 +541,41 @@ cargo_src_configure() {
# @USAGE: Command with its arguments
# @DESCRIPTION:
# Run the given command under an environment needed for performing tasks with
-# Cargo such as building.
+# Cargo such as building. RUSTFLAGS is used for both the build and target host.
+# CARGO_BUILD_RUSTFLAGS and CARGO_TARGET_RUSTFLAGS are used for just the build
+# host and target host respectively. Ensure these are set consistently between
+# Cargo invocations, otherwise rebuilds will occur.
cargo_env() {
+ [[ ${_CARGO_GEN_CONFIG_HAS_RUN} ]] || \
+ die "FATAL: please call cargo_gen_config before using
${FUNCNAME}"
+
filter-lto
tc-export AR CC CXX PKG_CONFIG
+ # Set vars for cc-rs crate.
+ local -x \
+ HOST_AR=$(tc-getBUILD_AR)
+ HOST_CC=$(tc-getBUILD_CC)
+ HOST_CXX=$(tc-getBUILD_CXX)
+ HOST_CFLAGS=${BUILD_CFLAGS}
+ HOST_CXXFLAGS=${BUILD_CXXFLAGS}
+
if tc-is-cross-compiler; then
- declare -x CARGO_BUILD_TARGET=$(rust_abi)
+
[gentoo-dev] [PATCH 2/6] cargo.eclass: Add cargo_env helper and use it in compile, test, install
Rust packages have a tendency to rebuild parts during test and install.
It is not clear whether this can be addressed. We were therefore relying
on some environment variables set during the compile phase for
cross-compiling to work in the later phases. This is not ideal,
especially if you need to build for multiple targets.
These environment variables can also be useful in other contexts, such
as the build runner in app-misc/anki.
This change moves the setting of these variables into a separate helper
that is now used in all these phases and can be used by ebuilds too. The
variables are now kept local to each invocation of this helper,
preventing leakage.
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 37 +++--
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index aab28dbbac167..d598af8825adf 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -523,26 +523,23 @@ cargo_src_configure() {
[[ ${ECARGO_ARGS[@]} ]] && einfo "Configured with: ${ECARGO_ARGS[@]}"
}
-# @FUNCTION: cargo_src_compile
+# @FUNCTION: cargo_env
+# @USAGE: Command with its arguments
# @DESCRIPTION:
-# Build the package using cargo build.
-cargo_src_compile() {
- debug-print-function ${FUNCNAME} "$@"
-
- [[ ${_CARGO_GEN_CONFIG_HAS_RUN} ]] || \
- die "FATAL: please call cargo_gen_config before using
${FUNCNAME}"
-
+# Run the given command under an environment needed for performing tasks with
+# Cargo such as building.
+cargo_env() {
filter-lto
tc-export AR CC CXX PKG_CONFIG
if tc-is-cross-compiler; then
- export CARGO_BUILD_TARGET=$(rust_abi)
+ declare -x CARGO_BUILD_TARGET=$(rust_abi)
local TRIPLE=${CARGO_BUILD_TARGET//-/_}
- export CARGO_TARGET_"${TRIPLE^^}"_LINKER=$(tc-getCC)
+ declare -x CARGO_TARGET_"${TRIPLE^^}"_LINKER=$(tc-getCC)
# Set vars for cc-rs crate.
tc-export_build_env
- export \
+ declare -x \
HOST_AR=$(tc-getBUILD_AR)
HOST_CC=$(tc-getBUILD_CC)
HOST_CXX=$(tc-getBUILD_CXX)
@@ -550,9 +547,21 @@ cargo_src_compile() {
HOST_CXXFLAGS=${BUILD_CXXFLAGS}
fi
+ "${@}"
+}
+
+# @FUNCTION: cargo_src_compile
+# @DESCRIPTION:
+# Build the package using cargo build.
+cargo_src_compile() {
+ debug-print-function ${FUNCNAME} "$@"
+
+ [[ ${_CARGO_GEN_CONFIG_HAS_RUN} ]] || \
+ die "FATAL: please call cargo_gen_config before using
${FUNCNAME}"
+
set -- cargo build $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@"
einfo "${@}"
- "${@}" || die "cargo build failed"
+ cargo_env "${@}" || die "cargo build failed"
}
# @FUNCTION: cargo_src_install
@@ -573,7 +582,7 @@ cargo_src_install() {
$(usex debug --debug "") \
${ECARGO_ARGS[@]} "$@"
einfo "${@}"
- "${@}" || die "cargo install failed"
+ cargo_env "${@}" || die "cargo install failed"
rm -f "${ED}/usr/.crates.toml" || die
rm -f "${ED}/usr/.crates2.json" || die
@@ -590,7 +599,7 @@ cargo_src_test() {
set -- cargo test $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@"
einfo "${@}"
- "${@}" || die "cargo test failed"
+ cargo_env "${@}" || die "cargo test failed"
}
fi
--
2.45.2
[gentoo-dev] [PATCH 1/6] cargo.eclass: Use newer Cargo config file name
"config" is deprecated and "config.toml" has been valid for ages.
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 7db34efb4e174..aab28dbbac167 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -248,7 +248,7 @@ cargo_crate_uris() {
# @FUNCTION: cargo_gen_config
# @DESCRIPTION:
-# Generate the $CARGO_HOME/config necessary to use our local registry and
settings.
+# Generate the $CARGO_HOME/config.toml necessary to use our local registry and
settings.
# Cargo can also be configured through environment variables in addition to
the TOML syntax below.
# For each configuration key below of the form foo.bar the environment
variable CARGO_FOO_BAR
# can also be used to define the value.
@@ -261,7 +261,7 @@ cargo_gen_config() {
mkdir -p "${ECARGO_HOME}" || die
- cat > "${ECARGO_HOME}/config" <<- _EOF_ || die "Failed to create cargo
config"
+ cat > "${ECARGO_HOME}/config.toml" <<- _EOF_ || die "Failed to create
cargo config"
[source.gentoo]
directory = "${ECARGO_VENDOR}"
--
2.45.2
[gentoo-dev] [PATCH v4 0/6] cargo.eclass: Handle LDFLAGS and RUSTFLAGS better
Sorry for yet another iteration of this. I noticed that the build host flags were not being applied to rustc when cross-compiling. Upon investigation, I found that this isn't actually possible right now. I have reworked it to be close to what we need when it does become possible. James Le Cuirot (6): cargo.eclass: Use newer Cargo config file name cargo.eclass: Add cargo_env helper and use it in compile, test, install cargo.eclass: Handle LDFLAGS and RUSTFLAGS better cargo.eclass: Explicitly tell rustc not to strip binaries cargo.eclass: Shadow flag variables so that LTO filtering remains local distutils-r1.eclass: Use cargo_env when appropriate for flag handling eclass/cargo.eclass| 93 ++ eclass/distutils-r1.eclass | 16 ++- 2 files changed, 69 insertions(+), 40 deletions(-) -- 2.45.2
[gentoo-dev] [PATCH 5/5 v3] distutils-r1.eclass: Use cargo_env when appropriate for flag handling
cargo_env handles linker flags and enables cross-compiling. It also
handles LTO filtering, so we can remove that from this eclass.
Signed-off-by: James Le Cuirot
---
eclass/distutils-r1.eclass | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index fa8edb5cdfb77..743242b2acee8 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1251,7 +1251,9 @@ distutils_pep517_install() {
die "mydistutilsargs are banned in PEP517 mode (use
DISTUTILS_ARGS)"
fi
- local config_settings=
+ local cmd=() config_settings=
+ has cargo ${INHERITED} && cmd+=( cargo_env )
+
case ${DISTUTILS_USE_PEP517} in
maturin)
# `maturin pep517 build-wheel --help` for options
@@ -1390,7 +1392,7 @@ distutils_pep517_install() {
local build_backend=$(_distutils-r1_get_backend)
einfo " Building the wheel for ${PWD#${WORKDIR}/} via ${build_backend}"
- local cmd=(
+ cmd+=(
"${EPYTHON}" -m gpep517 build-wheel
--prefix="${EPREFIX}/usr"
--backend "${build_backend}"
@@ -1792,16 +1794,6 @@ distutils-r1_run_phase() {
# bug fixes from Cython (this works only when setup.py is using
# cythonize() but it's better than nothing)
local -x CYTHON_FORCE_REGEN=1
-
- # Rust extensions are incompatible with C/C++ LTO compiler
- # see e.g. https://bugs.gentoo.org/910220
- if has cargo ${INHERITED}; then
- local x
- for x in $(all-flag-vars); do
- local -x "${x}=${!x}"
- done
- filter-lto
- fi
fi
# silence warnings when pydevd is loaded on Python 3.11+
--
2.45.2
[gentoo-dev] [PATCH 4/5 v3] cargo.eclass: Shadow flag variables so that LTO filtering remains local
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 9 +
1 file changed, 9 insertions(+)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 44d3f7ee31f59..9f0bffee0e048 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -532,7 +532,16 @@ cargo_src_configure() {
# host and target host respectively. Ensure these are set consistently between
# Cargo invocations, otherwise rebuilds will occur.
cargo_env() {
+ # Shadow flag variables so that filtering below remains local.
+ local flag
+ for flag in $(all-flag-vars); do
+ local -x "${flag}=${!flag}"
+ done
+
+ # Rust extensions are incompatible with C/C++ LTO compiler see e.g.
+ # https://bugs.gentoo.org/910220
filter-lto
+
tc-export AR CC CXX PKG_CONFIG
# Set vars for cc-rs crate.
--
2.45.2
[gentoo-dev] [PATCH 3/5 v3] cargo.eclass: Explicitly tell rustc not to strip binaries
Most projects don't strip binaries in release mode by default, but there
are exceptions like app-misc/broot.
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 596598ca8585a..44d3f7ee31f59 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -548,13 +548,13 @@ cargo_env() {
# RUSTFLAGS. The given linker cannot include any arguments, so split
these
# into link-args along with LDFLAGS. Also include external RUSTFLAGS.
local LD_A=( ${HOST_CC} ${BUILD_LDFLAGS} )
- local -x CARGO_BUILD_RUSTFLAGS="${RUSTFLAGS} ${CARGO_BUILD_RUSTFLAGS}
-C linker=${LD_A[0]}"
+ local -x CARGO_BUILD_RUSTFLAGS="-C strip=none ${RUSTFLAGS}
${CARGO_BUILD_RUSTFLAGS} -C linker=${LD_A[0]}"
[[ ${#LD_A[@]} -gt 1 ]] && local CARGO_BUILD_RUSTFLAGS+="$(printf -- '
-C link-arg=%s' "${LD_A[@]:1}")"
if tc-is-cross-compiler; then
local -x CARGO_BUILD_TARGET=$(rust_abi)
local TRIPLE=${CARGO_BUILD_TARGET//-/_} LD_A=( $(tc-getCC)
${LDFLAGS} )
- local -x CARGO_TARGET_"${TRIPLE^^}"_RUSTFLAGS="${RUSTFLAGS}
${CARGO_TARGET_RUSTFLAGS} -C linker=${LD_A[0]}"
+ local -x CARGO_TARGET_"${TRIPLE^^}"_RUSTFLAGS="-C strip=none
${RUSTFLAGS} ${CARGO_TARGET_RUSTFLAGS} -C linker=${LD_A[0]}"
[[ ${#LD_A[@]} -gt 1 ]] && local
CARGO_TARGET_"${TRIPLE^^}"_RUSTFLAGS+="$(printf -- ' -C link-arg=%s'
"${LD_A[@]:1}")"
else
CARGO_BUILD_RUSTFLAGS+=" ${CARGO_TARGET_RUSTFLAGS}"
--
2.45.2
[gentoo-dev] [PATCH 2/5 v3] cargo.eclass: Handle LDFLAGS and RUSTFLAGS better
LDFLAGS are not currently honoured by Cargo builds at all. It would be
particularly advantageous to honour -fuse-ld because alternative linkers
like mold are known to be significantly faster at handling Rust.
As things stand, the eclass sets the linker to CC when cross-compiling,
but it does so erroneously due to a shell quoting issue. If CC includes
arguments, an error occurs when setting the CARGO_TARGET_*_LINKER
variable. Even with the right quoting, Cargo still fails because this
variable is not allowed to include arguments. They have to be specified
via RUSTFLAGS instead.
We would also like to configure the build host linker properly when
cross-compiling, but strangely there is no equivalent linker variable
for the build host. It can only be set via RUSTFLAGS. For consistency,
we now use RUSTFLAGS for the target host linker as well.
Some ebuilds already set RUSTFLAGS, so some consideration was given to
how to handle these. When set, Cargo prioritises RUSTFLAGS over
CARGO_BUILD_RUSTFLAGS and CARGO_TARGET_*_RUSTFLAGS, so we need it unset
to allow different flags for the build and target hosts. We can still
include its contents in the latter variables for convenience though.
It should not be necessary for ebuilds to figure out which Rust ABI is
applicable in order to set flags only for the target host, so the helper
reads from a simple CARGO_TARGET_RUSTFLAGS variable without the triple
for convenience.
Unfortunately, I have not yet encountered a package that makes use of
CARGO_BUILD_RUSTFLAGS while cross-compiling, but as far as I can tell,
it should work.
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 47 +++--
1 file changed, 33 insertions(+), 14 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index b6d5fe21f0a7b..596598ca8585a 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -527,27 +527,46 @@ cargo_src_configure() {
# @USAGE: Command with its arguments
# @DESCRIPTION:
# Run the given command under an environment needed for performing tasks with
-# Cargo such as building.
+# Cargo such as building. RUSTFLAGS is used for both the build and target host.
+# CARGO_BUILD_RUSTFLAGS and CARGO_TARGET_RUSTFLAGS are used for just the build
+# host and target host respectively. Ensure these are set consistently between
+# Cargo invocations, otherwise rebuilds will occur.
cargo_env() {
filter-lto
tc-export AR CC CXX PKG_CONFIG
+ # Set vars for cc-rs crate.
+ tc-export_build_env
+ local -x \
+ HOST_AR=$(tc-getBUILD_AR)
+ HOST_CC=$(tc-getBUILD_CC)
+ HOST_CXX=$(tc-getBUILD_CXX)
+ HOST_CFLAGS=${BUILD_CFLAGS}
+ HOST_CXXFLAGS=${BUILD_CXXFLAGS}
+
+ # The default linker is "cc" so override by setting linker to CC in the
+ # RUSTFLAGS. The given linker cannot include any arguments, so split
these
+ # into link-args along with LDFLAGS. Also include external RUSTFLAGS.
+ local LD_A=( ${HOST_CC} ${BUILD_LDFLAGS} )
+ local -x CARGO_BUILD_RUSTFLAGS="${RUSTFLAGS} ${CARGO_BUILD_RUSTFLAGS}
-C linker=${LD_A[0]}"
+ [[ ${#LD_A[@]} -gt 1 ]] && local CARGO_BUILD_RUSTFLAGS+="$(printf -- '
-C link-arg=%s' "${LD_A[@]:1}")"
+
if tc-is-cross-compiler; then
- declare -x CARGO_BUILD_TARGET=$(rust_abi)
- local TRIPLE=${CARGO_BUILD_TARGET//-/_}
- declare -x CARGO_TARGET_"${TRIPLE^^}"_LINKER=$(tc-getCC)
-
- # Set vars for cc-rs crate.
- tc-export_build_env
- declare -x \
- HOST_AR=$(tc-getBUILD_AR)
- HOST_CC=$(tc-getBUILD_CC)
- HOST_CXX=$(tc-getBUILD_CXX)
- HOST_CFLAGS=${BUILD_CFLAGS}
- HOST_CXXFLAGS=${BUILD_CXXFLAGS}
+ local -x CARGO_BUILD_TARGET=$(rust_abi)
+ local TRIPLE=${CARGO_BUILD_TARGET//-/_} LD_A=( $(tc-getCC)
${LDFLAGS} )
+ local -x CARGO_TARGET_"${TRIPLE^^}"_RUSTFLAGS="${RUSTFLAGS}
${CARGO_TARGET_RUSTFLAGS} -C linker=${LD_A[0]}"
+ [[ ${#LD_A[@]} -gt 1 ]] && local
CARGO_TARGET_"${TRIPLE^^}"_RUSTFLAGS+="$(printf -- ' -C link-arg=%s'
"${LD_A[@]:1}")"
+ else
+ CARGO_BUILD_RUSTFLAGS+=" ${CARGO_TARGET_RUSTFLAGS}"
fi
- "${@}"
+ (
+ # Bare RUSTFLAGS will override the above, even if empty, so
unset it
+ # locally. Do this in a subshell so that it remains set
afterwards.
+ unset RUSTFLAGS
+
+ "${@}"
+ )
}
# @FUNCTION: cargo_src_compile
--
2.45.2
[gentoo-dev] [PATCH 1/5 v3] cargo.eclass: Add cargo_env helper and use it in compile, test, install
Rust packages have a tendency to rebuild parts during test and install.
It is not clear whether this can be addressed. We were therefore relying
on some environment variables set during the compile phase for
cross-compiling to work in the later phases. This is not ideal,
especially if you need to build for multiple targets.
These environment variables can also be useful in other contexts, such
as the build runner in app-misc/anki.
This change moves the setting of these variables into a separate helper
that is now used in all these phases and can be used by ebuilds too. The
variables are now kept local to each invocation of this helper,
preventing leakage.
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 37 +++--
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 7db34efb4e174..b6d5fe21f0a7b 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -523,26 +523,23 @@ cargo_src_configure() {
[[ ${ECARGO_ARGS[@]} ]] && einfo "Configured with: ${ECARGO_ARGS[@]}"
}
-# @FUNCTION: cargo_src_compile
+# @FUNCTION: cargo_env
+# @USAGE: Command with its arguments
# @DESCRIPTION:
-# Build the package using cargo build.
-cargo_src_compile() {
- debug-print-function ${FUNCNAME} "$@"
-
- [[ ${_CARGO_GEN_CONFIG_HAS_RUN} ]] || \
- die "FATAL: please call cargo_gen_config before using
${FUNCNAME}"
-
+# Run the given command under an environment needed for performing tasks with
+# Cargo such as building.
+cargo_env() {
filter-lto
tc-export AR CC CXX PKG_CONFIG
if tc-is-cross-compiler; then
- export CARGO_BUILD_TARGET=$(rust_abi)
+ declare -x CARGO_BUILD_TARGET=$(rust_abi)
local TRIPLE=${CARGO_BUILD_TARGET//-/_}
- export CARGO_TARGET_"${TRIPLE^^}"_LINKER=$(tc-getCC)
+ declare -x CARGO_TARGET_"${TRIPLE^^}"_LINKER=$(tc-getCC)
# Set vars for cc-rs crate.
tc-export_build_env
- export \
+ declare -x \
HOST_AR=$(tc-getBUILD_AR)
HOST_CC=$(tc-getBUILD_CC)
HOST_CXX=$(tc-getBUILD_CXX)
@@ -550,9 +547,21 @@ cargo_src_compile() {
HOST_CXXFLAGS=${BUILD_CXXFLAGS}
fi
+ "${@}"
+}
+
+# @FUNCTION: cargo_src_compile
+# @DESCRIPTION:
+# Build the package using cargo build.
+cargo_src_compile() {
+ debug-print-function ${FUNCNAME} "$@"
+
+ [[ ${_CARGO_GEN_CONFIG_HAS_RUN} ]] || \
+ die "FATAL: please call cargo_gen_config before using
${FUNCNAME}"
+
set -- cargo build $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@"
einfo "${@}"
- "${@}" || die "cargo build failed"
+ cargo_env "${@}" || die "cargo build failed"
}
# @FUNCTION: cargo_src_install
@@ -573,7 +582,7 @@ cargo_src_install() {
$(usex debug --debug "") \
${ECARGO_ARGS[@]} "$@"
einfo "${@}"
- "${@}" || die "cargo install failed"
+ cargo_env "${@}" || die "cargo install failed"
rm -f "${ED}/usr/.crates.toml" || die
rm -f "${ED}/usr/.crates2.json" || die
@@ -590,7 +599,7 @@ cargo_src_test() {
set -- cargo test $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@"
einfo "${@}"
- "${@}" || die "cargo test failed"
+ cargo_env "${@}" || die "cargo test failed"
}
fi
--
2.45.2
Re: [gentoo-dev] [PATCH 1/3] cargo.eclass: Add cargo_env helper and use it in compile, test, install
On Wed, 2024-07-24 at 18:14 -0400, Eli Schwartz wrote: > On 7/24/24 6:07 PM, James Le Cuirot wrote: > > Rust packages have a tendency to rebuild parts during test and install. > > It is not clear whether this can be addressed. We were therefore relying > > on some environment variables set during the compile phase for > > cross-compiling to work in the later phases. This is not ideal, > > especially if you need to build for multiple targets. > > > Oof, yeah, as I mentioned on Monday in -dev, I have a package that > actually produces meaningfully different programs if you rebuild it > during test. > > dev-util/ruff will, when built with FEATURES=test, not show color when > you run it. Don't know why, feel a bit too freaked out about rebuilding > for tests *at all* to even think about fixing this in a "src_test > compatible way". > > So I wonder if maybe we can somehow switch to e.g. doing the test phase > in a different directory such that it doesn't modify the artifacts we > actually want to install. It can happen due to files or environment variables changing. It sounds like the tests inadvertently cause that in this case. You could copy the $(cargo_target_dir) to $(cargo_target_dir)-test and then set CARGO_TARGET_DIR to the latter before running the tests. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] savedconfig.eclass: Drop support for EAPI 6
On Thu, 2024-07-25 at 07:35 +0200, Ulrich Müller wrote:
> Signed-off-by: Ulrich Müller
> ---
> eclass/savedconfig.eclass | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/eclass/savedconfig.eclass b/eclass/savedconfig.eclass
> index cc5748543078..65a1f3bfd800 100644
> --- a/eclass/savedconfig.eclass
> +++ b/eclass/savedconfig.eclass
> @@ -1,10 +1,10 @@
> -# Copyright 1999-2023 Gentoo Authors
> +# Copyright 1999-2024 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
>
> # @ECLASS: savedconfig.eclass
> # @MAINTAINER:
> # base-sys...@gentoo.org
> -# @SUPPORTED_EAPIS: 6 7 8
> +# @SUPPORTED_EAPIS: 7 8
> # @BLURB: common API for saving/restoring complex configuration files
> # @DESCRIPTION:
> # It is not uncommon to come across a package which has a very fine
> @@ -31,7 +31,7 @@
> # build.
>
> case ${EAPI} in
> - 6|7|8) ;;
> + 7|8) ;;
> *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
> esac
>
> @@ -60,12 +60,12 @@ save_config() {
> if [[ $# -eq 1 && -f $1 ]] ; then
> # Just one file, so have the ${configfile} be that config file
> dodir "${configfile%/*}"
> - cp "$@" "${ED%/}/${configfile}" || die "failed to save $*"
> + cp "$@" "${ED}/${configfile}" || die "failed to save $*"
> else
> # A dir, or multiple files, so have the ${configfile} be a dir
> # with all the saved stuff below it
> dodir "${configfile}"
> - treecopy "$@" "${ED%/}/${configfile}" || die "failed to save $*"
> + treecopy "$@" "${ED}/${configfile}" || die "failed to save $*"
> fi
>
> elog "Your configuration for ${CATEGORY}/${PF} has been saved in "
> @@ -150,7 +150,7 @@ savedconfig_pkg_postinst() {
> # are worse :/.
>
> if use savedconfig ; then
> - find "${EROOT%/}/etc/portage/savedconfig/${CATEGORY}/${PF}" \
> + find "${EROOT}/etc/portage/savedconfig/${CATEGORY}/${PF}" \
> -exec touch {} + 2>/dev/null
> fi
> }
Ack.
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH 3/3 v2] cargo.eclass: Explicitly tell rustc not to strip binaries
Most projects don't strip binaries in release mode by default, but there
are exceptions like app-misc/broot.
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 9ccd482e6b2d1..2a71b6c938fb6 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -548,13 +548,13 @@ cargo_env() {
# RUSTFLAGS. The given linker cannot include any arguments, so split
these
# into link-args along with LDFLAGS. Also include external RUSTFLAGS.
local LD_A=( ${HOST_CC} ${BUILD_LDFLAGS} )
- declare -x CARGO_BUILD_RUSTFLAGS="${RUSTFLAGS} ${CARGO_BUILD_RUSTFLAGS}
-C linker=${LD_A[0]}"
+ declare -x CARGO_BUILD_RUSTFLAGS="-C strip=none ${RUSTFLAGS}
${CARGO_BUILD_RUSTFLAGS} -C linker=${LD_A[0]}"
[[ ${#LD_A[@]} -gt 1 ]] && declare CARGO_BUILD_RUSTFLAGS+="$(printf --
' -C link-arg=%s' "${LD_A[@]:1}")"
if tc-is-cross-compiler; then
declare -x CARGO_BUILD_TARGET=$(rust_abi)
local TRIPLE=${CARGO_BUILD_TARGET//-/_} LD_A=( $(tc-getCC)
${LDFLAGS} )
- declare -x CARGO_TARGET_"${TRIPLE^^}"_RUSTFLAGS="${RUSTFLAGS}
${CARGO_TARGET_RUSTFLAGS} -C linker=${LD_A[0]}"
+ declare -x CARGO_TARGET_"${TRIPLE^^}"_RUSTFLAGS="-C strip=none
${RUSTFLAGS} ${CARGO_TARGET_RUSTFLAGS} -C linker=${LD_A[0]}"
[[ ${#LD_A[@]} -gt 1 ]] && declare
CARGO_TARGET_"${TRIPLE^^}"_RUSTFLAGS+="$(printf -- ' -C link-arg=%s'
"${LD_A[@]:1}")"
else
CARGO_BUILD_RUSTFLAGS+=" ${CARGO_TARGET_RUSTFLAGS}"
--
2.45.2
[gentoo-dev] [PATCH 2/3 v2] cargo.eclass: Handle LDFLAGS and RUSTFLAGS better
LDFLAGS are not currently honoured by Cargo builds at all. It would be
particularly advantageous to honour -fuse-ld because alternative linkers
like mold are known to be significantly faster at handling Rust.
As things stand, the eclass sets the linker to CC when cross-compiling,
but it does so erroneously due to a shell quoting issue. If CC includes
arguments, an error occurs when setting the CARGO_TARGET_*_LINKER
variable. Even with the right quoting, Cargo still fails because this
variable is not allowed to include arguments. They have to be specified
via RUSTFLAGS instead.
We would also like to configure the build host linker properly when
cross-compiling, but strangely there is no equivalent linker variable
for the build host. It can only be set via RUSTFLAGS. For consistency,
we now use RUSTFLAGS for the target host linker as well.
Some ebuilds already set RUSTFLAGS, so some consideration was given to
how to handle these. When set, Cargo prioritises RUSTFLAGS over
CARGO_BUILD_RUSTFLAGS and CARGO_TARGET_*_RUSTFLAGS, so we need it unset
to allow different flags for the build and target hosts. We can still
include its contents in the latter variables for convenience though.
It should not be necessary for ebuilds to figure out which Rust ABI is
applicable in order to set flags only for the target host, so the helper
reads from a simple CARGO_TARGET_RUSTFLAGS variable without the triple
for convenience.
Unfortunately, I have not yet encountered a package that makes use of
CARGO_BUILD_RUSTFLAGS while cross-compiling, but as far as I can tell,
it should work.
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 45 -
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index b6d5fe21f0a7b..9ccd482e6b2d1 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -527,27 +527,46 @@ cargo_src_configure() {
# @USAGE: Command with its arguments
# @DESCRIPTION:
# Run the given command under an environment needed for performing tasks with
-# Cargo such as building.
+# Cargo such as building. RUSTFLAGS is used for both the build and target host.
+# CARGO_BUILD_RUSTFLAGS and CARGO_TARGET_RUSTFLAGS are used for just the build
+# host and target host respectively. Ensure these are set consistently between
+# Cargo invocations, otherwise rebuilds will occur.
cargo_env() {
filter-lto
tc-export AR CC CXX PKG_CONFIG
+ # Set vars for cc-rs crate.
+ tc-export_build_env
+ declare -x \
+ HOST_AR=$(tc-getBUILD_AR)
+ HOST_CC=$(tc-getBUILD_CC)
+ HOST_CXX=$(tc-getBUILD_CXX)
+ HOST_CFLAGS=${BUILD_CFLAGS}
+ HOST_CXXFLAGS=${BUILD_CXXFLAGS}
+
+ # The default linker is "cc" so override by setting linker to CC in the
+ # RUSTFLAGS. The given linker cannot include any arguments, so split
these
+ # into link-args along with LDFLAGS. Also include external RUSTFLAGS.
+ local LD_A=( ${HOST_CC} ${BUILD_LDFLAGS} )
+ declare -x CARGO_BUILD_RUSTFLAGS="${RUSTFLAGS} ${CARGO_BUILD_RUSTFLAGS}
-C linker=${LD_A[0]}"
+ [[ ${#LD_A[@]} -gt 1 ]] && declare CARGO_BUILD_RUSTFLAGS+="$(printf --
' -C link-arg=%s' "${LD_A[@]:1}")"
+
if tc-is-cross-compiler; then
declare -x CARGO_BUILD_TARGET=$(rust_abi)
- local TRIPLE=${CARGO_BUILD_TARGET//-/_}
- declare -x CARGO_TARGET_"${TRIPLE^^}"_LINKER=$(tc-getCC)
-
- # Set vars for cc-rs crate.
- tc-export_build_env
- declare -x \
- HOST_AR=$(tc-getBUILD_AR)
- HOST_CC=$(tc-getBUILD_CC)
- HOST_CXX=$(tc-getBUILD_CXX)
- HOST_CFLAGS=${BUILD_CFLAGS}
- HOST_CXXFLAGS=${BUILD_CXXFLAGS}
+ local TRIPLE=${CARGO_BUILD_TARGET//-/_} LD_A=( $(tc-getCC)
${LDFLAGS} )
+ declare -x CARGO_TARGET_"${TRIPLE^^}"_RUSTFLAGS="${RUSTFLAGS}
${CARGO_TARGET_RUSTFLAGS} -C linker=${LD_A[0]}"
+ [[ ${#LD_A[@]} -gt 1 ]] && declare
CARGO_TARGET_"${TRIPLE^^}"_RUSTFLAGS+="$(printf -- ' -C link-arg=%s'
"${LD_A[@]:1}")"
+ else
+ CARGO_BUILD_RUSTFLAGS+=" ${CARGO_TARGET_RUSTFLAGS}"
fi
- "${@}"
+ (
+ # Bare RUSTFLAGS will override the above, even if empty, so
unset it
+ # locally. Do this in a subshell so that it remains set
afterwards.
+ unset RUSTFLAGS
+
+ "${@}"
+ )
}
# @FUNCTION: cargo_src_compile
--
2.45.2
[gentoo-dev] [PATCH 1/3 v2] cargo.eclass: Add cargo_env helper and use it in compile, test, install
Rust packages have a tendency to rebuild parts during test and install.
It is not clear whether this can be addressed. We were therefore relying
on some environment variables set during the compile phase for
cross-compiling to work in the later phases. This is not ideal,
especially if you need to build for multiple targets.
These environment variables can also be useful in other contexts, such
as the build runner in app-misc/anki.
This change moves the setting of these variables into a separate helper
that is now used in all these phases and can be used by ebuilds too. The
variables are now kept local to each invocation of this helper,
preventing leakage.
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 37 +++--
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 7db34efb4e174..b6d5fe21f0a7b 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -523,26 +523,23 @@ cargo_src_configure() {
[[ ${ECARGO_ARGS[@]} ]] && einfo "Configured with: ${ECARGO_ARGS[@]}"
}
-# @FUNCTION: cargo_src_compile
+# @FUNCTION: cargo_env
+# @USAGE: Command with its arguments
# @DESCRIPTION:
-# Build the package using cargo build.
-cargo_src_compile() {
- debug-print-function ${FUNCNAME} "$@"
-
- [[ ${_CARGO_GEN_CONFIG_HAS_RUN} ]] || \
- die "FATAL: please call cargo_gen_config before using
${FUNCNAME}"
-
+# Run the given command under an environment needed for performing tasks with
+# Cargo such as building.
+cargo_env() {
filter-lto
tc-export AR CC CXX PKG_CONFIG
if tc-is-cross-compiler; then
- export CARGO_BUILD_TARGET=$(rust_abi)
+ declare -x CARGO_BUILD_TARGET=$(rust_abi)
local TRIPLE=${CARGO_BUILD_TARGET//-/_}
- export CARGO_TARGET_"${TRIPLE^^}"_LINKER=$(tc-getCC)
+ declare -x CARGO_TARGET_"${TRIPLE^^}"_LINKER=$(tc-getCC)
# Set vars for cc-rs crate.
tc-export_build_env
- export \
+ declare -x \
HOST_AR=$(tc-getBUILD_AR)
HOST_CC=$(tc-getBUILD_CC)
HOST_CXX=$(tc-getBUILD_CXX)
@@ -550,9 +547,21 @@ cargo_src_compile() {
HOST_CXXFLAGS=${BUILD_CXXFLAGS}
fi
+ "${@}"
+}
+
+# @FUNCTION: cargo_src_compile
+# @DESCRIPTION:
+# Build the package using cargo build.
+cargo_src_compile() {
+ debug-print-function ${FUNCNAME} "$@"
+
+ [[ ${_CARGO_GEN_CONFIG_HAS_RUN} ]] || \
+ die "FATAL: please call cargo_gen_config before using
${FUNCNAME}"
+
set -- cargo build $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@"
einfo "${@}"
- "${@}" || die "cargo build failed"
+ cargo_env "${@}" || die "cargo build failed"
}
# @FUNCTION: cargo_src_install
@@ -573,7 +582,7 @@ cargo_src_install() {
$(usex debug --debug "") \
${ECARGO_ARGS[@]} "$@"
einfo "${@}"
- "${@}" || die "cargo install failed"
+ cargo_env "${@}" || die "cargo install failed"
rm -f "${ED}/usr/.crates.toml" || die
rm -f "${ED}/usr/.crates2.json" || die
@@ -590,7 +599,7 @@ cargo_src_test() {
set -- cargo test $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@"
einfo "${@}"
- "${@}" || die "cargo test failed"
+ cargo_env "${@}" || die "cargo test failed"
}
fi
--
2.45.2
[gentoo-dev] [PATCH 3/3] cargo.eclass: Explicitly tell rustc not to strip binaries
Most projects don't strip binaries in release mode by default, but there
are exceptions like app-misc/broot.
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 65eaee6f84e4b..7ae40608aeb5a 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -550,14 +550,14 @@ cargo_env() {
local LD_A=( ${HOST_CC} ${BUILD_LDFLAGS} )
declare -x CARGO_BUILD_RUSTFLAGS="-C linker=${LD_A[0]}"
[[ ${#LD_A[@]} -gt 1 ]] && declare CARGO_BUILD_RUSTFLAGS+="$(printf --
' -C link-arg=%s' "${LD_A[@]:1}")"
- declare CARGO_BUILD_RUSTFLAGS+=" ${RUSTFLAGS} ${CARGO_BUILD_RUSTFLAGS}"
+ declare CARGO_BUILD_RUSTFLAGS+=" -C strip=none ${RUSTFLAGS}
${CARGO_BUILD_RUSTFLAGS}"
if tc-is-cross-compiler; then
declare -x CARGO_BUILD_TARGET=$(rust_abi)
local TRIPLE=${CARGO_BUILD_TARGET//-/_} LD_A=( $(tc-getCC)
${LDFLAGS} )
declare -x CARGO_TARGET_"${TRIPLE^^}"_RUSTFLAGS="-C
linker=${LD_A[0]}"
[[ ${#LD_A[@]} -gt 1 ]] && declare
CARGO_TARGET_"${TRIPLE^^}"_RUSTFLAGS+="$(printf -- ' -C link-arg=%s'
"${LD_A[@]:1}")"
- declare CARGO_TARGET_"${TRIPLE^^}"_RUSTFLAGS+=" ${RUSTFLAGS}
${CARGO_TARGET_RUSTFLAGS}"
+ declare CARGO_TARGET_"${TRIPLE^^}"_RUSTFLAGS+=" -C strip=none
${RUSTFLAGS} ${CARGO_TARGET_RUSTFLAGS}"
else
CARGO_BUILD_RUSTFLAGS+=" ${CARGO_TARGET_RUSTFLAGS}"
fi
--
2.45.2
[gentoo-dev] [PATCH 2/3] cargo.eclass: Handle LDFLAGS and RUSTFLAGS better
LDFLAGS are not currently honoured by Cargo builds at all. It would be
particularly advantageous to honour -fuse-ld because alternative linkers
like mold are known to be significantly faster at handling Rust.
As things stand, the eclass sets the linker to CC when cross-compiling,
but it does so erroneously due to a shell quoting issue. If CC includes
arguments, an error occurs when setting the CARGO_TARGET_*_LINKER
variable. Even with the right quoting, Cargo still fails because this
variable is not allowed to include arguments. They have to be specified
via RUSTFLAGS instead.
We would also like to configure the build host linker properly when
cross-compiling, but strangely there is no equivalent linker variable
for the build host. It can only be set via RUSTFLAGS. For consistency,
we now use RUSTFLAGS for the target host linker as well.
Some ebuilds already set RUSTFLAGS, so some consideration was given to
how to handle these. When set, Cargo prioritises RUSTFLAGS over
CARGO_BUILD_RUSTFLAGS and CARGO_TARGET_*_RUSTFLAGS, so we need it unset
to allow different flags for the build and target hosts. We can still
include its contents in the latter variables for convenience though.
It should not be necessary for ebuilds to figure out which Rust ABI is
applicable in order to set flags only for the target host, so the helper
reads from a simple CARGO_TARGET_RUSTFLAGS variable without the triple
for convenience.
Unfortunately, I have not yet encountered a package that makes use of
CARGO_BUILD_RUSTFLAGS while cross-compiling, but as far as I can tell,
it should work.
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 47 -
1 file changed, 34 insertions(+), 13 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index b6d5fe21f0a7b..65eaee6f84e4b 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -527,27 +527,48 @@ cargo_src_configure() {
# @USAGE: Command with its arguments
# @DESCRIPTION:
# Run the given command under an environment needed for performing tasks with
-# Cargo such as building.
+# Cargo such as building. RUSTFLAGS is used for both the build and target host.
+# CARGO_BUILD_RUSTFLAGS and CARGO_TARGET_RUSTFLAGS are used for just the build
+# host and target host respectively. Ensure these are set consistently between
+# Cargo invocations, otherwise rebuilds will occur.
cargo_env() {
filter-lto
tc-export AR CC CXX PKG_CONFIG
+ # Set vars for cc-rs crate.
+ tc-export_build_env
+ declare -x \
+ HOST_AR=$(tc-getBUILD_AR)
+ HOST_CC=$(tc-getBUILD_CC)
+ HOST_CXX=$(tc-getBUILD_CXX)
+ HOST_CFLAGS=${BUILD_CFLAGS}
+ HOST_CXXFLAGS=${BUILD_CXXFLAGS}
+
+ # The default linker is "cc" so override by setting linker to CC in the
+ # RUSTFLAGS. The given linker cannot include any arguments, so split
these
+ # into link-args along with LDFLAGS. Also include external RUSTFLAGS.
+ local LD_A=( ${HOST_CC} ${BUILD_LDFLAGS} )
+ declare -x CARGO_BUILD_RUSTFLAGS="-C linker=${LD_A[0]}"
+ [[ ${#LD_A[@]} -gt 1 ]] && declare CARGO_BUILD_RUSTFLAGS+="$(printf --
' -C link-arg=%s' "${LD_A[@]:1}")"
+ declare CARGO_BUILD_RUSTFLAGS+=" ${RUSTFLAGS} ${CARGO_BUILD_RUSTFLAGS}"
+
if tc-is-cross-compiler; then
declare -x CARGO_BUILD_TARGET=$(rust_abi)
- local TRIPLE=${CARGO_BUILD_TARGET//-/_}
- declare -x CARGO_TARGET_"${TRIPLE^^}"_LINKER=$(tc-getCC)
-
- # Set vars for cc-rs crate.
- tc-export_build_env
- declare -x \
- HOST_AR=$(tc-getBUILD_AR)
- HOST_CC=$(tc-getBUILD_CC)
- HOST_CXX=$(tc-getBUILD_CXX)
- HOST_CFLAGS=${BUILD_CFLAGS}
- HOST_CXXFLAGS=${BUILD_CXXFLAGS}
+ local TRIPLE=${CARGO_BUILD_TARGET//-/_} LD_A=( $(tc-getCC)
${LDFLAGS} )
+ declare -x CARGO_TARGET_"${TRIPLE^^}"_RUSTFLAGS="-C
linker=${LD_A[0]}"
+ [[ ${#LD_A[@]} -gt 1 ]] && declare
CARGO_TARGET_"${TRIPLE^^}"_RUSTFLAGS+="$(printf -- ' -C link-arg=%s'
"${LD_A[@]:1}")"
+ declare CARGO_TARGET_"${TRIPLE^^}"_RUSTFLAGS+=" ${RUSTFLAGS}
${CARGO_TARGET_RUSTFLAGS}"
+ else
+ CARGO_BUILD_RUSTFLAGS+=" ${CARGO_TARGET_RUSTFLAGS}"
fi
- "${@}"
+ (
+ # Bare RUSTFLAGS will override the above, even if empty, so
unset it
+ # locally. Do this in a subshell so that it remains set
afterwards.
+ unset RUSTFLAGS
+
+ "${@}"
+ )
}
# @FUNCTION: cargo_src_compile
--
2.45.2
[gentoo-dev] [PATCH 1/3] cargo.eclass: Add cargo_env helper and use it in compile, test, install
Rust packages have a tendency to rebuild parts during test and install.
It is not clear whether this can be addressed. We were therefore relying
on some environment variables set during the compile phase for
cross-compiling to work in the later phases. This is not ideal,
especially if you need to build for multiple targets.
These environment variables can also be useful in other contexts, such
as the build runner in app-misc/anki.
This change moves the setting of these variables into a separate helper
that is now used in all these phases and can be used by ebuilds too. The
variables are now kept local to each invocation of this helper,
preventing leakage.
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 37 +++--
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 7db34efb4e174..b6d5fe21f0a7b 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -523,26 +523,23 @@ cargo_src_configure() {
[[ ${ECARGO_ARGS[@]} ]] && einfo "Configured with: ${ECARGO_ARGS[@]}"
}
-# @FUNCTION: cargo_src_compile
+# @FUNCTION: cargo_env
+# @USAGE: Command with its arguments
# @DESCRIPTION:
-# Build the package using cargo build.
-cargo_src_compile() {
- debug-print-function ${FUNCNAME} "$@"
-
- [[ ${_CARGO_GEN_CONFIG_HAS_RUN} ]] || \
- die "FATAL: please call cargo_gen_config before using
${FUNCNAME}"
-
+# Run the given command under an environment needed for performing tasks with
+# Cargo such as building.
+cargo_env() {
filter-lto
tc-export AR CC CXX PKG_CONFIG
if tc-is-cross-compiler; then
- export CARGO_BUILD_TARGET=$(rust_abi)
+ declare -x CARGO_BUILD_TARGET=$(rust_abi)
local TRIPLE=${CARGO_BUILD_TARGET//-/_}
- export CARGO_TARGET_"${TRIPLE^^}"_LINKER=$(tc-getCC)
+ declare -x CARGO_TARGET_"${TRIPLE^^}"_LINKER=$(tc-getCC)
# Set vars for cc-rs crate.
tc-export_build_env
- export \
+ declare -x \
HOST_AR=$(tc-getBUILD_AR)
HOST_CC=$(tc-getBUILD_CC)
HOST_CXX=$(tc-getBUILD_CXX)
@@ -550,9 +547,21 @@ cargo_src_compile() {
HOST_CXXFLAGS=${BUILD_CXXFLAGS}
fi
+ "${@}"
+}
+
+# @FUNCTION: cargo_src_compile
+# @DESCRIPTION:
+# Build the package using cargo build.
+cargo_src_compile() {
+ debug-print-function ${FUNCNAME} "$@"
+
+ [[ ${_CARGO_GEN_CONFIG_HAS_RUN} ]] || \
+ die "FATAL: please call cargo_gen_config before using
${FUNCNAME}"
+
set -- cargo build $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@"
einfo "${@}"
- "${@}" || die "cargo build failed"
+ cargo_env "${@}" || die "cargo build failed"
}
# @FUNCTION: cargo_src_install
@@ -573,7 +582,7 @@ cargo_src_install() {
$(usex debug --debug "") \
${ECARGO_ARGS[@]} "$@"
einfo "${@}"
- "${@}" || die "cargo install failed"
+ cargo_env "${@}" || die "cargo install failed"
rm -f "${ED}/usr/.crates.toml" || die
rm -f "${ED}/usr/.crates2.json" || die
@@ -590,7 +599,7 @@ cargo_src_test() {
set -- cargo test $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@"
einfo "${@}"
- "${@}" || die "cargo test failed"
+ cargo_env "${@}" || die "cargo test failed"
}
fi
--
2.45.2
[gentoo-dev] [PATCH 8/8] dev-lang/go: Use go-env.eclass in 1.22.5 and 9999
This deduplicates some helper functions.
Signed-off-by: James Le Cuirot
---
dev-lang/go/go-1.22.5.ebuild | 65 +---
dev-lang/go/go-.ebuild | 65 +---
2 files changed, 18 insertions(+), 112 deletions(-)
diff --git a/dev-lang/go/go-1.22.5.ebuild b/dev-lang/go/go-1.22.5.ebuild
index fc36a2d33ae98..b16e86ae904f0 100644
--- a/dev-lang/go/go-1.22.5.ebuild
+++ b/dev-lang/go/go-1.22.5.ebuild
@@ -10,7 +10,7 @@ export CTARGET=${CTARGET:-${CHOST}}
GO_BOOTSTRAP_MIN=1.20.14
MY_PV=${PV/_/}
-inherit toolchain-funcs
+inherit go-env toolchain-funcs
case ${PV} in
**)
@@ -33,7 +33,7 @@ HOMEPAGE="https://go.dev";
LICENSE="BSD"
SLOT="0/${PV}"
-IUSE="abi_mips_o32 abi_mips_n64 cpu_flags_x86_sse2"
+IUSE="cpu_flags_x86_sse2"
RDEPEND="
arm? ( sys-devel/binutils[gold] )
@@ -66,55 +66,8 @@ DOCS=(
SECURITY.md
)
-go_arch() {
- # By chance most portage arch names match Go
- local tc_arch=$(tc-arch $@)
- case "${tc_arch}" in
- x86)echo 386;;
- x64-*) echo amd64;;
- loong) echo loong64;;
- mips) if use abi_mips_o32; then
- [[ $(tc-endian $@) = big ]] && echo mips ||
echo mipsle
- elif use abi_mips_n64; then
- [[ $(tc-endian $@) = big ]] && echo mips64 ||
echo mips64le
- fi ;;
- ppc64) [[ $(tc-endian $@) = big ]] && echo ppc64 || echo
ppc64le ;;
- riscv) echo riscv64 ;;
- s390) echo s390x ;;
- *) echo "${tc_arch}";;
- esac
-}
-
-go_arm() {
- case "${1:-${CHOST}}" in
- armv5*) echo 5;;
- armv6*) echo 6;;
- armv7*) echo 7;;
- *)
- die "unknown GOARM for ${1:-${CHOST}}"
- ;;
- esac
-}
-
-go_os() {
- case "${1:-${CHOST}}" in
- *-linux*) echo linux;;
- *-darwin*) echo darwin;;
- *-freebsd*) echo freebsd;;
- *-netbsd*) echo netbsd;;
- *-openbsd*) echo openbsd;;
- *-solaris*) echo solaris;;
- *-cygwin*|*-interix*|*-winnt*)
- echo windows
- ;;
- *)
- die "unknown GOOS for ${1:-${CHOST}}"
- ;;
- esac
-}
-
go_tuple() {
- echo "$(go_os $@)_$(go_arch $@)"
+ echo "$(go-env_goos $@)_$(go-env_goarch $@)"
}
go_cross_compile() {
@@ -140,16 +93,16 @@ src_compile() {
export GOBIN="${GOROOT}/bin"
# Go's build script does not use BUILD/HOST/TARGET consistently. :(
- export GOHOSTARCH=$(go_arch ${CBUILD})
- export GOHOSTOS=$(go_os ${CBUILD})
+ export GOHOSTARCH=$(go-env_goarch ${CBUILD})
+ export GOHOSTOS=$(go-env_goos ${CBUILD})
export CC=$(tc-getBUILD_CC)
- export GOARCH=$(go_arch)
- export GOOS=$(go_os)
+ export GOARCH=$(go-env_goarch)
+ export GOOS=$(go-env_goos)
export CC_FOR_TARGET=$(tc-getCC)
export CXX_FOR_TARGET=$(tc-getCXX)
- use arm && export GOARM=$(go_arm)
- use x86 && export GO386=$(usex cpu_flags_x86_sse2 '' 'softfloat')
+ use arm && export GOARM=$(go-env_goarm)
+ use x86 && export GO386=$(go-env_go386)
cd src
bash -x ./make.bash || die "build failed"
diff --git a/dev-lang/go/go-.ebuild b/dev-lang/go/go-.ebuild
index fc36a2d33ae98..b16e86ae904f0 100644
--- a/dev-lang/go/go-.ebuild
+++ b/dev-lang/go/go-.ebuild
@@ -10,7 +10,7 @@ export CTARGET=${CTARGET:-${CHOST}}
GO_BOOTSTRAP_MIN=1.20.14
MY_PV=${PV/_/}
-inherit toolchain-funcs
+inherit go-env toolchain-funcs
case ${PV} in
**)
@@ -33,7 +33,7 @@ HOMEPAGE="https://go.dev";
LICENSE="BSD"
SLOT="0/${PV}"
-IUSE="abi_mips_o32 abi_mips_n64 cpu_flags_x86_sse2"
+IUSE="cpu_flags_x86_sse2"
RDEPEND="
arm? ( sys-devel/binutils[gold] )
@@ -66,55 +66,8 @@ DOCS=(
SECURITY.md
)
-go_arch() {
- # By chance most portage arch names match Go
- local tc_arch=$(tc-arch $@)
- case "${tc_arch}" in
- x86)echo 386;;
- x64-*) echo amd64;;
- loong) echo loong64;;
- mips) if use abi_mips_o32; then
- [[ $(tc-endian $@) = big ]] && echo mips ||
echo mipsle
- elif use abi_mips_n64; then
- [[ $(tc-endian $@) = big ]] && echo mips64 ||
echo mips64le
-
[gentoo-dev] [PATCH 7/8] go-env.eclass: Add the go-env_goos() helper function
This code is taken from dev-lang/go. No other packages have code like
this, but some erroneously call `go env GOOS`, which is bad for
cross-compiling. They should use this function instead.
Signed-off-by: James Le Cuirot
---
eclass/go-env.eclass | 18 ++
1 file changed, 18 insertions(+)
diff --git a/eclass/go-env.eclass b/eclass/go-env.eclass
index c839c41be0d7e..be131133113be 100644
--- a/eclass/go-env.eclass
+++ b/eclass/go-env.eclass
@@ -48,6 +48,24 @@ go-env_set_compile_environment() {
export CGO_LDFLAGS="${CGO_LDFLAGS:-$LDFLAGS}"
}
+# @FUNCTION: go-env_goos
+# @USAGE: [toolchain prefix]
+# @DESCRIPTION:
+# Returns the appropriate GOOS setting for the target operating system.
+go-env_goos() {
+ local target=${1:-${CHOST}}
+ case "${target}" in
+ *-linux*) echo linux ;;
+ *-darwin*) echo darwin ;;
+ *-freebsd*) echo freebsd ;;
+ *-netbsd*) echo netbsd ;;
+ *-openbsd*) echo openbsd ;;
+ *-solaris*) echo solaris ;;
+ *-cygwin*|*-interix*|*-winnt*) echo windows ;;
+ *) die "unknown GOOS for ${target}" ;;
+ esac
+}
+
# @FUNCTION: go-env_goarch
# @USAGE: [toolchain prefix]
# @DESCRIPTION:
--
2.45.2
[gentoo-dev] [PATCH 6/8] go-env.eclass: Rewrite the go-env_goarch() logic
The previous logic was flawed, incomplete, and needlessly made use of
USE flags. We can rely on the tuple instead. Tested against all the
tuples we have in our profiles.
Signed-off-by: James Le Cuirot
---
eclass/go-env.eclass | 32 +---
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/eclass/go-env.eclass b/eclass/go-env.eclass
index c34c634bb6003..c839c41be0d7e 100644
--- a/eclass/go-env.eclass
+++ b/eclass/go-env.eclass
@@ -53,21 +53,23 @@ go-env_set_compile_environment() {
# @DESCRIPTION:
# Returns the appropriate GOARCH setting for the target architecture.
go-env_goarch() {
- # By chance most portage arch names match Go
- local tc_arch=$(tc-arch $@)
- case "${tc_arch}" in
- x86)echo 386;;
- x64-*) echo amd64;;
- loong) echo loong64;;
- mips) if use abi_mips_o32; then
- [[ $(tc-endian $@) = big ]] && echo mips ||
echo mipsle
- elif use abi_mips_n64; then
- [[ $(tc-endian $@) = big ]] && echo mips64 ||
echo mips64le
- fi ;;
- ppc64) [[ $(tc-endian $@) = big ]] && echo ppc64 || echo
ppc64le ;;
- riscv) echo riscv64 ;;
- s390) echo s390x ;;
- *) echo "${tc_arch}";;
+ local target=${1:-${CHOST}}
+ # Some Portage arch names match Go.
+ local arch=$(tc-arch "${target}") cpu=${target%%-*}
+ case "${arch}" in
+ x86)echo 386 ;;
+ loong) echo loong64 ;;
+ *) case "${cpu}" in
+ aarch64*be) echo arm64be ;;
+ arm64) echo arm64 ;;
+ arm*b*) echo armbe ;;
+ mips64*l*) echo mips64le ;;
+ mips*l*) echo mipsle ;;
+ powerpc64le*) echo ppc64le ;;
+ arm64|s390x) echo "${cpu}" ;;
+ mips64*|riscv64*|sparc64*) echo
"${arch}64" ;;
+ *) echo "${arch}" ;;
+ esac ;;
esac
}
--
2.45.2
[gentoo-dev] [PATCH 5/8] go-env.eclass: Establish EAPI 7 and 8 as supported
Signed-off-by: James Le Cuirot
---
eclass/go-env.eclass | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/eclass/go-env.eclass b/eclass/go-env.eclass
index 1a2c9787a146b..c34c634bb6003 100644
--- a/eclass/go-env.eclass
+++ b/eclass/go-env.eclass
@@ -6,11 +6,17 @@
# Flatcar Linux Maintainers
# @AUTHOR:
# Flatcar Linux Maintainers
+# @SUPPORTED_EAPIS: 7 8
# @BLURB: Helper eclass for setting the Go compile environment. Required for
cross-compiling.
# @DESCRIPTION:
# This eclass includes helper functions for setting the compile environment
for Go ebuilds.
# Intended to be called by other Go eclasses in an early build stage, e.g.
src_unpack.
+case ${EAPI} in
+ 7|8) ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
+
if [[ -z ${_GO_ENV_ECLASS} ]]; then
_GO_ENV_ECLASS=1
@@ -34,14 +40,7 @@ go-env_set_compile_environment() {
use x86 && export GO386=$(go-env_go386)
# XXX: Hack for checking ICE (bug #912152, gcc PR113204)
- case ${EAPI} in
- 6)
- has_version "sys-devel/gcc[debug]" && filter-lto
- ;;
- *)
- has_version -b "sys-devel/gcc[debug]" && filter-lto
- ;;
- esac
+ has_version -b "sys-devel/gcc[debug]" && filter-lto
export CGO_CFLAGS="${CGO_CFLAGS:-$CFLAGS}"
export CGO_CPPFLAGS="${CGO_CPPFLAGS:-$CPPFLAGS}"
--
2.45.2
[gentoo-dev] [PATCH 4/8] golang-base.eclass: Drop support for EAPI 5 and 6
All such usage has gone.
Signed-off-by: James Le Cuirot
---
eclass/golang-base.eclass | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/eclass/golang-base.eclass b/eclass/golang-base.eclass
index 4bba00200cfc9..a2996e3b06836 100644
--- a/eclass/golang-base.eclass
+++ b/eclass/golang-base.eclass
@@ -1,10 +1,10 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2024 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: golang-base.eclass
# @MAINTAINER:
# William Hubbs
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 7
# @BLURB: Eclass that provides base functions for Go packages.
# @DEPRECATED: go-module.eclass
# @DESCRIPTION:
@@ -12,12 +12,9 @@
# programming language; it also provides the build-time dependency on
# dev-lang/go.
-case "${EAPI:-0}" in
- 5|6|7)
- ;;
- *)
- die "${ECLASS}: Unsupported EAPI (EAPI=${EAPI})"
- ;;
+case ${EAPI} in
+ 7) ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
if [[ -z ${_GOLANG_BASE} ]]; then
--
2.45.2
[gentoo-dev] [PATCH 3/8] golang-build.eclass: Drop support for EAPI 6
All such usage has gone.
Signed-off-by: James Le Cuirot
---
eclass/golang-build.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/golang-build.eclass b/eclass/golang-build.eclass
index 235313bd70f5d..b5218ce36572f 100644
--- a/eclass/golang-build.eclass
+++ b/eclass/golang-build.eclass
@@ -1,10 +1,10 @@
-# Copyright 1999-2023 Gentoo Authors
+# Copyright 1999-2024 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: golang-build.eclass
# @MAINTAINER:
# William Hubbs
-# @SUPPORTED_EAPIS: 6 7
+# @SUPPORTED_EAPIS: 7
# @PROVIDES: golang-base
# @BLURB: Eclass for compiling go packages.
# @DEPRECATED: go-module.eclass
@@ -13,7 +13,7 @@
# functions for software written in the Go programming language.
case ${EAPI} in
- 6|7) ;;
+ 7) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
--
2.45.2
[gentoo-dev] [PATCH 2/8] golang-vcs-snapshot.eclass: Drop support for EAPI 6
All such usage has gone.
Signed-off-by: James Le Cuirot
---
eclass/golang-vcs-snapshot.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/golang-vcs-snapshot.eclass
b/eclass/golang-vcs-snapshot.eclass
index d34b8a6e913da..a91ddbbe36150 100644
--- a/eclass/golang-vcs-snapshot.eclass
+++ b/eclass/golang-vcs-snapshot.eclass
@@ -1,10 +1,10 @@
-# Copyright 1999-2023 Gentoo Authors
+# Copyright 1999-2024 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: golang-vcs-snapshot.eclass
# @MAINTAINER:
# William Hubbs
-# @SUPPORTED_EAPIS: 6 7
+# @SUPPORTED_EAPIS: 7
# @PROVIDES: golang-base
# @BLURB: eclass to unpack VCS snapshot tarballs for Go software
# @DEPRECATED: go-module.eclass
@@ -45,7 +45,7 @@
# and add the vendored tarballs to ${WORKDIR}/src/${EGO_PN}/vendor
case ${EAPI} in
- 6|7) ;;
+ 7) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
--
2.45.2
[gentoo-dev] [PATCH 1/8] golang-vcs.eclass: Drop support for EAPI 6
All such usage has gone.
Signed-off-by: James Le Cuirot
---
eclass/golang-vcs.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/golang-vcs.eclass b/eclass/golang-vcs.eclass
index 6f7a837bc15fd..dee040505d237 100644
--- a/eclass/golang-vcs.eclass
+++ b/eclass/golang-vcs.eclass
@@ -1,10 +1,10 @@
-# Copyright 1999-2023 Gentoo Authors
+# Copyright 1999-2024 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: golang-vcs.eclass
# @MAINTAINER:
# William Hubbs
-# @SUPPORTED_EAPIS: 6 7
+# @SUPPORTED_EAPIS: 7
# @PROVIDES: golang-base
# @BLURB: Eclass for fetching and unpacking go repositories.
# @DEPRECATED: go-module.eclass
@@ -13,7 +13,7 @@
# of software written in the Go programming language.
case ${EAPI} in
- 6|7) ;;
+ 7) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
--
2.45.2
Re: [gentoo-dev] Last rites: games-arcade/{spacerider,tuxdash,xsfcave}
On Tue, 2024-07-02 at 14:39 +0400, Vitaly Zdanevich wrote: > > On 7/2/24 14:12, Sam James wrote: > > > > Vitaly Zdanevich writes: > > > > > > > > Ancient > > > > > > Oh, ancient games are sooo bad, no ray tracing, no soul. > > > > > Please see https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct. > > Sorry just painful to see when we lose some old cultural artifacts. > > I cannot install it, no screenshots here > > Anybody know more about this game? Same screenshots, videos? You imply that I did this out of hand, simply because they were old, but I assure you that I did try all of these games first. You could have easily tried them yourself before sending your message, despite the mask. I have no problem with having merely old games in our repo. It helps if they are still actively maintained, but they don't necessarily have to be. In fact, I have been rather sad to see others drop games in the past. The games still need to have some merit though. We are not a museum, and I would rather focus energy on the much better games that still need our attention. Experiences are subjective, of course, but I seriously doubted I would have found these games entertaining at the time, let alone now. I'll admit that TuxDash had some potential. It honoured the look of the original very well, which I am old enough to have played in the 80s. The maps are entirely random though, so there is practically no skill involved. A quick search revealed many other open source clones that are probably much better. I'll try to be more descriptive in my masks next time. signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: games-arcade/{spacerider,tuxdash,xsfcave}
# James Le Cuirot (2024-07-01) # Ancient, dead upstream, generally awful. # Removal on 2024-08-01. Bugs #935307, #935308, #935309. games-arcade/spacerider games-arcade/tuxdash games-arcade/xsfcave signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] unpacker.eclass: Drop support for EAPI 6
On Mon, 2024-07-01 at 23:36 +0200, Ulrich Müller wrote:
> Signed-off-by: Ulrich Müller
> ---
> eclass/unpacker.eclass | 11 ---
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/eclass/unpacker.eclass b/eclass/unpacker.eclass
> index 2957ca02d3f4..91520a36d16a 100644
> --- a/eclass/unpacker.eclass
> +++ b/eclass/unpacker.eclass
> @@ -4,7 +4,7 @@
> # @ECLASS: unpacker.eclass
> # @MAINTAINER:
> # base-sys...@gentoo.org
> -# @SUPPORTED_EAPIS: 6 7 8
> +# @SUPPORTED_EAPIS: 7 8
> # @BLURB: helpers for extraneous file formats and consistent behavior across
> EAPIs
> # @DESCRIPTION:
> # Some extraneous file formats are not part of PMS, or are only in certain
> @@ -16,7 +16,7 @@
> # - support partial unpacks?
>
> case ${EAPI} in
> - 6|7|8) ;;
> + 7|8) ;;
> *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
> esac
>
> @@ -430,10 +430,7 @@ _unpacker_get_decompressor() {
> echo "xz -T$(makeopts_jobs) -dc" ;;
> *.lz)
> find_lz_unpacker() {
> - local has_version_arg="-b"
> -
> - [[ ${EAPI} == 6 ]] && has_version_arg="--host-root"
> - if has_version "${has_version_arg}"
> ">=app-arch/xz-utils-5.4.0" ; then
> + if has_version -b ">=app-arch/xz-utils-5.4.0" ; then
> echo xz
> return
> fi
> @@ -537,7 +534,7 @@ _unpacker() {
> esac
>
> # 7z, rar and lha/lzh are handled by package manager in EAPI < 8
> - if [[ ${EAPI} != [67] ]]; then
> + if [[ ${EAPI} != 7 ]]; then
> case ${m} in
> *.7z)
> arch="unpack_7z" ;;
Cool. 👍
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Arch Status and Future Plans
On Tue, 2024-06-25 at 20:33 +0300, Arthur Zamarin wrote: > x86 > > Stable 32-bit arch. I'll be honest, I don't believe at all this should > be stable arch anymore. I propose making it dev arch, and mass-dekeyword > stuff we got because of inertia. This arch is close to HW die. (let's > not talk about i486 vs i686). I don't use stable, so I'm biased, but I think this is long overdue. > ppc > > Stable 32-bit arch. Becoming harder and harder with time, with more > broken stuff (which I just destable/dekeyword). > > I propose we convert it into dev arch status, not stable. If folks > disagree, once again mass-dekeyword. I'm inclined to kill it. I actively used hardware once upon a time, but that was nearly 20 years ago. When I dropped Java support for it around 2016ish, I literally one found user. I've never heard of one since. > ppc64 > > Stable 64-bit arch. So, this is a mess of an arch. Consists of both > ppc64ul (big-endian) and ppc64le (little-endian). The latter is much > better supported by upstream. The profiles inheritance inside is a mess > (we even added running 32 userspace on 64 bit kernel, called ppc64/32ul > - just why?). We have devboxes for both BE and LE, so mostly fine. The > profile inheritance is the messiest I've even seen. > > I would hope to split this arch into the two endianness, but I suspect > nobody has the energy to do it. Oh well. > > Next proposal is to cleanup profiles: remove the ppc64/32ul, cleanup > profile inheritance, cleanup the masks and unmasks, and continue with > both ppc64ul & ppc64le supported. I wasn't really in favour of having LE and BE under the same keyword, but I was overruled. My fears have largely proven true. We have seen a lot of issues around graphical stuff. Sure, we've handled it in profiles, but it is a pain. > m68k > > Exp arch, works ? maybe? I've no idea. Let's not touch :) It's not too bad and generally works. I'm a little slow on keywording requests sometimes, but I mostly keep up. I have thought about promoting it from exp to dev now that the tree is in a better state than it was, but there is still some work to do. We have an important ABI breakage ahead, but that is being discussed. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 0/5] Fixing automagic dependencies on gtk[wayland,X],
On Sun, 2024-06-23 at 13:35 -0400, Eli Schwartz wrote: > There is a bug in how gtk 3 and gtk 4 are built against by other > packages. GTK supports optionally enabling X and wayland support -- when > you do so, the ABI of GTK changes. > > It is historically common for X11 packages to check for a macro provided > by GTK that says "built with X11 support". This goes back to the days > when X11 was the only backend shipped with GTK, and the main use of the > macro was to check whether to use X11 or rather to use, say, the win32 > or Quartz (macOS) backends. The pattern has continued now that Linux has > two backends. > > The result of this is that many packages really need to support their > own IUSE="X wayland" (because they can conditionally build code for > that) and also need to make sure that USE flag is actually respected. > Failure to do this means that when rebuilding GTK with different USE > flags, all applications linking to GTK need to be rebuilt too, but > portage doesn't know that. > > It also means that binhosts -- such as the one officially hosted by > Gentoo -- have bad binaries that don't actually match the packages users > have installed. This is particularly bad since it breaks expectations > and is quite hard to debug. This has hit people a bunch of times when > trying to install the xfce desktop environment, in particular. > - What I propose in this patchset. Hack a custom gentoo feature into the > GTK headers. GTK normally behaves exactly as it's supposed to > upstream, but we add the ability to pass a define via `append-cflags` > that makes the GTK headers tell an outright lie and claim its API > doesn't exist. Which is what we want -- we want packages to be able to > compile *as if* GTK wasn't built with support for a given backend. > This disables the automagic as if option 1 (implementing configure > options) was carried out. Advantage: automatically support proper > control of features. Disadvantage: requires patching GTK and > then still adding workarounds for each package that needs it. Nice trick! I like it. Good work. :) signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: games-util/xgame and games-util/xgame-gtk2
# James Le Cuirot (2024-06-20) # Ancient, dead upstream, X11-based, probably doesn't work any more, and there # are better ways of running games in different sessions now. # Removal on 2024-07-20. Bug #934640. games-util/xgame games-util/xgame-gtk2 signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: games-strategy/majesty-demo
# James Le Cuirot (2024-06-20) # Apparently a good game, but you cannot buy the full Linux version any more. # Get the HD version from Steam or the Windows original from GOG instead. # Removal on 2024-07-20. Bug #934637. games-strategy/majesty-demo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function
On Sat, 2024-06-15 at 17:56 -0400, Ionen Wolkens wrote: > On Sat, Jun 15, 2024 at 08:14:34PM +0200, Florian Schmaus wrote: > > On 13/06/2024 17.03, James Le Cuirot wrote: > > > Several Cargo-based ebuilds cannot use cargo_src_install for various > > > reasons and manually install binaries from within the target directory > > > instead. It is common to see `target/$(usex debug debug release)`, but > > > this lacks the target ABI when cross-compiling, so provide a helper > > > function. > > > > Glad that someone is working on better cross-compilation support for > > rust. :) > > > > That said, many rust ebuilds generate shell completions by invoking the > > just compiled binary in src_install(). This does not work out of the box > > when cross-compiling. > > > > Is there anything we can or should do about it (besides binfmt_misc)? > > For example, asking the according projects to implement a mechanism to > > extract the completions files from the binary without running it, or > > have the build system generate the completion files as result of the build? > > All I can think of without changing entirely how they're generated is: > 1. (worst) either make a 2nd build using CBUILD (yeah no), or BDEPEND >on same-version self with a USE only when cross compiling > 2. (lazy) skip completions w/ ewarn if tc-is-cross-compiler, just so >it at least won't break cross over completion files that the user >may not even care much about > 3. generate them yourself with each releases and ship in a tarball, >works out for users but extra burden for maintainer over little > 4. ask upstream to provide proper release tarballs if not already and >include pre-generated completions/docs/etc... so it's otherwise >only a problem with arbitrary git checkouts > (3+4 may possibly be more complicated if cargo features / USE change > cli options and thus completion files) > > For one of my ebuilds I went with better-than-nothing #2. I've been doing this work for Flatcar, which doesn't use any of the packages affected by this, but it does still concern me a little. Unfortunately, none of the options are great. I've seen #2 in one or two cases, and thanks for doing that. For #1, the BDEPEND approach isn't possible with current Portage/PMS. The experimental EAPI 5-hdepend, which led to BDEPEND in EAPI 7, had a USE flag called targetroot (terrible name!) for this purpose. It wasn't based on cross-compiling, because Portage/PMS don't actually have any concept of that. It applied when ROOT!=/. We decided not to keep it though. Chances are that / won't already have an identical or at least compatible version already installed. Doing another temporary build was therefore deemed preferable. On the plus side, that's quite easy with Cargo. On the minus side, almost all Rust builds take ages. It hardly seems worth it for shell completions. I really don't see #4 happening, given that most end-user applications are normally installed using cargo install. Regarding binfmt_misc, you could explicitly invoke via qemu-user instead, making it less dependent on a particular setup. I have hacked together some helpers to do stuff like this because we really need it for Perl. In Perl's case, it would be mandatory when cross-compiling because there's really no other way. I wouldn't want it to be mandatory in this case though. signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH v2] cargo.eclass: Add cargo_target_dir helper function
Several Cargo-based ebuilds cannot use cargo_src_install for various
reasons and manually install binaries from within the target directory
instead. It is common to see `target/$(usex debug debug release)`, but
this lacks the target ABI when cross-compiling, so provide a helper
function.
There are some multilib Cargo-based ebuilds that always set the target
ABI, even when not cross-compiling. It would be simpler to do this in
general, so once ebuilds have been updated to use this new helper, I
might change the eclass again accordingly.
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 10 ++
1 file changed, 10 insertions(+)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 40d98211ce7f9..7463e1a0a600a 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -319,6 +319,16 @@ _cargo_gen_git_config() {
fi
}
+# @FUNCTION: cargo_target_dir
+# @DESCRIPTION:
+# Return the directory within target that contains the build, e.g.
+# target/aarch64-unknown-linux-gnu/release.
+cargo_target_dir() {
+ local abi
+ tc-is-cross-compiler && abi=/$(rust_abi)
+ echo "${CARGO_TARGET_DIR:-target}${abi}/$(usex debug debug release)"
+}
+
# @FUNCTION: cargo_src_unpack
# @DESCRIPTION:
# Unpacks the package and the cargo registry.
--
2.45.1
Re: [gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function
On Thu, 2024-06-13 at 21:32 +, Lucio Sauer wrote:
> On Thu, Jun 13, 2024 at 04:03:44PM +0100, James Le Cuirot wrote:
> > Several Cargo-based ebuilds cannot use cargo_src_install for various
> > reasons and manually install binaries from within the target directory
> > instead. It is common to see `target/$(usex debug debug release)`, but
> > this lacks the target ABI when cross-compiling, so provide a helper
> > function.
> >
> > There are some multilib Cargo-based ebuilds that always set the target
> > ABI, even when not cross-compiling. It would be simpler to do this in
> > general, so once ebuilds have been updated to use this new helper, I
> > might change the eclass again accordingly.
> >
> > Signed-off-by: James Le Cuirot
> > ---
> > eclass/cargo.eclass | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
> > index 40d98211ce7f9..2036fb635d569 100644
> > --- a/eclass/cargo.eclass
> > +++ b/eclass/cargo.eclass
> > @@ -319,6 +319,16 @@ _cargo_gen_git_config() {
> > fi
> > }
> >
> > +# @FUNCTION: cargo_target_dir
> > +# @DESCRIPTION:
> > +# Return the directory within target that contains the build, e.g.
> > +# target/aarch64-unknown-linux-gnu/release.
> > +cargo_target_dir() {
> > + local abi
> > + tc-is-cross-compiler && abi=$(rust_abi)
> > + echo "${CARGO_TARGET_DIR:-target}${abi+/}${abi}/$(usex debug debug
> > release)"
> > +}
> > +
> How about giving this function an optional parameter that gets passed to
> rust_abi so that you can get the build directory for targets other than
> CHOST?
>
> What initially motivated this suggestion is a quirk in app-misc/anki's
> build system together with your recent change to cargo.eclass 375da3684,
> which enables cross-compilation by setting environment variables.
> Here, I first build the 'build system runner' for CBUILD, which then
> compiles the actual package for CHOST. I think I can avoid explicitly
> setting --target $(rust ${CBUILD}) for the runner for now, but it would
> be handy to easily get the build directory for CBUILD in the future!
I did consider that, but for the sake of simplicity, I think I'd prefer just
overriding CHOST when you need to do this. There are already similar examples
of this.
I had a look at app-misc/anki. I think you do need to give --target to the
runner right now if that's building something, otherwise how would it know
what the target is? Perhaps the runner respects CARGO_BUILD_TARGET? If so, I
was thinking of making a cargo_env wrapper helper that would set that and
other variables in the context of the given command. This would be used in
cargo_src_compile, as well as cargo_src_install and cargo_src_test in case any
rebuilding occurs. It could also be used for other custom scenarios like this
one. What do you think?
diff --git a/app-misc/anki/anki-24.04.1.ebuild
b/app-misc/anki/anki-24.04.1.ebuild
index 54dfbf94f31b2..2764659ccbf51 100644
--- a/app-misc/anki/anki-24.04.1.ebuild
+++ b/app-misc/anki/anki-24.04.1.ebuild
@@ -871,9 +871,9 @@ src_compile() {
#* generate the ninja file and run ninja afterwards
#* create the Python wheel files in "${S}"/out/wheels
- cargo build --release --package runner || die
+ tc-env_build cargo_src_compile --package runner
if use gui; then
- out/rust/release/runner build -- $(get_NINJAOPTS) wheels || die
+ cargo_env "$(CHOST=${CBUILD} cargo_target_dir)/runner" build --
$(get_NINJAOPTS) wheels || die
else
cargo_src_compile --package anki-sync-server
fi
@@ -901,7 +901,7 @@ src_test() {
"${S}"/build/ninja_gen/src/cargo.rs || die
for runner in pytest rust_test jest; do
- out/rust/release/runner build -- $(get_NINJAOPTS) check:$runner
|| \
+ cargo_env "$(CHOST=${CBUILD} cargo_target_dir)/runner" build --
$(get_NINJAOPTS) check:$runner || \
die "check:$runner failed!"
done
}
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH] cargo.eclass: Add cargo_target_dir helper function
Several Cargo-based ebuilds cannot use cargo_src_install for various
reasons and manually install binaries from within the target directory
instead. It is common to see `target/$(usex debug debug release)`, but
this lacks the target ABI when cross-compiling, so provide a helper
function.
There are some multilib Cargo-based ebuilds that always set the target
ABI, even when not cross-compiling. It would be simpler to do this in
general, so once ebuilds have been updated to use this new helper, I
might change the eclass again accordingly.
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 10 ++
1 file changed, 10 insertions(+)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 40d98211ce7f9..2036fb635d569 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -319,6 +319,16 @@ _cargo_gen_git_config() {
fi
}
+# @FUNCTION: cargo_target_dir
+# @DESCRIPTION:
+# Return the directory within target that contains the build, e.g.
+# target/aarch64-unknown-linux-gnu/release.
+cargo_target_dir() {
+ local abi
+ tc-is-cross-compiler && abi=$(rust_abi)
+ echo "${CARGO_TARGET_DIR:-target}${abi+/}${abi}/$(usex debug debug
release)"
+}
+
# @FUNCTION: cargo_src_unpack
# @DESCRIPTION:
# Unpacks the package and the cargo registry.
--
2.45.1
Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: Add tc-has-64bit-time_t
On Thu, 2024-06-13 at 17:23 +0200, Michał Górny wrote:
> Add a helper function to check whether time_t is 64-bit. This could
> be used e.g. to deselect tests that rely on timestamps exceeding Y2k38.
> It is meant to be more future-proof than hardcoding a list of 32-bit
> architectures, given the necessity of switching to 64-bit time_t
> in the future.
>
> Signed-off-by: Michał Górny
> ---
> eclass/toolchain-funcs.eclass | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> Pull-Request: https://github.com/gentoo/gentoo/pull/37142
>
> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> index cde84e6f34c8..3e20e956e9c2 100644
> --- a/eclass/toolchain-funcs.eclass
> +++ b/eclass/toolchain-funcs.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 2002-2023 Gentoo Authors
> +# Copyright 2002-2024 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
>
> # @ECLASS: toolchain-funcs.eclass
> @@ -1251,4 +1251,14 @@ tc-is-lto() {
> return 1
> }
>
> +# @FUNCTION: tc-has-64bit-time_t
> +# @RETURN: Shell true if time_t is at least 64 bits long, false otherwise
> +tc-has-64bit-time_t() {
> + "$(tc-getCC)" ${CFLAGS} ${CPPFLAGS} -c -x c - -o /dev/null <<-EOF
> &>/dev/null
> + #include
> + int test[sizeof(time_t) >= 8 ? 1 : -1];
> + EOF
> + return $?
> +}
> +
> fi
I take it this can't be done with tc-cpp-is-true because you need more than
just the preprocessor?
Please don't quote $(tc-getCC), CC can have additional arguments in some
cases. We don't quote $(tc-getTARGET_CPP) in tc-cpp-is-true.
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH v2 2/2] cargo.eclass: Enable cross-compiling by setting environment variables
CARGO_BUILD_TARGET and CARGO_TARGET__LINKER are enough for pure
Rust. The linker otherwise defaults to `cc`. This doesn't respect any
linker specified in LDFLAGS, but this is also true for native builds. We
would need to do something with RUSTFLAGS.
The HOST_* variables are for the cc-rs crate, which is often used to
build non-Rust code. It uses the usual variables (CC, CFLAGS, etc) for
the target.
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index 72c740cda9065..40d98211ce7f9 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -34,7 +34,7 @@ case ${EAPI} in
;;
esac
-inherit flag-o-matic multiprocessing toolchain-funcs
+inherit flag-o-matic multiprocessing rust-toolchain toolchain-funcs
[[ ! ${CARGO_OPTIONAL} ]] && BDEPEND="${RUST_DEPEND}"
@@ -525,6 +525,21 @@ cargo_src_compile() {
filter-lto
tc-export AR CC CXX PKG_CONFIG
+ if tc-is-cross-compiler; then
+ export CARGO_BUILD_TARGET=$(rust_abi)
+ local TRIPLE=${CARGO_BUILD_TARGET//-/_}
+ export CARGO_TARGET_"${TRIPLE^^}"_LINKER=$(tc-getCC)
+
+ # Set vars for cc-rs crate.
+ tc-export_build_env
+ export \
+ HOST_AR=$(tc-getBUILD_AR)
+ HOST_CC=$(tc-getBUILD_CC)
+ HOST_CXX=$(tc-getBUILD_CXX)
+ HOST_CFLAGS=${BUILD_CFLAGS}
+ HOST_CXXFLAGS=${BUILD_CXXFLAGS}
+ fi
+
set -- cargo build $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@"
einfo "${@}"
"${@}" || die "cargo build failed"
--
2.45.1
[gentoo-dev] [PATCH v2 1/2] cargo.eclass: Drop EAPI 7 support
It is going to inherit rust-toolchain, which is EAPI 8 only.
Closes: https://bugs.gentoo.org/715890
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index a685cd99fb38b..72c740cda9065 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -7,11 +7,11 @@
# @AUTHOR:
# Doug Goldstein
# Georgy Yakovlev
-# @SUPPORTED_EAPIS: 7 8
+# @SUPPORTED_EAPIS: 8
# @BLURB: common functions and variables for cargo builds
case ${EAPI} in
- 7|8) ;;
+ 8) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
@@ -23,10 +23,6 @@ _CARGO_ECLASS=1
RUST_DEPEND="virtual/rust"
case ${EAPI} in
- 7)
- # 1.37 added 'cargo vendor' subcommand and net.offline config
knob
- RUST_DEPEND=">=virtual/rust-1.37.0"
- ;;
8)
# 1.39 added --workspace
# 1.46 added --target dir
@@ -556,17 +552,6 @@ cargo_src_install() {
rm -f "${ED}/usr/.crates.toml" || die
rm -f "${ED}/usr/.crates2.json" || die
-
- # it turned out to be non-standard dir, so get rid of it future EAPI
- # and only run for EAPI=7
- # https://bugs.gentoo.org/715890
- case ${EAPI:-0} in
- 7)
- if [ -d "${S}/man" ]; then
- doman "${S}/man" || return 0
- fi
- ;;
- esac
}
# @FUNCTION: cargo_src_test
--
2.45.1
[gentoo-dev] Last rites: games-emulation/gcube
# James Le Cuirot (2024-06-09) # Long dead upstream. Probably broken. Use games-emulation/dolphin instead. # Removal on 2024-07-09. Bug #739140. games-emulation/gcube signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: games-fps/wolfgl
# James Le Cuirot (2024-06-09) # Super ancient and broken 32-bit only port. Package ECWolf instead. # Removal on 2024-07-09. Bug #926467. games-fps/wolfgl signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: games-strategy/darwinia-demo
# James Le Cuirot (2024-06-09) # Download no longer available, license prevents mirroring. # Removal on 2024-07-09. Bug #791115. games-strategy/darwinia-demo signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH 2/2] cargo.eclass: Enable cross-compiling by setting environment variables
CARGO_BUILD_TARGET and CARGO_TARGET__LINKER are enough for pure
Rust. The linker otherwise defaults to `cc`. This doesn't respect any
linker specified in LDFLAGS, but this is also true for native builds. We
would need to do something with RUSTFLAGS.
The HOST_* variables are for the cc-rs crate, which is often used to
build non-Rust code. It uses the usual variables (CC, CFLAGS, etc) for
the target.
Signed-off-by: James Le Cuirot
---
eclass/cargo.eclass | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index ef55e0613e61c..9390d488f8327 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -38,7 +38,7 @@ case ${EAPI} in
;;
esac
-inherit flag-o-matic multiprocessing toolchain-funcs
+inherit flag-o-matic multiprocessing rust-toolchain toolchain-funcs
[[ ! ${CARGO_OPTIONAL} ]] && BDEPEND="${RUST_DEPEND}"
@@ -529,6 +529,21 @@ cargo_src_compile() {
filter-lto
tc-export AR CC CXX PKG_CONFIG
+ if tc-is-cross-compiler; then
+ export CARGO_BUILD_TARGET=$(rust_abi)
+ local TRIPLE=${CARGO_BUILD_TARGET//-/_}
+ export CARGO_TARGET_"${TRIPLE^^}"_LINKER=$(tc-getCC)
+
+ # Set vars for cc-rs crate.
+ tc-export_build_env
+ export \
+ HOST_AR=$(tc-getBUILD_AR)
+ HOST_CC=$(tc-getBUILD_CC)
+ HOST_CXX=$(tc-getBUILD_CXX)
+ HOST_CFLAGS=${BUILD_CFLAGS}
+ HOST_CXXFLAGS=${BUILD_CXXFLAGS}
+ fi
+
set -- cargo build $(usex debug "" --release) ${ECARGO_ARGS[@]} "$@"
einfo "${@}"
"${@}" || die "cargo build failed"
--
2.45.1
[gentoo-dev] [PATCH 1/2] cargo.eclass: Drop EAPI 7 support
It is going to inherit rust-toolchain, which is EAPI 8 only.
Signed-off-by: James Le Cuirot
---
There are still some EAPI 7 ebuilds left right now, but I'm working on that!
eclass/cargo.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/cargo.eclass b/eclass/cargo.eclass
index a685cd99fb38b..ef55e0613e61c 100644
--- a/eclass/cargo.eclass
+++ b/eclass/cargo.eclass
@@ -7,11 +7,11 @@
# @AUTHOR:
# Doug Goldstein
# Georgy Yakovlev
-# @SUPPORTED_EAPIS: 7 8
+# @SUPPORTED_EAPIS: 8
# @BLURB: common functions and variables for cargo builds
case ${EAPI} in
- 7|8) ;;
+ 8) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
--
2.45.1
Re: [gentoo-dev] Up for grabs: Raspberry Pi stack
On Sat, 2024-04-20 at 04:24 +0100, Sam James wrote: > I don't have the hardware set up at the moment (and haven't for a while) > to test this properly. > > The following packages are up for grabs: > * media-libs/raspberrypi-userland-bin > * sys-kernel/raspberrypi-image > > I dropped myself as a co-maintainer on the following: > * sys-firmware/raspberrypi-wifi-ucode > * media-libs/raspberrypi-userland-bin > * sys-boot/raspberrypi-firmware > * sys-kernel/raspberrypi-sources > * sys-kernel/raspberrypi-image > > I think anyone interested in these packages should probably consider > joining the lot. > > There's a few outstanding bugs, notably https://bugs.gentoo.org/930269 > for Raspberry Pi 5 support, but a bunch of others including bumps being > due. I've been working in this area because of my PiStorm efforts, but it's been hard to find the time lately. I can at least say that I was on the way to last riting media-libs/raspberrypi-userland(-bin). Ideally, we need libcamera first, otherwise users of things like media-video/motion will be impacted. I don't know whether we have any such users though. As for hardware, I only have a Pi 4b and have no need for a Pi 5. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: tc-env_build: override (E)SYSROOT
On Fri, 2024-04-19 at 12:14 -0400, Mike Gilbert wrote:
> When using the CBUILD toolchain, it makes no sense to look for headers
> and libraries in the CHOST-based SYSROOT.
>
> Signed-off-by: Mike Gilbert
> ---
> eclass/toolchain-funcs.eclass | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> index cde84e6f34c8..58a718180079 100644
> --- a/eclass/toolchain-funcs.eclass
> +++ b/eclass/toolchain-funcs.eclass
> @@ -1,4 +1,4 @@
> -# Copyright 2002-2023 Gentoo Authors
> +# Copyright 2002-2024 Gentoo Authors
> # Distributed under the terms of the GNU General Public License v2
>
> # @ECLASS: toolchain-funcs.eclass
> @@ -384,6 +384,12 @@ tc-export_build_env() {
> # the target build system does not check.
> tc-env_build() {
> tc-export_build_env
> + local -x SYSROOT=
> + if [[ ${EAPI} == 6 ]]; then
> + local -x ESYSROOT=${EPREFIX}
> + else
> + local -x ESYSROOT=${BROOT}
> + fi
> CFLAGS=${BUILD_CFLAGS} \
> CXXFLAGS=${BUILD_CXXFLAGS} \
> CPPFLAGS=${BUILD_CPPFLAGS} \
What do you need this for? Just wondering because I wouldn't have thought
anything you wrap with tc-env_build would care about ESYSROOT.
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] Last rites: games-board/xmille
# James Le Cuirot (2024-04-05) # Dead upstream and broken beyond repair. Removal on 2024-05-05. Bug #928591. games-board/xmille signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
On Mon, 2024-04-01 at 20:51 +0200, Kévin GASPARD DE RENEFORT wrote: > > Thanks for clarifying that, it wasn't clear to me when I read the > > earlier e-mail. > > > > Personally I think the long term solution is to identify critical code > > bases that have a low bus factor before the bad actors do and make a > > concentrated community effort to help audit and maintain these code > > bases. > > Hi, > > I hope this is not a stupid suggestion, that is also my first mail here > so if something does not suits habits feel free to tell me please, but > after reading the whole topic here I did not find this suggestion. > > It’s merely a proposition out of my mind, also something I know very > little about. > > --- > > I read Linus T. speaking about usage of AI nowadays, in the IT field and > stating that is an awful idea to write code with it (at least, for now)… > But not to ask an AI to read the code and try to found by this way > security holes, bad habits, bugs and such. > > Again, my skill and knowledge about AI, specially nowadays, is very > small. But would take it lot of works to sets an AI to simple «read» > codes to look for undesired stuff ? That won’t even modify anything, > merely says : «Ah, found something weird, **here**.». Maybe, properly > configured, it would have detected this social-hacking. Maybe not. > > Since programming is a very hard works, specially when it’s about > security and bug, I also have very poor programing skill, but since the > whole purpose of a computer and it’s set of software is to do what an > human could NOT do properly (like being attentives while reading dozens > of hundreds line of code…) and automate stuff, it *seems* to perfectly > suits this need. > > I guess the process on Gentoo side while it’s about "packaging" is > writing the good ebuild that download source code, compressed (and that > is the whole problem here if I understand) and then unpack it, compile > it, etc… > > Could an AI reading the code could be a step somewhere ? > > On other distribution I would say it needs to act **before** the package > is made, while building it I guess, for Gentoo I do not know. > > But that is not the job of Gentoo’s ebuild writer to check other > projects code, that would be a non-sense ! Right ? > > I’m curious of what an AI could bring in this subject. > > If it’s a stupid suggestion, well, will keep reading this topic, very > interesting. And sorry for the noise. > > PS: Thanks for the works behind libre software, open-source and here, > Gentoo. I trust you since I do not have knowledge to judge properly the > works, but Gentoo is indeed one of the best Linux available, if not the > best in some field. Don’t let burn-out takes you and keep your real > priority among everything, even Gentoo or libre software. We are humans, > not machines. > > Regards, > GASPARD DE RENEFORT Kévin That's not stupid at all, I'd been thinking exactly the same thing. I raised this whole issue during a discussion at FOSDEM 2019, where I admitted that I didn't check the code changes for packages I was bumping, knowing that few to none of the other people in the room did so either. Despite speaking up then, I still didn't do it because it's a heavy a burden and I'm not paid to do it. Now I'm thinking I really should, but I could really use some help. I'll raise this idea at work. You could say that we specialise in these things. :) Regards, Chewi signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: games-sports/gracer
# James Le Cuirot (2024-03-30) # Old, ugly, broken, and requires OSS sound. Removal on 2024-04-30. # Bug #928066. games-sports/gracer signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH] python-utils-r1.eclass: Fix python_doheader install location with ROOT
python_get_includedir is prefixed with ESYSROOT, not EPREFIX, so we need
to strip off the former, not the latter.
This is currently only used for dev-python/pillow, which I have tested.
Signed-off-by: James Le Cuirot
---
eclass/python-utils-r1.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index 3af3cbdb075e1..caa39813feec7 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -884,7 +884,7 @@ python_doheader() {
[[ ${EPYTHON} ]] || die 'No Python implementation set (EPYTHON is
null).'
local includedir=$(python_get_includedir)
- local d=${includedir#${EPREFIX}}
+ local d=${includedir#${ESYSROOT}}
(
insopts -m 0644
--
2.43.2
Re: [gentoo-dev] Important note on tinderbox behavior
On Fri, 2024-02-23 at 15:35 +0100, Agostino Sarubbo wrote:
> Dear all,
>
> TL;DR: tinderbox will skip packages with know failures
>
> it's a matter of fact that on bugzilla there are hundreds of bugs that
> tinderbox continues to reproduce.
>
> That results in a waste of resources and time.
>
> What was done to improve this situation:
> in the past few months I launched few tinderbox environments with the scope
> of
> collect the known failures.
> These failures, that have an open bug, have been noted on a list.
> When tinderbox starts, it queries bugzilla to understand the status of the
> bug
> and in case of open bugs it passes the package names to emerge as
> --exclude $PACKAGE
> That save a lot of time because emerge FOO --exclude FOO hangs immediately.
>
> Imagine a scenario where a broken package has no DEPEND. The waste of
> resource
> is very minimal.
>
> Imagine another scenario where:
> - the package FOO is broken
> - the package BAR has 100 depend
> - the package FOO is a depend of BAR
> - the package FOO is at position 100 of the depend order
>
> that results in build 99 packages for nothing.
>
> In short the problem is not in the package itself, but when a lot of DEPEND
> are involved.
>
> This behavior, *that was already experimented in the latest few months* does
> not change anything on your side.
>
> The only con that comes in my mind is that when a version bump silently fixes
> an issue and maintainer is not aware about that.
> The bug still remains as open and as a consequence, the package continues to
> be excluded.
>
> For this reason, please be pay more attention to open bugs.
>
> As a side note, bugs are obviously categorized. For example a build failure
> for a package FOO on musl, will produce '--exclude FOO' only on musl.
> Same thing for doc brokeness.
>
> For this reason please expect less 'tinderbox has reproduced this issue with
> version "${VERSION}" - Updating summary.' and not seeing anymore this message
> is not a symptom of 'this is fixed now' ( https://bugs.gentoo.org/770889#c6 )
>
> Failures regarding Modern C porting are excluded from this behavior. Instead
> '-fpermissive' will be used to build as much as possible.
> Tests failures have also no influence on that, but keep in mind that packages
> with known test failure(s) are not built by default.
>
> Thanks
> Agostino
>
You've made the right call here. Sorry for not fixing the many bugs you've
reported. It's not that I don't care, it's very hard to find the time,
especially for the musl and Clang ones. I certainly won't assume the issues
have magically gone away. Thanks for your continued hard work in this area.
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Setting default HOME_MODE in /etc/login.defs
On Sun, 2024-02-11 at 09:00 +0100, Ulrich Mueller wrote: > > > > > > On Sat, 10 Feb 2024, Daniel Simionato wrote: > > > I'd like to start a discussion regarding setting HOME_MODE by default in > > the /etc/login.defs file (owned by sys-apps/shadow package). > > > Upstream keeps HOME_MODE commented: > > https://github.com/shadow-maint/shadow/blob/3e59e9613ec40c51c19c7bb5c28468e33a4529d5/etc/login.defs#L207 > > > HOME_MODE affects only useradd and newuser commands: if HOME_MODE is set, > > they will use the specified permission when creating a user home directory, > > otherwise the default UMASK will be used. > > Since the default umask is 022, keeping HOME_MODE unset will result in home > > readable home directories created by useradd, which goes against security > > best practices. > > > The proposal is to set HOME_MODE to 0700, or at least 0750: RedHat and RH > > based distros, OpenSuse, ArchLinux all set it to 0700, Ubuntu has it at > > 0750. Debian and Gentoo are two exceptions, keeping the upstream value of > > HOME_MODE (although login.defs is changed in other ways). > > > I previously made a PR on github where you can find more details ( > > https://github.com/gentoo/gentoo/pull/35231), but as pointed in the > > comments this probably warrants some discussion beforehand. > > > I can understand the argument against the change, which is keeping in sync > > with upstream and don't risk changing the historic default behaviour of > > tools some users might rely upon. > > > I do believe though there's merit in providing safer and secure defaults, > > so I would like HOME_MODE to have a safe default value for Gentoo and > > Gentoo based distros. > > I see no strong argument either way. However, changing the default is > somewhat intrusive, so I'd prefer staying with upstream. Also, are we > aware of any breakage caused by this? > > As you've pointed out yourself, distros are inconsistent about it, > i.e. not much guidance from there. Maybe upstream would be a better > place for this discussion? > > Ulrich You may need 0701 if you have a web server reading from ~/public_html, but that's uncommon. I've been using this for years without issue, but I think 0700 makes the most sense as the default. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC PATCH 00/10] Upgrading cups-filters to 2.0.0
On Tue, 2023-12-05 at 00:20 -0500, Eli Schwartz wrote: > I've been working with Sam for a bit on this update. It's a bit of a > fiddly one, as a lot of stuff has changed upstream. It's probably best > described via my proposed news post. Please review. It would also be > quite nice to get a bit of testing -- I'm especially concerned about > cups-browsed's testsuite, so if anyone has any ideas how to actually run > it, that would be fantastic. I do not use cups-browsed myself... I've mostly just glanced at the code, which looks fine, but I just want to express my huge thanks for doing this. I know printing stuff isn't sexy, but it is important, so I really appreciate the effort. signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH 4/4] eclass/golang-vcs.eclass: set up compile env
From: Thilo Fromm
This change calls go-env_set_compile_environment in golang-vcs's
src_unpack to set up a sane compile environment early in the go build
process. This un-breaks cross compiling of all golang ebuilds that
inherit golang-vcs.
Signed-off-by: Thilo Fromm
Closes: https://github.com/gentoo/gentoo/pull/33539
Signed-off-by: James Le Cuirot
---
eclass/golang-vcs.eclass | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/eclass/golang-vcs.eclass b/eclass/golang-vcs.eclass
index 7558db4776cb..6f7a837bc15f 100644
--- a/eclass/golang-vcs.eclass
+++ b/eclass/golang-vcs.eclass
@@ -20,7 +20,7 @@ esac
if [[ -z ${_GOLANG_VCS_ECLASS} ]]; then
_GOLANG_VCS_ECLASS=1
-inherit estack golang-base
+inherit estack golang-base go-env
PROPERTIES+=" live"
@@ -63,6 +63,7 @@ PROPERTIES+=" live"
# @INTERNAL
# @DESCRIPTION:
# Create EGO_STORE_DIR if necessary.
+# Set compile env via go-env.
_golang-vcs_env_setup() {
debug-print-function ${FUNCNAME} "$@"
@@ -84,6 +85,8 @@ _golang-vcs_env_setup() {
mkdir -p "${WORKDIR}/${P}/src" ||
die "${ECLASS}: unable to create ${WORKDIR}/${P}"
return 0
+
+ go-env_set_compile_environment
}
# @FUNCTION: _golang-vcs_fetch
--
2.42.1
[gentoo-dev] [PATCH 3/4] eclass/golang-vcs-snapshot.eclass: set up compile env
From: Thilo Fromm
This change calls go-env_set_compile_environment in
golang-vcs-snapshot's src_unpack to set up a sane compile environment
early in the go build process. This un-breaks cross compiling of all
golang ebuilds that inherit golang-vcs-snapshot.
Signed-off-by: Thilo Fromm
Signed-off-by: James Le Cuirot
---
eclass/golang-vcs-snapshot.eclass | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/eclass/golang-vcs-snapshot.eclass
b/eclass/golang-vcs-snapshot.eclass
index 9c199bbbd8c5..d34b8a6e913d 100644
--- a/eclass/golang-vcs-snapshot.eclass
+++ b/eclass/golang-vcs-snapshot.eclass
@@ -52,7 +52,7 @@ esac
if [[ -z ${_GOLANG_VCS_SNAPSHOT_ECLASS} ]]; then
_GOLANG_VCS_SNAPSHOT_ECLASS=1
-inherit golang-base
+inherit golang-base go-env
# @ECLASS_VARIABLE: EGO_VENDOR
# @DESCRIPTION:
@@ -92,6 +92,7 @@ _golang-vcs-snapshot_dovendor() {
# @FUNCTION: golang-vcs-snapshot_src_unpack
# @DESCRIPTION:
# Extract the first archive from ${A} to the appropriate location for GOPATH.
+# Set compile env via go-env.
golang-vcs-snapshot_src_unpack() {
local lib vendor_path x
ego_pn_check
@@ -117,6 +118,8 @@ golang-vcs-snapshot_src_unpack() {
fi
done
fi
+
+ go-env_set_compile_environment
}
fi
--
2.42.1
[gentoo-dev] [PATCH 2/4] eclass/go-module.eclass: export compile env in src_unpack
From: Thilo Fromm
This change calls go-env_set_compile_environment in go-module's
src_unpack to set up a sane compile environment early in the go build
process. This un-breaks cross compiling of all golang ebuilds that
inherit go-module.
Signed-off-by: Thilo Fromm
Signed-off-by: James Le Cuirot
---
eclass/go-module.eclass | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index 6c58d7f26f07..701d36e012e2 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -68,7 +68,7 @@ esac
if [[ -z ${_GO_MODULE_ECLASS} ]]; then
_GO_MODULE_ECLASS=1
-inherit multiprocessing toolchain-funcs
+inherit multiprocessing toolchain-funcs go-env
if [[ ! ${GO_OPTIONAL} ]]; then
BDEPEND=">=dev-lang/go-1.18"
@@ -363,6 +363,7 @@ go-module_setup_proxy() {
#local go proxy. This mode is deprecated.
# 2. Otherwise, if EGO_VENDOR is set, bail out, as this functionality was
removed.
# 3. Otherwise, call 'ego mod verify' and then do a normal unpack.
+# Set compile env via go-env.
go-module_src_unpack() {
if use amd64 || use arm || use arm64 ||
( use ppc64 && [[ $(tc-endian) == "little" ]] ) || use s390 ||
use x86; then
@@ -386,6 +387,8 @@ go-module_src_unpack() {
${nf} ego mod verify
fi
fi
+
+ go-env_set_compile_environment
}
# @FUNCTION: _go-module_src_unpack_gosum
--
2.42.1
[gentoo-dev] [PATCH 1/4] eclass/go-env.eclass: add helper to set compile env
From: Thilo Fromm
This change adds a helper function to explicitly set CC, CXX, and
GOARCH, and carrying over CFLAGS, LDFLAGS and friends to CGO
equivalents, to provide a minimal sane compile environment for Go.
It enables Go builds to play nice with crossdev's wrappers for
emerge/ebuild etc. Previously, Go ebuilds emitted binaries for the host
architecture.
For example, when running on an x86_64 host:
emerge-aarch64-cross-linux-gnu foo
will now correctly emerge Go package "foo" for aarch64 instead of
x86_64.
The eclass provides a single helper function
go-env_set_compile_environment()
intended to be called by other Go eclasses in an early build stage.
Ebuilds may also explicitly call this function.
Signed-off-by: Thilo Fromm
Signed-off-by: James Le Cuirot
---
eclass/go-env.eclass | 48
1 file changed, 48 insertions(+)
create mode 100644 eclass/go-env.eclass
diff --git a/eclass/go-env.eclass b/eclass/go-env.eclass
new file mode 100644
index ..ba4f6c3fbb59
--- /dev/null
+++ b/eclass/go-env.eclass
@@ -0,0 +1,48 @@
+# Copyright 2023 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: go-env.eclass
+# @MAINTAINER:
+# Flatcar Linux Maintainers
+# @AUTHOR:
+# Flatcar Linux Maintainers
+# @BLURB: Helper eclass for setting the Go compile environment. Required for
cross-compiling.
+# @DESCRIPTION:
+# This eclass includes a helper function for setting the compile environment
for Go ebuilds.
+# Intended to be called by other Go eclasses in an early build stage, e.g.
src_unpack.
+
+if [[ -z ${_GO_ENV_ECLASS} ]]; then
+_GO_ENV_ECLASS=1
+
+inherit toolchain-funcs
+
+# @FUNCTION: go-env_set_compile_environment
+# @DESCRIPTION:
+# Set up basic compile environment: CC, CXX, and GOARCH.
+# Also carry over CFLAGS, LDFLAGS and friends.
+# Required for cross-compiling with crossdev.
+# If not set, host defaults will be used and the resulting binaries are host
arch.
+# (e.g. "emerge-aarch64-cross-linux-gnu foo" run on x86_64 will emerge "foo"
for x86_64
+# instead of aarch64)
+go-env_set_compile_environment() {
+ local arch="$(tc-arch)"
+ case "${arch}" in
+ x86)GOARCH="386" ;;
+ x64-*) GOARCH="amd64" ;;
+ ppc64) if [[ "$(tc-endian)" == "big" ]] ; then
+ GOARCH="ppc64"
+ else
+ GOARCH="ppc64le"
+ fi ;;
+ *) GOARCH="${arch}" ;;
+ esac
+
+ tc-export CC CXX
+ export GOARCH
+ export CGO_CFLAGS="${CGO_CFLAGS:-$CFLAGS}"
+ export CGO_CPPFLAGS="${CGO_CPPFLAGS:-$CPPFLAGS}"
+ export CGO_CXXFLAGS="${CGO_CXXFLAGS:-$CXXFLAGS}"
+ export CGO_LDFLAGS="${CGO_LDFLAGS:-$LDFLAGS}"
+}
+
+fi
--
2.42.1
[gentoo-dev] [PATCH V2 0/4] eclass/go-env.eclass: add helper to enable cross compiling
See the GitHub link for earlier discussion. This still doesn't work for cross-prefix builds, unless you set CGO_ENABLED=1, but fixing that involves different code and can be done later. https://github.com/gentoo/gentoo/pull/33539
[gentoo-dev] [PATCH] toolchain-funcs.eclass: Add functions to get pointer size in bytes
tc-get-ptr-size for CHOST and tc-get-build-ptr-size for CBUILD.
Closes: https://bugs.gentoo.org/328401
Signed-off-by: James Le Cuirot
---
eclass/toolchain-funcs.eclass | 14 ++
1 file changed, 14 insertions(+)
diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index 8fef764ad597..5da93063866b 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -1216,4 +1216,18 @@ tc-get-c-rtlib() {
return 0
}
+# @FUNCTION: tc-get-ptr-size
+# @RETURN: Size of a pointer in bytes for CHOST (e.g. 4 or 8).
+tc-get-ptr-size() {
+ $(tc-getCPP) -P - <<< __SIZEOF_POINTER__ ||
+ die "Could not determine CHOST pointer size"
+}
+
+# @FUNCTION: tc-get-build-ptr-size
+# @RETURN: Size of a pointer in bytes for CBUILD (e.g. 4 or 8).
+tc-get-build-ptr-size() {
+ $(tc-getBUILD_CPP) -P - <<< __SIZEOF_POINTER__ ||
+ die "Could not determine CBUILD pointer size"
+}
+
fi
--
2.41.0
[gentoo-dev] [PATCH] eclass/go-env.eclass: add helper to set compile env
From: Thilo Fromm
This change adds a helper function to explicitly set CC, CXX, and
GOARCH, and carrying over CFLAGS, LDFLAGS and friends to CGO
equivalents, to provide a minimal sane compile environment for Go.
It enables Go builds to play nice with crossdev's wrappers for
emerge/ebuild etc. Previously, Go ebuilds emitted binaries for the host
architecture.
For example, when running on an x86_64 host:
emerge-aarch64-cross-linux-gnu foo
will now correctly emerge Go package "foo" for aarch64 instead of
x86_64.
The eclass provides a single helper function
go-env_set_compile_environment()
intended to be called by other Go eclasses in an early build stage.
Ebuilds may also explicitly call this function.
Calls to this function from _src_prepare in go-module.eclass,
golang-vcs-snapshot.eclass, and golang-vcs.eclass have also been added
to un-break cross-compilation of existing Go packages.
Signed-off-by: Thilo Fromm
Closes: https://github.com/gentoo/gentoo/pull/33539
Signed-off-by: James Le Cuirot
---
eclass/go-env.eclass | 48 +++
eclass/go-module.eclass | 5 +++-
eclass/golang-vcs-snapshot.eclass | 5 +++-
eclass/golang-vcs.eclass | 5 +++-
4 files changed, 60 insertions(+), 3 deletions(-)
create mode 100644 eclass/go-env.eclass
See the GitHub link for earlier discussion. This still doesn't work for
cross-prefix
builds, unless you set CGO_ENABLED=1, but fixing that involves different code
and can
be done later.
diff --git a/eclass/go-env.eclass b/eclass/go-env.eclass
new file mode 100644
index ..0b4d44658a07
--- /dev/null
+++ b/eclass/go-env.eclass
@@ -0,0 +1,48 @@
+# Copyright 2023 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: go-env.eclass
+# @MAINTAINER:
+# Flatcar Maintainers
+# @AUTHOR:
+# Flatcar Maintainers
+# @BLURB: Helper eclass for setting the Go compile environment. Required for
cross-compiling.
+# @DESCRIPTION:
+# This eclass includes a helper function for setting the compile environment
for Go ebuilds.
+# Intended to be called by other Go eclasses in an early build stage, e.g.
src_unpack.
+
+if [[ -z ${_GO_ENV_ECLASS} ]]; then
+_GO_ENV_ECLASS=1
+
+inherit toolchain-funcs
+
+# @FUNCTION: go-env_set_compile_environment
+# @DESCRIPTION:
+# Set up basic compile environment: CC, CXX, and GOARCH.
+# Also carry over CFLAGS, LDFLAGS and friends.
+# Required for cross-compiling with crossdev.
+# If not set, host defaults will be used and the resulting binaries are host
arch.
+# (e.g. "emerge-aarch64-cross-linux-gnu foo" run on x86_64 will emerge "foo"
for x86_64
+# instead of aarch64)
+go-env_set_compile_environment() {
+ local arch=$(tc-arch "${CHOST}}")
+ case "${arch}" in
+ x86)GOARCH="386" ;;
+ x64-*) GOARCH="amd64" ;;
+ ppc64) if [[ "$(tc-endian "${${CHOST}}")" = "big" ]] ; then
+ GOARCH="ppc64"
+ else
+ GOARCH="ppc64le"
+ fi ;;
+ *) GOARCH="${arch}" ;;
+ esac
+
+ tc-export CC CXX
+ export GOARCH
+ export CGO_CFLAGS="${CGO_CFLAGS:-$CFLAGS}"
+ export CGO_CPPFLAGS="${CGO_CPPFLAGS:-$CPPFLAGS}"
+ export CGO_CXXFLAGS="${CGO_CXXFLAGS:-$CXXFLAGS}"
+ export CGO_LDFLAGS="${CGO_LDFLAGS:-$LDFLAGS}"
+}
+
+fi
diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index 6c58d7f26f07..701d36e012e2 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -68,7 +68,7 @@ esac
if [[ -z ${_GO_MODULE_ECLASS} ]]; then
_GO_MODULE_ECLASS=1
-inherit multiprocessing toolchain-funcs
+inherit multiprocessing toolchain-funcs go-env
if [[ ! ${GO_OPTIONAL} ]]; then
BDEPEND=">=dev-lang/go-1.18"
@@ -363,6 +363,7 @@ go-module_setup_proxy() {
#local go proxy. This mode is deprecated.
# 2. Otherwise, if EGO_VENDOR is set, bail out, as this functionality was
removed.
# 3. Otherwise, call 'ego mod verify' and then do a normal unpack.
+# Set compile env via go-env.
go-module_src_unpack() {
if use amd64 || use arm || use arm64 ||
( use ppc64 && [[ $(tc-endian) == "little" ]] ) || use s390 ||
use x86; then
@@ -386,6 +387,8 @@ go-module_src_unpack() {
${nf} ego mod verify
fi
fi
+
+ go-env_set_compile_environment
}
# @FUNCTION: _go-module_src_unpack_gosum
diff --git a/eclass/golang-vcs-snapshot.eclass
b/eclass/golang-vcs-snapshot.eclass
index 9c199bbbd8c5..d34b8a6e913d 100644
--- a/eclass/golang-vcs-snapshot.eclass
+++ b/eclass/golang-vcs-snapshot.eclass
@@ -52,7 +52,7 @@ esac
if [[
Re: [gentoo-dev] [PATCH] distutils-r1.eclass: Make use of gpep517's new build-wheel --prefix arg
On Thu, 2023-09-28 at 02:15 +0100, Sam James wrote: > James Le Cuirot writes: > > > This fixes cross-prefix installations. > > Do we need to crank the minimum version we depend on for gpep517 then? Woops, yes. Got over-excited when I saw it was stabilised. Thanks. :) signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH v2] distutils-r1.eclass: Make use of gpep517's new build-wheel --prefix arg
This fixes cross-prefix installations.
Signed-off-by: James Le Cuirot
---
eclass/distutils-r1.eclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 56afcdc5bcb8..1cc91110dccf 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -210,7 +210,7 @@ _distutils_set_globals() {
fi
bdep='
- >=dev-python/gpep517-13[${PYTHON_USEDEP}]
+ >=dev-python/gpep517-15[${PYTHON_USEDEP}]
'
case ${DISTUTILS_USE_PEP517} in
flit)
@@ -1444,6 +1444,7 @@ distutils_pep517_install() {
einfo " Building the wheel for ${PWD#${WORKDIR}/} via ${build_backend}"
local cmd=(
gpep517 build-wheel
+ --prefix="${EPREFIX}/usr"
--backend "${build_backend}"
--output-fd 3
--wheel-dir "${WHEEL_BUILD_DIR}"
--
2.41.0
[gentoo-dev] [PATCH] distutils-r1.eclass: Make use of gpep517's new build-wheel --prefix arg
This fixes cross-prefix installations.
Signed-off-by: James Le Cuirot
---
eclass/distutils-r1.eclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 56afcdc5bcb8..838162c6b0f8 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1444,6 +1444,7 @@ distutils_pep517_install() {
einfo " Building the wheel for ${PWD#${WORKDIR}/} via ${build_backend}"
local cmd=(
gpep517 build-wheel
+ --prefix="${EPREFIX}/usr"
--backend "${build_backend}"
--output-fd 3
--wheel-dir "${WHEEL_BUILD_DIR}"
--
2.41.0
[gentoo-dev] [PATCH] python-utils-r1.eclass: Redo cross-prefix support using sysconfig
We recently supported cross-prefix by rewriting PYTHON_SITEDIR and
PYTHON_INCLUDEDIR from BROOT to EPREFIX. We now know that you can get
sysconfig to use EPREFIX in the first place, which is cleaner.
Signed-off-by: James Le Cuirot
---
eclass/python-utils-r1.eclass | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index f9c6d161d3f3..bd30c1203180 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -346,24 +346,22 @@ _python_export() {
PYTHON_SITEDIR)
[[ -n ${PYTHON} ]] || die "PYTHON needs to be
set for ${var} to be exported, or requested before it"
PYTHON_SITEDIR=$(
- "${PYTHON}" - <<-EOF || die
- import sysconfig
-
print(sysconfig.get_path("purelib"))
+ "${PYTHON}" - "${EPREFIX}/usr" <<-EOF
|| die
+ import sys, sysconfig
+
print(sysconfig.get_path("purelib", vars={"base": sys.argv[1]}))
EOF
)
-
PYTHON_SITEDIR=${EPREFIX}${PYTHON_SITEDIR#"${BROOT-${EPREFIX}}"}
export PYTHON_SITEDIR
debug-print "${FUNCNAME}: PYTHON_SITEDIR =
${PYTHON_SITEDIR}"
;;
PYTHON_INCLUDEDIR)
[[ -n ${PYTHON} ]] || die "PYTHON needs to be
set for ${var} to be exported, or requested before it"
PYTHON_INCLUDEDIR=$(
- "${PYTHON}" - <<-EOF || die
- import sysconfig
-
print(sysconfig.get_path("platinclude"))
+ "${PYTHON}" - "${ESYSROOT}/usr" <<-EOF
|| die
+ import sys, sysconfig
+
print(sysconfig.get_path("platinclude", vars={"installed_platbase":
sys.argv[1]}))
EOF
)
-
PYTHON_INCLUDEDIR=${ESYSROOT}${PYTHON_INCLUDEDIR#"${BROOT-${EPREFIX}}"}
export PYTHON_INCLUDEDIR
debug-print "${FUNCNAME}: PYTHON_INCLUDEDIR =
${PYTHON_INCLUDEDIR}"
--
2.41.0
[gentoo-dev] [PATCH] distutils-r1.eclass: Use gpep517's new prefix rewriting options
It is okay for these to be given as an empty string.
Signed-off-by: James Le Cuirot
---
This cannot be applied until gpep517-14 is stable, but I'm just getting
it reviewed in readiness.
eclass/distutils-r1.eclass | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 91de144e1110..34ef3b6e55f3 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -210,7 +210,7 @@ _distutils_set_globals() {
fi
bdep='
- >=dev-python/gpep517-13[${PYTHON_USEDEP}]
+ >=dev-python/gpep517-14[${PYTHON_USEDEP}]
'
case ${DISTUTILS_USE_PEP517} in
flit)
@@ -1452,7 +1452,11 @@ distutils_pep517_install() {
cmd+=( --config-json "${config_settings}" )
fi
if [[ -n ${SYSROOT} ]]; then
- cmd+=( --sysroot "${SYSROOT}" )
+ cmd+=(
+ --sysroot "${SYSROOT}"
+ --rewrite-prefix-from "${BROOT}"
+ --rewrite-prefix-to "${EPREFIX}"
+ )
fi
printf '%s\n' "${cmd[*]}"
local wheel=$(
--
2.41.0
[gentoo-dev] [PATCH v3] python-utils-r1.eclass: Fix PYTHON_SITEDIR/INCLUDEDIR for cross-prefix
We dynamically determine Python's SITEDIR and INCLUDEDIR using the build
host's Python. This breaks down when the build host's prefix differs
from the target host's prefix, so chop off the former and prepend the
latter.
This assumes that each Python implementation is always installed using
the same scheme. Meson already makes this assumption, and gpep517 makes
a similar assumption to determine Python's stdlib location.
We could improve on this and determine these locations using SYSROOT's
sysconfigdata file, like gpep517 does, but this seems needlessly
complex. We would need to take this approach for PYTHON_LIBPATH and
PYTHON_CONFIG, but these are only used by handful of packages.
${BROOT-${EPREFIX}} is needed rather than plain ${BROOT} for the same
reason we need it for PYTHON, namely that Portage <3.0.50 was buggy.
Signed-off-by: James Le Cuirot
---
Note that gpep517 also needs the same treatment, but I'll handle that
later. This at least allows Portage itself to be installed.
eclass/python-utils-r1.eclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index 2fffd6d56bf5..f9c6d161d3f3 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -351,6 +351,7 @@ _python_export() {
print(sysconfig.get_path("purelib"))
EOF
)
+
PYTHON_SITEDIR=${EPREFIX}${PYTHON_SITEDIR#"${BROOT-${EPREFIX}}"}
export PYTHON_SITEDIR
debug-print "${FUNCNAME}: PYTHON_SITEDIR =
${PYTHON_SITEDIR}"
;;
@@ -362,6 +363,7 @@ _python_export() {
print(sysconfig.get_path("platinclude"))
EOF
)
+
PYTHON_INCLUDEDIR=${ESYSROOT}${PYTHON_INCLUDEDIR#"${BROOT-${EPREFIX}}"}
export PYTHON_INCLUDEDIR
debug-print "${FUNCNAME}: PYTHON_INCLUDEDIR =
${PYTHON_INCLUDEDIR}"
--
2.41.0
Re: [gentoo-dev] [PATCH v2] python-utils-r1.eclass: Fix PYTHON_SITEDIR/INCLUDEDIR for cross-prefix
On Wed, 2023-08-16 at 12:47 +0200, Michał Górny wrote:
> On Wed, 2023-08-16 at 07:39 +0100, James Le Cuirot wrote:
> > We dynamically determine Python's SITEDIR and INCLUDEDIR using the build
> > host's Python. This breaks down when the build host's prefix differs
> > from the target host's prefix, so chop off the former and prepend the
> > latter.
> >
> > This assumes that each Python implementation is always installed using
> > the same scheme. Meson already makes this assumption, and gpep517 makes
> > a similar assumption to determine Python's stdlib location.
> >
> > We could improve on this and determine these locations using SYSROOT's
> > sysconfigdata file, like gpep517 does, but this seems needlessly
> > complex. We would need to take this approach for PYTHON_LIBPATH and
> > PYTHON_CONFIG, but these are only used by handful of packages.
> >
> > ${BROOT-${EPREFIX}} is needed rather than plain ${BROOT} for the same
> > reason we need it for PYTHON, namely that Portage <3.0.50 was buggy.
> >
> > Signed-off-by: James Le Cuirot
> > ---
> >
> > Note that gpep517 also needs the same treatment, but I'll handle that
> > later. This at least allows Portage itself to be installed.
> >
> > eclass/python-utils-r1.eclass | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> > index 2fffd6d56bf5..abfb74832f30 100644
> > --- a/eclass/python-utils-r1.eclass
> > +++ b/eclass/python-utils-r1.eclass
> > @@ -351,6 +351,7 @@ _python_export() {
> >
> > print(sysconfig.get_path("purelib"))
> > EOF
> > )
> > +
> > PYTHON_SITEDIR="${EPREFIX}${PYTHON_SITEDIR#${BROOT-${EPREFIX}}}"
> > export PYTHON_SITEDIR
> > debug-print "${FUNCNAME}: PYTHON_SITEDIR =
> > ${PYTHON_SITEDIR}"
> > ;;
> > @@ -362,6 +363,7 @@ _python_export() {
> >
> > print(sysconfig.get_path("platinclude"))
> > EOF
> > )
> > +
> > PYTHON_INCLUDEDIR="${ESYSROOT}${PYTHON_INCLUDEDIR#${BROOT-${EPREFIX}}}"
> > export PYTHON_INCLUDEDIR
> > debug-print "${FUNCNAME}: PYTHON_INCLUDEDIR =
> > ${PYTHON_INCLUDEDIR}"
> >
> >
>
> You don't seem to have changed that, actually.
Ah! Sorry, I shouldn't make changes in a rush before starting the day job.
ionen said globbing, when this is technically pattern matching, so I got
confused and thought quoting the whole thing would fix it. Actually globbing
doesn't even occur when assigning variables.
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH v2] python-utils-r1.eclass: Fix PYTHON_SITEDIR/INCLUDEDIR for cross-prefix
We dynamically determine Python's SITEDIR and INCLUDEDIR using the build
host's Python. This breaks down when the build host's prefix differs
from the target host's prefix, so chop off the former and prepend the
latter.
This assumes that each Python implementation is always installed using
the same scheme. Meson already makes this assumption, and gpep517 makes
a similar assumption to determine Python's stdlib location.
We could improve on this and determine these locations using SYSROOT's
sysconfigdata file, like gpep517 does, but this seems needlessly
complex. We would need to take this approach for PYTHON_LIBPATH and
PYTHON_CONFIG, but these are only used by handful of packages.
${BROOT-${EPREFIX}} is needed rather than plain ${BROOT} for the same
reason we need it for PYTHON, namely that Portage <3.0.50 was buggy.
Signed-off-by: James Le Cuirot
---
Note that gpep517 also needs the same treatment, but I'll handle that
later. This at least allows Portage itself to be installed.
eclass/python-utils-r1.eclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index 2fffd6d56bf5..abfb74832f30 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -351,6 +351,7 @@ _python_export() {
print(sysconfig.get_path("purelib"))
EOF
)
+
PYTHON_SITEDIR="${EPREFIX}${PYTHON_SITEDIR#${BROOT-${EPREFIX}}}"
export PYTHON_SITEDIR
debug-print "${FUNCNAME}: PYTHON_SITEDIR =
${PYTHON_SITEDIR}"
;;
@@ -362,6 +363,7 @@ _python_export() {
print(sysconfig.get_path("platinclude"))
EOF
)
+
PYTHON_INCLUDEDIR="${ESYSROOT}${PYTHON_INCLUDEDIR#${BROOT-${EPREFIX}}}"
export PYTHON_INCLUDEDIR
debug-print "${FUNCNAME}: PYTHON_INCLUDEDIR =
${PYTHON_INCLUDEDIR}"
--
2.41.0
Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: Fix PYTHON_SITEDIR/INCLUDEDIR for cross-prefix
On Tue, 2023-08-15 at 18:25 -0400, Ionen Wolkens wrote:
> On Tue, Aug 15, 2023 at 11:02:54PM +0100, James Le Cuirot wrote:
> > We dynamically determine Python's SITEDIR and INCLUDEDIR using the build
> > host's Python. This breaks down when the build host's prefix differs
> > from the target host's prefix, so chop off the former and prepend the
> > latter.
> >
> > This assumes that each Python implementation is always installed using
> > the same scheme. Meson already makes this assumption, and gpep517 makes
> > a similar assumption to determine Python's stdlib location.
> >
> > We could improve on this and determine these locations using SYSROOT's
> > sysconfigdata file, like gpep517 does, but this seems needlessly
> > complex. We would need to take this approach for PYTHON_LIBPATH and
> > PYTHON_CONFIG, but these are only used by handful of packages.
> >
> > ${BROOT-${EPREFIX}} is needed rather than plain ${BROOT} for the same
> > reason we need it for PYTHON, namely that Portage <3.0.50 was buggy.
> >
> > Signed-off-by: James Le Cuirot
> > ---
> >
> > Note that gpep517 also needs the same treatment, but I'll handle that
> > later. This at least allows Portage itself to be installed.
> >
> > eclass/python-utils-r1.eclass | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
> > index 2fffd6d56bf5..68b28c0ed806 100644
> > --- a/eclass/python-utils-r1.eclass
> > +++ b/eclass/python-utils-r1.eclass
> > @@ -351,6 +351,7 @@ _python_export() {
> >
> > print(sysconfig.get_path("purelib"))
> > EOF
> > )
> > +
> > PYTHON_SITEDIR=${EPREFIX}${PYTHON_SITEDIR#${BROOT-${EPREFIX}}}
>
> For a minor nitpick, should use quotes for the substitution, aka:
>
> PYTHON_SITEDIR=${EPREFIX}${PYTHON_SITEDIR#"${BROOT-${EPREFIX}}"}
>
> Or else if BROOT/EPREFIX somehow had glob characters in them, they will
> actually be globbing.
>
> > export PYTHON_SITEDIR
> > debug-print "${FUNCNAME}: PYTHON_SITEDIR =
> > ${PYTHON_SITEDIR}"
> > ;;
> > @@ -362,6 +363,7 @@ _python_export() {
> >
> > print(sysconfig.get_path("platinclude"))
> > EOF
> > )
> > +
> > PYTHON_INCLUDEDIR=${ESYSROOT}${PYTHON_INCLUDEDIR#${BROOT-${EPREFIX}}}
>
> Same here.
>
> > export PYTHON_INCLUDEDIR
> > debug-print "${FUNCNAME}: PYTHON_INCLUDEDIR =
> > ${PYTHON_INCLUDEDIR}"
> >
> > --
> > 2.41.0
> >
Oops, not like me to miss that. Thanks!
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH] python-utils-r1.eclass: Fix PYTHON_SITEDIR/INCLUDEDIR for cross-prefix
We dynamically determine Python's SITEDIR and INCLUDEDIR using the build
host's Python. This breaks down when the build host's prefix differs
from the target host's prefix, so chop off the former and prepend the
latter.
This assumes that each Python implementation is always installed using
the same scheme. Meson already makes this assumption, and gpep517 makes
a similar assumption to determine Python's stdlib location.
We could improve on this and determine these locations using SYSROOT's
sysconfigdata file, like gpep517 does, but this seems needlessly
complex. We would need to take this approach for PYTHON_LIBPATH and
PYTHON_CONFIG, but these are only used by handful of packages.
${BROOT-${EPREFIX}} is needed rather than plain ${BROOT} for the same
reason we need it for PYTHON, namely that Portage <3.0.50 was buggy.
Signed-off-by: James Le Cuirot
---
Note that gpep517 also needs the same treatment, but I'll handle that
later. This at least allows Portage itself to be installed.
eclass/python-utils-r1.eclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index 2fffd6d56bf5..68b28c0ed806 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -351,6 +351,7 @@ _python_export() {
print(sysconfig.get_path("purelib"))
EOF
)
+
PYTHON_SITEDIR=${EPREFIX}${PYTHON_SITEDIR#${BROOT-${EPREFIX}}}
export PYTHON_SITEDIR
debug-print "${FUNCNAME}: PYTHON_SITEDIR =
${PYTHON_SITEDIR}"
;;
@@ -362,6 +363,7 @@ _python_export() {
print(sysconfig.get_path("platinclude"))
EOF
)
+
PYTHON_INCLUDEDIR=${ESYSROOT}${PYTHON_INCLUDEDIR#${BROOT-${EPREFIX}}}
export PYTHON_INCLUDEDIR
debug-print "${FUNCNAME}: PYTHON_INCLUDEDIR =
${PYTHON_INCLUDEDIR}"
--
2.41.0
[gentoo-dev] [PATCH 2/2] python-utils-r1.eclass: Fix shebangs using ${EPYTHON}, not ${PYTHON}
${PYTHON} points to BROOT's Python because it's usually used for calling
Python during the build. This value will be wrong at runtime after
building cross-prefix.
Signed-off-by: James Le Cuirot
---
eclass/python-utils-r1.eclass | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index 56b1b81edd2e..2555ce12d066 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -1023,8 +1023,6 @@ python_fix_shebang() {
debug-print-function ${FUNCNAME} "${@}"
[[ ${EPYTHON} ]] || die "${FUNCNAME}: EPYTHON unset (pkg_setup not
called?)"
- local PYTHON
- _python_export "${EPYTHON}" PYTHON
local force quiet
while [[ ${@} ]]; do
@@ -1097,7 +1095,7 @@ python_fix_shebang() {
if [[ ! ${error} ]]; then
debug-print "${FUNCNAME}: in file ${f#${D%/}}"
debug-print "${FUNCNAME}: rewriting shebang:
${shebang}"
- sed -i -e "1s@${from}@#!${PYTHON}@" "${f}" ||
die
+ sed -i -e
"1s@${from}@#!${EPREFIX}/usr/bin/${EPYTHON}@" "${f}" || die
any_fixed=1
else
eerror "The file has incompatible shebang:"
--
2.41.0
[gentoo-dev] [PATCH 1/2] python-utils-r1.eclass: Remove old EAPI hack for exporting PYTHON
This eclass is EAPI 7+ now, so we can assume that BROOT is available.
This was broken anyway because it seems that Portage doesn't set BROOT
when it's empty.
Signed-off-by: James Le Cuirot
---
eclass/python-utils-r1.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index a883135eaa41..56b1b81edd2e 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -338,7 +338,7 @@ _python_export() {
debug-print "${FUNCNAME}: EPYTHON = ${EPYTHON}"
;;
PYTHON)
- export
PYTHON=${BROOT-${EPREFIX}}/usr/bin/${impl}
+ export PYTHON=${BROOT}/usr/bin/${impl}
debug-print "${FUNCNAME}: PYTHON = ${PYTHON}"
;;
PYTHON_SITEDIR)
--
2.41.0
[gentoo-dev] Last rites: games-action/descent3 and games-action/descent3-demo
# James Le Cuirot (2023-06-25) # Impossible to legally obtain the native full game now. It freezes on keyboard # input, is incompatible with PipeWire, and requires gamescope to display under # Wayland. In short, it's a lost cause. Removal in 30 days. Bug #436140. games-action/descent3 games-action/descent3-demo signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH] cmake.eclass: Set CMAKE_SYSROOT when building with SYSROOT=
From: Raul E Rangel
When performing a SYSROOT= build, the --sysroot parameter was not
getting passed to the compiler if the CBUILD and CHOST matched. This
results in the build attempting to use BROOT libraries and headers
instead of the ones from the SYSROOT.
This change will allow `llvm` to be built into a new SYSROOT.
ROOT=/build/amd64-host emerge sys-devel/llvm
Signed-off-by: Raul E Rangel
Closes: https://github.com/gentoo/gentoo/pull/30658
Signed-off-by: James Le Cuirot
---
eclass/cmake.eclass | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
index 24787f1c2a49..1cdbc123a243 100644
--- a/eclass/cmake.eclass
+++ b/eclass/cmake.eclass
@@ -484,17 +484,17 @@ cmake_src_configure() {
cat >> "${toolchain_file}" <<- _EOF_ || die
set(CMAKE_SYSTEM_NAME "${sysname}")
_EOF_
+ fi
- if [ "${SYSROOT:-/}" != "/" ] ; then
- # When cross-compiling with a sysroot (e.g. with
crossdev's emerge wrappers)
- # we need to tell cmake to use libs/headers from the
sysroot but programs from / only.
- cat >> "${toolchain_file}" <<- _EOF_ || die
- set(CMAKE_SYSROOT "${ESYSROOT}")
- set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
- set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
- set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
- _EOF_
- fi
+ if [[ ${SYSROOT:-/} != / ]] ; then
+ # When building with a sysroot (e.g. with crossdev's emerge
wrappers)
+ # we need to tell cmake to use libs/headers from the sysroot
but programs from / only.
+ cat >> "${toolchain_file}" <<- _EOF_ || die
+ set(CMAKE_SYSROOT "${ESYSROOT}")
+ set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
+ set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
+ set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
+ _EOF_
fi
if use prefix-guest; then
--
2.40.1
[gentoo-dev] [PATCH] qmake-utils.eclass: Force QMAKE_*FLAGS_RELEASE_WITH_DEBUGINFO to blank
These variables are usually defined as:
$ fgrep RELEASE_WITH_DEBUGINFO /usr/lib64/qt5/mkspecs/common/gcc-base.conf
QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO += $$QMAKE_CFLAGS_OPTIMIZE -g
QMAKE_CXXFLAGS_RELEASE_WITH_DEBUGINFO +=
$$QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO
QMAKE_LFLAGS_RELEASE_WITH_DEBUGINFO +=
They can take precedence over our provided flags, so they need to be
blanked out. They are normally only used when the user specifies
-force-debug-info, but sometimes upstreams enable this themselves.
Signed-off-by: James Le Cuirot
---
eclass/qmake-utils.eclass | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/eclass/qmake-utils.eclass b/eclass/qmake-utils.eclass
index a86ce1fbabb8..49e7d5d15883 100644
--- a/eclass/qmake-utils.eclass
+++ b/eclass/qmake-utils.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2022 Gentoo Authors
+# Copyright 1999-2023 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: qmake-utils.eclass
@@ -78,12 +78,15 @@ qt5_get_qmake_args() {
QMAKE_CFLAGS="${CFLAGS}"
QMAKE_CFLAGS_RELEASE=
QMAKE_CFLAGS_DEBUG=
+ QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO=
QMAKE_CXXFLAGS="${CXXFLAGS}"
QMAKE_CXXFLAGS_RELEASE=
QMAKE_CXXFLAGS_DEBUG=
+ QMAKE_CXXFLAGS_RELEASE_WITH_DEBUGINFO=
QMAKE_LFLAGS="${LDFLAGS}"
QMAKE_LFLAGS_RELEASE=
QMAKE_LFLAGS_DEBUG=
+ QMAKE_LFLAGS_RELEASE_WITH_DEBUGINFO=
EOF
}
--
2.40.1
Re: [gentoo-dev] wxGTK:3.0-gtk3 vs wxGTK:3.2-gtk3
On Wed, 2023-05-31 at 11:43 +, Andrey Grozin wrote: > Hello *, > > wxGTK:3.2-gtk3 is now stable. But there are 98 ebuilds depending on > wxGTK:3.0-gtk3 and only 22 ebuilds depending on wxGTK:3.2-gtk3 in the > tree. Probably, in a vast majority of cases 3.0 can be simply replaced by > 3.2 without any negative consequences. What could be a reasonable way to > organize the transition 3.0 -> 3.2 in the tree? File a zillion bugs? > > The fact that this dependence is written in a special syntax > WX_GTK_VER="3.0-gtk3" > makes such a transition more difficult. Unlike the normal dependency > syntax, it is not possible to write something like > x11-libs/wxGTK:*= > This is unfortunate. The 3.0 -> 3.2 transition absolutely requires to edit > ebuild texts, unlike :*= where the same ebuild can work with different > slots (just a recompilation is sufficient for transition). This fact > makes it impossible for an ebuild to work with both slots. In a majority > of cases, I suppose, it would be desirable to allow an ebuild to work with > any of these 2 slots, without a necessity to edit it. But, alas, this is > not possible. > > Andrey games-engines/odamex is another one that doesn't work with 3.2. It just crashes. Haven't looked into it. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites: www-client/chromium-bin
> On May 4, 2023 6:38:32 PM UTC, Mike Gilbert wrote: > > # Out of date by several versions. Many unresolved security > > # vulnerabilities. Lack of manpower/interest in keeping it up to date. > > # Removal on 2023-06-03. > > www-client/chromium-bin > > > On Thu, 2023-05-04 at 18:59 +, Maciej Barć wrote: > R.i.p. to a lot od desktop users on non-state-of-the-art HW. > But chromium source build was unusable for long time with big UI bugs. Those affected can try www-client/vivaldi instead. If you're unaware, it's based on Chromium. It's also a binary package, I keep it well-maintained, and if you ask me, it's just better all round. :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] distutils-r1.eclass: Add PYTHON_DEPS to DEPEND unconditionally
On 12 April 2023 16:58:58 BST, "Michał Górny" wrote:
>From: Raul E Rangel
>
>Python distutils packages that build C extensions are currently not
>declaring PYTHON_DEPS as part of their DEPEND declaration. This results
>in build errors when cross compiling using ROOT=.
>
>i.e.,
> In file included from src/setproctitle.c:14:
> In file included from src/spt.h:15:
> src/spt_python.h:15:10: fatal error: 'Python.h' file not found
> #include
>^~
> 1 error generated.
>
>Since the distutils-r1 eclass currently sets the RDEPEND and BDEPEND
>variables it makes sense to have the eclass also set the DEPEND
>variable. We unconditionally add it to keep the API simple. If in the
>future this is problematic, we can maybe add a DISTUTILS_PURE_PYTHON
>eclass variable that will omit the DEPEND.
>
>Signed-off-by: Raul E Rangel
>Closes: https://github.com/gentoo/gentoo/pull/30469
>Signed-off-by: Michał Górny
>---
> eclass/distutils-r1.eclass | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
>diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
>index 09684781de2a..7e9cd6ef9b5a 100644
>--- a/eclass/distutils-r1.eclass
>+++ b/eclass/distutils-r1.eclass
>@@ -34,8 +34,8 @@
> # functions, you should consider calling the defaults (and especially
> # distutils-r1_python_prepare_all).
> #
>-# Please note that distutils-r1 sets RDEPEND and BDEPEND (or DEPEND
>-# in earlier EAPIs) unconditionally for you.
>+# Please note that distutils-r1 sets BDEPEND, DEPEND, and RDEPEND
>+# unconditionally for you.
> #
> # Also, please note that distutils-r1 will always inherit python-r1
> # as well. Thus, all the variables defined and documented there are
>@@ -307,6 +307,12 @@ _distutils_set_globals() {
> fi
>
> if [[ ! ${DISTUTILS_OPTIONAL} ]]; then
>+ # This dependency is only required for packages that build
>+ # C extensions. It was deemed cleaner to unconditionally
>+ # add the dependency than add it to the individual
>+ # ebuilds that need it.
>+ DEPEND="${PYTHON_DEPS}"
>+
> RDEPEND="${PYTHON_DEPS} ${rdep}"
> BDEPEND="${PYTHON_DEPS} ${bdep}"
> REQUIRED_USE=${PYTHON_REQUIRED_USE}
I think that's reasonable.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
[gentoo-dev] [PATCH] cmake.eclass: Set CMAKE_SYSROOT in toolchain file when necessary
We previously set CMAKE_FIND_ROOT_PATH, but CMAKE_SYSROOT also sets this
and more. The latter is needed when cross-compiling Fortran code such as
sci-libs/lapack. Without this, it uses the toolchain's default sysroot,
adds a -L/usr/${CHOST}/usr/lib flag based on that, reads the libc.so.6
ld script from this directory, does not apply any sysroot to the paths
within because the script is outside the sysroot, and finally fails when
attempting to link the host's libc.so.6.
Signed-off-by: James Le Cuirot
---
eclass/cmake.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
index 2c5620adede5..a2ff80a233b4 100644
--- a/eclass/cmake.eclass
+++ b/eclass/cmake.eclass
@@ -489,7 +489,7 @@ cmake_src_configure() {
# When cross-compiling with a sysroot (e.g. with
crossdev's emerge wrappers)
# we need to tell cmake to use libs/headers from the
sysroot but programs from / only.
cat >> "${toolchain_file}" <<- _EOF_ || die
- set(CMAKE_FIND_ROOT_PATH "${SYSROOT}")
+ set(CMAKE_SYSROOT "${ESYSROOT}")
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
--
2.39.1
Re: [gentoo-dev] Putting CC and CXX into make.conf
On Thu, 2023-02-09 at 14:03 +0100, Michał Górny wrote:
> Hi,
>
> I'd like to propose that we work towards having good defaults for CC
> and CXX variables in make.conf files. Something like:
>
> CC=${CHOST}-gcc
> CXX=${CHOST}-g++
>
> or:
>
> CC=${CHOST}-cc
> CXX=${CHOST}-c++
>
> Why?
>
> Right now we're pretty much relying on autoconf defaults: if CC/CXX is
> unset, autoconf looks for ${CHOST}-gcc and ${CHOST}-g++ appropriately.
> However, autoconf is only one of the many build systems (and no longer
> very popular, I'd say) and whenever apps use another build system or
> override the default lookup in autoconf, we need to 'tc-export CC CXX'
> in order to ensure that the right name is picked.
>
> Furthermore, some of us (myself included) actually set CC and CXX
> in their make.conf to a different value. As a result, they are exported
> already on our systems and it's hard for us to notice that our ebuilds
> are missing the tc-export call.
>
> I'm not aware of any downsides to having them set by default, except for
> the potentially problematic migration of existing systems.
>
> What are your thoughts?
I've long been surprised that CC/CXX are not exported when the FLAGS are. We
already set these when cross-compiling or when using Clang, and that's been
fine, so I really don't see any issue.
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] kernel-2.eclass: Make xmakeopts an array for spaces in toolchain vars
On Mon, 2023-01-23 at 11:20 -0500, Joshua Kinard wrote:
> On 1/21/2023 06:03, James Le Cuirot wrote:
> > Variables like CC can have spaces for additional arguments. This is
> > particularly useful for reliably setting the sysroot.
> >
> > Signed-off-by: James Le Cuirot
> > ---
> > eclass/kernel-2.eclass | 21 +++--
> > 1 file changed, 15 insertions(+), 6 deletions(-)
> >
> > diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> > index 873d4a204669..f7fcf15743f0 100644
> > --- a/eclass/kernel-2.eclass
> > +++ b/eclass/kernel-2.eclass
> > @@ -1,4 +1,4 @@
> > -# Copyright 1999-2022 Gentoo Authors
> > +# Copyright 1999-2023 Gentoo Authors
> > # Distributed under the terms of the GNU General Public License v2
> >
> > # @ECLASS: kernel-2.eclass
> > @@ -756,13 +756,22 @@ env_setup_xmakeopts() {
> >
> > # When cross-compiling, we need to set the ARCH/CROSS_COMPILE
> > # variables properly or bad things happen !
> > - xmakeopts="ARCH=${KARCH}"
> > + xmakeopts=( ARCH="${KARCH}" )
> > if [[ ${CTARGET} != ${CHOST} ]] && ! cross_pre_c_headers; then
> > - xmakeopts="${xmakeopts} CROSS_COMPILE=${CTARGET}-"
> > + xmakeopts+=( CROSS_COMPILE="${CTARGET}-" )
> > elif type -p ${CHOST}-ar >/dev/null; then
> > - xmakeopts="${xmakeopts} CROSS_COMPILE=${CHOST}-"
> > + xmakeopts+=( CROSS_COMPILE="${CHOST}-" )
> > fi
> > - xmakeopts="${xmakeopts} HOSTCC=$(tc-getBUILD_CC) CC=$(tc-getCC)
> > LD=$(tc-getLD) AR=$(tc-getAR) NM=$(tc-getNM) OBJCOPY=$(tc-getOBJCOPY)
> > READELF=$(tc-getREADELF) STRIP=$(tc-getSTRIP)"
> > + xmakeopts+=(
> > + HOSTCC="$(tc-getBUILD_CC)"
> > + CC="$(tc-getCC)"
> > + LD="$(tc-getLD)"
> > + AR="$(tc-getAR)"
> > + NM="$(tc-getNM)"
> > + OBJCOPY="$(tc-getOBJCOPY)"
> > + READELF="$(tc-getREADELF)"
> > + STRIP="$(tc-getSTRIP)"
> > + )
> > export xmakeopts
> > }
> >
> > @@ -850,7 +859,7 @@ install_headers() {
> > local ddir=$(kernel_header_destdir)
> >
> > env_setup_xmakeopts
> > - emake headers_install INSTALL_HDR_PATH="${ED}"${ddir}/.. ${xmakeopts}
> > + emake headers_install INSTALL_HDR_PATH="${ED}"${ddir}/..
> > "${xmakeopts[@]}"
> >
> > # let other packages install some of these headers
> > rm -rf "${ED}"${ddir}/scsi || die #glibc/uclibc/etc...
>
> Can we perhaps use this opportunity to make "xmakeopts" more clear via a
> better name, as well as uppercase it
> to indicate that it is an exported variable? E.g., something like
> "CROSS_MAKEOPTS" is more clear to the
> reader than "xmakeopts", IMHO.
>
> I realize such a change may be a tad invasive to the eclass and possibly
> touch some ebuilds, so that may need
> to be a separate patch that this proposed change would then be based off of.
I hadn't noticed some older linux-headers ebuilds use this variable, so thanks
for bringing that to my attention. Arguably they shouldn't, as it appears to
be an internal variable, even if it is exported, but it's been dropped in
later versions anyway. I've now made further changes. Please see the two
additional patches.
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH 3/3] sys-kernel/linux-headers: Adjust following kernel-2.eclass changes
Signed-off-by: James Le Cuirot
---
sys-kernel/linux-headers/linux-headers-5.10-r2.ebuild | 2 +-
sys-kernel/linux-headers/linux-headers-5.15-r3.ebuild | 2 +-
sys-kernel/linux-headers/linux-headers-5.19.ebuild| 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/sys-kernel/linux-headers/linux-headers-5.10-r2.ebuild
b/sys-kernel/linux-headers/linux-headers-5.10-r2.ebuild
index 08907ac2fb24..06fcc6978ce1 100644
--- a/sys-kernel/linux-headers/linux-headers-5.10-r2.ebuild
+++ b/sys-kernel/linux-headers/linux-headers-5.10-r2.ebuild
@@ -40,7 +40,7 @@ src_prepare() {
}
src_test() {
- emake headers_check ${xmakeopts}
+ emake headers_check "${KERNEL_MAKEOPTS[@]}"
}
src_install() {
diff --git a/sys-kernel/linux-headers/linux-headers-5.15-r3.ebuild
b/sys-kernel/linux-headers/linux-headers-5.15-r3.ebuild
index 9d2ebae3daee..dae40c5ab655 100644
--- a/sys-kernel/linux-headers/linux-headers-5.15-r3.ebuild
+++ b/sys-kernel/linux-headers/linux-headers-5.15-r3.ebuild
@@ -43,7 +43,7 @@ src_prepare() {
}
src_test() {
- emake headers_check ${xmakeopts}
+ emake headers_check "${KERNEL_MAKEOPTS[@]}"
}
src_install() {
diff --git a/sys-kernel/linux-headers/linux-headers-5.19.ebuild
b/sys-kernel/linux-headers/linux-headers-5.19.ebuild
index 527b4b401d6c..8ae17e59be76 100644
--- a/sys-kernel/linux-headers/linux-headers-5.19.ebuild
+++ b/sys-kernel/linux-headers/linux-headers-5.19.ebuild
@@ -42,7 +42,7 @@ src_prepare() {
}
src_test() {
- emake headers_check ${xmakeopts}
+ emake headers_check "${KERNEL_MAKEOPTS[@]}"
}
src_install() {
--
2.39.1
[gentoo-dev] [PATCH 2/3] kernel-2.eclass: Rename xmakeopts to more appropriate KERNEL_MAKEOPTS
An upper-case name suggests that the variable is exported. This variable
is also not just used for cross-compiling any more.
Signed-off-by: James Le Cuirot
---
eclass/kernel-2.eclass | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index f7fcf15743f0..3c78aa5a8445 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -745,24 +745,25 @@ cross_pre_c_headers() {
use headers-only && [[ ${CHOST} != ${CTARGET} ]]
}
-# @FUNCTION: env_setup_xmakeopts
+# @FUNCTION: env_setup_kernel_makeopts
# @USAGE:
# @DESCRIPTION:
-# set the ARCH/CROSS_COMPILE when cross compiling
+# Set the toolchain variables, as well as ARCH and CROSS_COMPILE when
+# cross-compiling.
-env_setup_xmakeopts() {
+env_setup_kernel_makeopts() {
# Kernel ARCH != portage ARCH
export KARCH=$(tc-arch-kernel)
# When cross-compiling, we need to set the ARCH/CROSS_COMPILE
# variables properly or bad things happen !
- xmakeopts=( ARCH="${KARCH}" )
+ KERNEL_MAKEOPTS=( ARCH="${KARCH}" )
if [[ ${CTARGET} != ${CHOST} ]] && ! cross_pre_c_headers; then
- xmakeopts+=( CROSS_COMPILE="${CTARGET}-" )
+ KERNEL_MAKEOPTS+=( CROSS_COMPILE="${CTARGET}-" )
elif type -p ${CHOST}-ar >/dev/null; then
- xmakeopts+=( CROSS_COMPILE="${CHOST}-" )
+ KERNEL_MAKEOPTS+=( CROSS_COMPILE="${CHOST}-" )
fi
- xmakeopts+=(
+ KERNEL_MAKEOPTS+=(
HOSTCC="$(tc-getBUILD_CC)"
CC="$(tc-getCC)"
LD="$(tc-getLD)"
@@ -772,7 +773,7 @@ env_setup_xmakeopts() {
READELF="$(tc-getREADELF)"
STRIP="$(tc-getSTRIP)"
)
- export xmakeopts
+ export KERNEL_MAKEOPTS
}
# @FUNCTION: universal_unpack
@@ -858,8 +859,8 @@ install_universal() {
install_headers() {
local ddir=$(kernel_header_destdir)
- env_setup_xmakeopts
- emake headers_install INSTALL_HDR_PATH="${ED}"${ddir}/..
"${xmakeopts[@]}"
+ env_setup_kernel_makeopts
+ emake headers_install INSTALL_HDR_PATH="${ED}"${ddir}/..
"${KERNEL_MAKEOPTS[@]}"
# let other packages install some of these headers
rm -rf "${ED}"${ddir}/scsi || die #glibc/uclibc/etc...
@@ -1425,8 +1426,8 @@ kernel-2_src_unpack() {
[[ -z ${K_NOSETEXTRAVERSION} ]] && unpack_set_extraversion
unpack_fix_install_path
- # Setup xmakeopts and cd into sourcetree.
- env_setup_xmakeopts
+ # Setup KERNEL_MAKEOPTS and cd into sourcetree.
+ env_setup_kernel_makeopts
cd "${S}" || die
if [[ ${K_DEBLOB_AVAILABLE} == 1 ]] && use deblob; then
--
2.39.1
Re: [gentoo-dev] NEWS: Breaking changes to the RAP Prefix toolchain
On Fri, 2023-01-20 at 23:11 +, James Le Cuirot wrote:
> The context for this is a pull request I've been working on for a few weeks.
>
> https://github.com/gentoo/gentoo/pull/28851
>
> RAP prefix nobbled gcc/clang's sysroot when invoking the linker because glibc
> installed its linker scripts with prefixed paths, such as /path/to/prefix/lib
> rather than just /lib. Adjusting the linker scripts rather than the compiler
> behaviour is more natural and makes cross-compiling far easier.
>
> For the migration procedure, I did try a different approach of manually fixing
> up the linker scripts, but if you do this first, the gcc build fails
> immediately, and if you do this afterwards, the gcc build fails later. A
> symlink is therefore needed to allow the sysroot to be applied, even when the
> linker script paths are still prefixed.
>
> Unfortunately, it's not possible to filter news items on USE flags or even
> profile parents, so I've had to resort to explicitly listing all the prefix
> profiles. Prefix is quite a niche feature, so I don't want to show this news
> to everyone.
Following some feedback elsewhere, I'm going to add an additional paragraph,
because many users are not sure what kind of prefix they have. See below.
>
>
> Title: Breaking changes to the RAP Prefix toolchain
> Author: James Le Cuirot
> Posted: 2023-01-20
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Profile: default/linux/amd64/17.0/no-multilib/prefix/*
> Display-If-Profile: default/linux/amd64/17.1/no-multilib/prefix/*
> Display-If-Profile: default/linux/amd64/23.0/no-multilib/prefix/*
> Display-If-Profile: default/linux/amd64/23.0/split-usr/no-multilib/prefix/*
> Display-If-Profile: default/linux/arm/17.0/armv7a/prefix/*
> Display-If-Profile: default/linux/arm/23.0/armv7a/prefix/*
> Display-If-Profile: default/linux/arm/23.0/split-usr/armv7a/prefix/*
> Display-If-Profile: default/linux/arm64/17.0/prefix/*
> Display-If-Profile: default/linux/arm64/23.0/prefix/*
> Display-If-Profile: default/linux/arm64/23.0/split-usr/prefix/*
> Display-If-Profile: default/linux/ppc64le/17.0/prefix/*
> Display-If-Profile: default/linux/riscv/20.0/rv64gc/lp64d/prefix/*
> Display-If-Profile: default/linux/riscv/23.0/rv64/lp64d/prefix/*
> Display-If-Profile: default/linux/riscv/23.0/rv64/split-usr/lp64d/prefix/*
> Display-If-Profile: default/linux/x86/17.0/prefix/*
> Display-If-Profile: default/linux/x86/23.0/prefix/*
> Display-If-Profile: default/linux/x86/23.0/split-usr/prefix/*
>
> We are changing the way the toolchain operates on RAP Prefix systems in order
> to
> reduce the number of hacks we need to apply and make cross-compiling easier.
>
> If you using a non-RAP "Prefix Guest" or "Prefix Stack" variant (e.g. macOS)
> then this does not apply.
If you're not sure what kind of prefix you have, then check whether the
prefix-guest USE flag is enabled.
portageq envvar USE | grep prefix-guest
> If you are using a libc other than glibc (e.g. musl) then this *does* apply,
> but
> your libc will *not* break, so you should not carry out the following
> procedure.
> The only other package known to be affected is dev-libs/libbsd, which you can
> simply update. If you find another package affected by this, then please file
> a
> bug report.
>
> WARNING! It is important that you carry out the following procedure, otherwise
> your toolchain will break when you next update your compiler or glibc.
>
> 1. Run the following to create a temporary symlink:
>
> EPREFIX=$(portageq envvar EPREFIX)
> mkdir -p "${EPREFIX}${EPREFIX%/*}"
> ln -sn "${EPREFIX}" "${EPREFIX}${EPREFIX}"
>
> 2. Update or rebuild all installed slots of sys-devel/gcc and
> sys-devel/clang
> (if any). Feel free to remove any you no longer need.
>
> 3. Update or rebuild sys-libs/glibc.
>
> 4. Run the following to remove the symlink:
>
> EPREFIX=$(portageq envvar EPREFIX)
> rm "${EPREFIX}${EPREFIX}"
>
> 5. If dev-libs/libbsd is installed, then update it to 0.11.7-r2 or later.
>
> If you are reading this having updated glibc first and you are no longer able
> to
> build anything, then don't panic. Simply execute the line below and then carry
> out the regular procedure above.
>
> qlist sys-libs/glibc | xargs grep -lIF "GNU ld script" | xargs sed -i -r
> "s: /(usr|lib): $(portageq envvar EPREFIX)/\1:g"
>
signature.asc
Description: This is a digitally signed message part
[gentoo-dev] [PATCH 7/7] dev-libs/libbsd: Strip prefix from paths in ld script
ld scripts on standalone prefix (RAP) systems should have the prefix stripped
from any paths, as the sysroot is automatically prepended.
I originally thought this script was just used to apply --as-needed and was
therefore unneeded. It's actually used to automatically link libmd when it is
needed.
Signed-off-by: James Le Cuirot
---
dev-libs/libbsd/libbsd-0.11.7-r2.ebuild | 43 +
1 file changed, 43 insertions(+)
create mode 100644 dev-libs/libbsd/libbsd-0.11.7-r2.ebuild
diff --git a/dev-libs/libbsd/libbsd-0.11.7-r2.ebuild
b/dev-libs/libbsd/libbsd-0.11.7-r2.ebuild
new file mode 100644
index ..0fcfb6bd563b
--- /dev/null
+++ b/dev-libs/libbsd/libbsd-0.11.7-r2.ebuild
@@ -0,0 +1,43 @@
+# Copyright 1999-2022 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+
+VERIFY_SIG_OPENPGP_KEY_PATH="${BROOT}"/usr/share/openpgp-keys/guillemjover.asc
+inherit multilib multilib-minimal verify-sig
+
+DESCRIPTION="Library to provide useful functions commonly found on BSD systems"
+HOMEPAGE="https://libbsd.freedesktop.org/wiki/
https://gitlab.freedesktop.org/libbsd/libbsd";
+SRC_URI="https://${PN}.freedesktop.org/releases/${P}.tar.xz";
+SRC_URI+=" verify-sig? (
https://${PN}.freedesktop.org/releases/${P}.tar.xz.asc )"
+
+LICENSE="BSD BSD-2 BSD-4 ISC"
+SLOT="0"
+KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~loong ~m68k ~mips ~ppc ~ppc64
~riscv ~s390 ~sparc ~x86 ~amd64-linux ~x86-linux"
+IUSE="static-libs"
+
+RDEPEND="app-crypt/libmd[${MULTILIB_USEDEP}]"
+DEPEND="${RDEPEND}
+ >=sys-kernel/linux-headers-3.17
+"
+BDEPEND="verify-sig? ( sec-keys/openpgp-keys-guillemjover )"
+
+multilib_src_configure() {
+ # The build system will install libbsd-ctor.a despite USE="-static-libs"
+ # which is correct, see:
+ #
https://gitlab.freedesktop.org/libbsd/libbsd/commit/c5b959028734ca2281250c85773d9b5e1d259bc8
+ ECONF_SOURCE="${S}" econf $(use_enable static-libs static)
+}
+
+multilib_src_install() {
+ emake DESTDIR="${D}" install
+
+ find "${ED}" -type f -name "*.la" -delete || die
+
+ # ld scripts on standalone prefix (RAP) systems should have the prefix
+ # stripped from any paths, as the sysroot is automatically prepended.
+ local ldscript=${ED}/usr/$(get_libdir)/${PN}$(get_libname)
+ if use prefix && ! use prefix-guest && grep -qIF "ld script"
"${ldscript}" 2>/dev/null; then
+ sed -i "s|${EPREFIX}/|/|g" "${ldscript}" || die
+ fi
+}
--
2.39.1
[gentoo-dev] [PATCH 6/7] python-utils-r1.eclass: Use BROOT rather than EPREFIX for PYTHON var
The PYTHON variable is used for the wrapper shebangs. These should point
to the build system rather than the host system. The variable is also
used in other contexts, but the build system is still likely to be most
appropriate. If this does break anything, it'll only be for prefixed
systems.
Signed-off-by: James Le Cuirot
---
eclass/python-utils-r1.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass
index 43472bd1fae0..bc397229a670 100644
--- a/eclass/python-utils-r1.eclass
+++ b/eclass/python-utils-r1.eclass
@@ -332,7 +332,7 @@ _python_export() {
debug-print "${FUNCNAME}: EPYTHON = ${EPYTHON}"
;;
PYTHON)
- export PYTHON=${EPREFIX}/usr/bin/${impl}
+ export
PYTHON=${BROOT-${EPREFIX}}/usr/bin/${impl}
debug-print "${FUNCNAME}: PYTHON = ${PYTHON}"
;;
PYTHON_SITEDIR)
--
2.39.1
[gentoo-dev] [PATCH 5/7] sys-devel/clang: Move clang prefix tweaks from profile
Signed-off-by: James Le Cuirot
---
profiles/features/prefix/standalone/profile.bashrc | 11 +--
sys-devel/clang/clang-13.0.1.ebuild| 5 +
sys-devel/clang/clang-14.0.6-r1.ebuild | 5 +
sys-devel/clang/clang-15.0.6-r1.ebuild | 5 +
sys-devel/clang/clang-15.0.7-r1.ebuild | 5 +
sys-devel/clang/clang-16.0.0..ebuild | 5 +
sys-devel/clang/clang-16.0.0_pre20230101.ebuild| 5 +
7 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/profiles/features/prefix/standalone/profile.bashrc
b/profiles/features/prefix/standalone/profile.bashrc
index 57ec4b57abcb..d46933210dcc 100644
--- a/profiles/features/prefix/standalone/profile.bashrc
+++ b/profiles/features/prefix/standalone/profile.bashrc
@@ -9,16 +9,7 @@
# Disable RAP trick during bootstrap stage2
[[ -z ${BOOTSTRAP_RAP_STAGE2} ]] || return 0
-if [[ ${CATEGORY}/${PN} == sys-devel/clang && ${EBUILD_PHASE} == configure ]];
then
-ebegin "Use ${EPREFIX} as default sysroot"
-sed -i -e "s@DEFAULT_SYSROOT \"\"@DEFAULT_SYSROOT \"${EPREFIX}\"@"
"${S}"/CMakeLists.txt
-eend $?
-pushd "${S}/lib/Driver/ToolChains" >/dev/null
-ebegin "Use dynamic linker from ${EPREFIX}"
-sed -i -e "/LibDir.*Loader/s@return \"\/\"@return \"${EPREFIX%/}/\"@"
Linux.cpp
-eend $?
-popd >/dev/null
-elif [[ ${CATEGORY}/${PN} == sys-devel/binutils && ${EBUILD_PHASE} == prepare
]]; then
+if [[ ${CATEGORY}/${PN} == sys-devel/binutils && ${EBUILD_PHASE} == prepare
]]; then
ebegin "Prefixifying native library path"
sed -i -r "/NATIVE_LIB_DIRS/s,((/usr(/local|)|)/lib),${EPREFIX}\1,g" \
"${S}"/ld/configure.tgt
diff --git a/sys-devel/clang/clang-13.0.1.ebuild
b/sys-devel/clang/clang-13.0.1.ebuild
index 5e10d595d900..c3a97feedae7 100644
--- a/sys-devel/clang/clang-13.0.1.ebuild
+++ b/sys-devel/clang/clang-13.0.1.ebuild
@@ -82,6 +82,10 @@ src_prepare() {
eprefixify \
lib/Frontend/InitHeaderSearch.cpp \
lib/Driver/ToolChains/Darwin.cpp || die
+
+ if ! use prefix-guest && [[ -n ${EPREFIX} ]]; then
+ sed -i "/LibDir.*Loader/s@return \"\/\"@return
\"${EPREFIX}/\"@" lib/Driver/ToolChains/Linux.cpp || die
+ fi
}
check_distribution_components() {
@@ -224,6 +228,7 @@ multilib_src_configure() {
local clang_version=$(ver_cut 1-3 "${llvm_version}")
local mycmakeargs=(
+ -DDEFAULT_SYSROOT=$(usex prefix-guest "" "${EPREFIX}")
-DLLVM_CMAKE_PATH="${EPREFIX}/usr/lib/llvm/${SLOT}/$(get_libdir)/cmake/llvm"
-DCMAKE_INSTALL_PREFIX="${EPREFIX}/usr/lib/llvm/${SLOT}"
-DCMAKE_INSTALL_MANDIR="${EPREFIX}/usr/lib/llvm/${SLOT}/share/man"
diff --git a/sys-devel/clang/clang-14.0.6-r1.ebuild
b/sys-devel/clang/clang-14.0.6-r1.ebuild
index de10ab36054f..5cdb584470ac 100644
--- a/sys-devel/clang/clang-14.0.6-r1.ebuild
+++ b/sys-devel/clang/clang-14.0.6-r1.ebuild
@@ -95,6 +95,10 @@ src_prepare() {
eprefixify \
lib/Lex/InitHeaderSearch.cpp \
lib/Driver/ToolChains/Darwin.cpp || die
+
+ if ! use prefix-guest && [[ -n ${EPREFIX} ]]; then
+ sed -i "/LibDir.*Loader/s@return \"\/\"@return
\"${EPREFIX}/\"@" lib/Driver/ToolChains/Linux.cpp || die
+ fi
}
check_distribution_components() {
@@ -234,6 +238,7 @@ multilib_src_configure() {
local clang_version=$(ver_cut 1-3 "${llvm_version}")
local mycmakeargs=(
+ -DDEFAULT_SYSROOT=$(usex prefix-guest "" "${EPREFIX}")
-DLLVM_CMAKE_PATH="${EPREFIX}/usr/lib/llvm/${SLOT}/$(get_libdir)/cmake/llvm"
-DCMAKE_INSTALL_PREFIX="${EPREFIX}/usr/lib/llvm/${SLOT}"
-DCMAKE_INSTALL_MANDIR="${EPREFIX}/usr/lib/llvm/${SLOT}/share/man"
diff --git a/sys-devel/clang/clang-15.0.6-r1.ebuild
b/sys-devel/clang/clang-15.0.6-r1.ebuild
index 0e089832722b..0d534ff751d3 100644
--- a/sys-devel/clang/clang-15.0.6-r1.ebuild
+++ b/sys-devel/clang/clang-15.0.6-r1.ebuild
@@ -86,6 +86,10 @@ src_prepare() {
eprefixify \
lib/Lex/InitHeaderSearch.cpp \
lib/Driver/ToolChains/Darwin.cpp || die
+
+ if ! use prefix-guest && [[ -n ${EPREFIX} ]]; then
+ sed -i "/LibDir.*Loader/s@return \"\/\"@return
\"${EPREFIX}/\"@" lib/Driver/ToolChains/Linux.cpp || die
+ fi
}
check_distribution_components() {
@@ -246,6 +250,7 @@ get_distribution_components() {
multilib_src_configure() {
local mycmakeargs=(
+
[gentoo-dev] [PATCH 4/7] toolchain.eclass: Move remaining gcc prefix tweaks from profile
Signed-off-by: James Le Cuirot
---
eclass/toolchain.eclass| 13 +
profiles/features/prefix/standalone/profile.bashrc | 14 +-
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 479814f0df3e..6d8901d21812 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -719,6 +719,19 @@ toolchain_src_prepare() {
einfo "Remove texinfo (bug #198182, bug #464008)"
eapply "${FILESDIR}"/gcc-configure-texinfo.patch
+ if ! use prefix-guest && [[ -n ${EPREFIX} ]] ; then
+ einfo "Prefixifying dynamic linkers..."
+ for f in gcc/config/*/*linux*.h ; do
+ ebegin " Updating ${f}"
+ if [[ ${f} == gcc/config/rs6000/linux*.h ]]; then
+ sed -i -r
"s,(DYNAMIC_LINKER_PREFIX\s+)\"\",\1\"${EPREFIX}\",g" "${f}" || die
+ else
+ sed -i -r
"/_DYNAMIC_LINKER/s,([\":])(/lib),\1${EPREFIX}\2,g" "${f}" || die
+ fi
+ eend $?
+ done
+ fi
+
# >=gcc-4
if [[ -x contrib/gcc_update ]] ; then
einfo "Touching generated files"
diff --git a/profiles/features/prefix/standalone/profile.bashrc
b/profiles/features/prefix/standalone/profile.bashrc
index 043f766c37e9..57ec4b57abcb 100644
--- a/profiles/features/prefix/standalone/profile.bashrc
+++ b/profiles/features/prefix/standalone/profile.bashrc
@@ -9,19 +9,7 @@
# Disable RAP trick during bootstrap stage2
[[ -z ${BOOTSTRAP_RAP_STAGE2} ]] || return 0
-if [[ ${CATEGORY}/${PN} == sys-devel/gcc && ${EBUILD_PHASE} == configure ]];
then
-cd "${S}"
-einfo "Prefixifying dynamic linkers..."
-for h in gcc/config/*/*linux*.h; do
- ebegin " Updating $h"
- if [[ "${h}" == gcc/config/rs6000/linux*.h ]]; then
- sed -i -r "s,(DYNAMIC_LINKER_PREFIX\s+)\"\",\1\"${EPREFIX}\",g" $h
- else
- sed -i -r "/_DYNAMIC_LINKER/s,([\":])(/lib),\1${EPREFIX}\2,g" $h
- fi
- eend $?
-done
-elif [[ ${CATEGORY}/${PN} == sys-devel/clang && ${EBUILD_PHASE} == configure
]]; then
+if [[ ${CATEGORY}/${PN} == sys-devel/clang && ${EBUILD_PHASE} == configure ]];
then
ebegin "Use ${EPREFIX} as default sysroot"
sed -i -e "s@DEFAULT_SYSROOT \"\"@DEFAULT_SYSROOT \"${EPREFIX}\"@"
"${S}"/CMakeLists.txt
eend $?
--
2.39.1
[gentoo-dev] [PATCH 3/7] toolchain.eclass: Fix cross-compiling gcc for standalone prefix
Standalone prefix has always configured gcc with a sysroot, but the
location of this sysroot is different at build time when
cross-compiling. gcc has a separate configure option for that.
prefix-guest systems do not have a sysroot applied, as they use the
host's libc.
Move this code from the prefix profile into the eclass so that it's less
of a special case. We can avoid relying on the `BOOTSTRAP_RAP_STAGE2`
variable by checking for the `prefix-guest` USE flag instead, as a
prefix-guest profile is now used for RAP stage 2.
Signed-off-by: James Le Cuirot
---
eclass/toolchain.eclass | 15 +++
.../features/prefix/standalone/profile.bashrc | 3 ---
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 0dd23d93e383..479814f0df3e 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -1200,6 +1200,21 @@ toolchain_src_configure() {
confgcc+=( --enable-threads=posix )
;;
esac
+
+ if ! use prefix-guest ; then
+ # GNU ld scripts, such as those in glibc, reference
unprefixed paths
+ # as the sysroot given here is automatically prepended.
For
+ # prefix-guest, we use the host's libc instead.
+ if [[ -n ${EPREFIX} ]] ; then
+ confgcc+=( --with-sysroot="${EPREFIX}" )
+ fi
+
+ # We need to build against the right headers and
libraries. Again,
+ # for prefix-guest, this is the host's.
+ if [[ -n ${ESYSROOT} ]] ; then
+ confgcc+=( --with-build-sysroot="${ESYSROOT}" )
+ fi
+ fi
fi
# __cxa_atexit is "essential for fully standards-compliant handling of
diff --git a/profiles/features/prefix/standalone/profile.bashrc
b/profiles/features/prefix/standalone/profile.bashrc
index 3cdda77b9a88..043f766c37e9 100644
--- a/profiles/features/prefix/standalone/profile.bashrc
+++ b/profiles/features/prefix/standalone/profile.bashrc
@@ -21,9 +21,6 @@ if [[ ${CATEGORY}/${PN} == sys-devel/gcc && ${EBUILD_PHASE}
== configure ]]; the
fi
eend $?
done
-
-# use sysroot of toolchain to get correct include and library at compile
time
-EXTRA_ECONF="${EXTRA_ECONF} --with-sysroot=${EPREFIX}"
elif [[ ${CATEGORY}/${PN} == sys-devel/clang && ${EBUILD_PHASE} == configure
]]; then
ebegin "Use ${EPREFIX} as default sysroot"
sed -i -e "s@DEFAULT_SYSROOT \"\"@DEFAULT_SYSROOT \"${EPREFIX}\"@"
"${S}"/CMakeLists.txt
--
2.39.1
