| Age | Commit message (Collapse) | Author |
|---|
|
Update done using:
```
git grep -l sys-libs/zlib dev-* | xargs sed -i -e s@sys-libs/zlib@virtual/zlib@g
git diff --name-only | xargs copybump
git diff --name-only | xargs grep -l PYTHON_COMPAT | xargs gpy-impl -@dead
pkgcheck scan --commits -c SourcingCheck,VisibilityCheck --exit error
```
Followed by manual revert in dev-python/zlib-ng where it accidentally
caught sys-libs/zlib-ng dependencies.
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
When bootstrapping Rust with the llvm profile (both glibc and musl),
the build fails at the mrustc stage due to two issues related to C++
standard library handling.
1. Compilation failure
When llvm-core/llvm is built with clang, 'llvm-config --cxxflags' includes
'-stdlib=libc++', but not when built with GCC. But under musl profile, GCC
has a known bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122409) in
handling the '-stdlib=libc++' option. It fails to search '/usr/include/c++/v1',
causing standard headers such as <cstddef> to be missing unless the include path is
manually specified via '-I/usr/include/c++/v1'.
This patch fixes the issue by wrapping llvm-config calls and explicitly
appending libc++'s header path whenever '-stdlib=libc++' is detected.
Below is the relevant error log:
> Calling /var/tmp/portage/dev-lang/rust-1.74.1-r101/work/bootstrap/mrustc-stage0/rustc-build/build_rustc_llvm_run failed (see /var/tmp/portage/dev-lang/rust-1.74.1-r101/work/bootstrap/mrustc-stage0/rustc-build/build_rustc_llvm.txt_failed.txt for stdout)
/var/tmp/portage/dev-lang/rust-1.74.1-r101/work/bootstrap/mrustc-stage0/rustc-build/build_rustc_llvm.txt_failed.txt
> running: "x86_64-pc-linux-musl-g++" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "-gdwarf-4" "-fno-omit-frame-pointer" "-m64" "-O2" "-pipe" "-I/usr/lib/llvm/17/include" "-std=c++17" "-stdlib=libc++" "-D__STDC_CONSTANT_MACROS" "-D__STDC_FORMAT_MACROS" "-D__STDC_LIMIT_MACROS" "-DLLVM_COMPONENT_AARCH64" "-DLLVM_COMPONENT_AMDGPU" "-DLLVM_COMPONENT_ARM" "-DLLVM_COMPONENT_ASMPARSER" "-DLLVM_COMPONENT_AVR" "-DLLVM_COMPONENT_BITREADER" "-DLLVM_COMPONENT_BITWRITER" "-DLLVM_COMPONENT_BPF" "-DLLVM_COMPONENT_COVERAGE" "-DLLVM_COMPONENT_HEXAGON" "-DLLVM_COMPONENT_INSTRUMENTATION" "-DLLVM_COMPONENT_IPO" "-DLLVM_COMPONENT_LINKER" "-DLLVM_COMPONENT_LOONGARCH" "-DLLVM_COMPONENT_LTO" "-DLLVM_COMPONENT_MIPS" "-DLLVM_COMPONENT_MSP430" "-DLLVM_COMPONENT_NVPTX" "-DLLVM_COMPONENT_POWERPC" "-DLLVM_COMPONENT_RISCV" "-DLLVM_COMPONENT_SPARC" "-DLLVM_COMPONENT_SYSTEMZ" "-DLLVM_COMPONENT_WEBASSEMBLY" "-DLLVM_COMPONENT_X86" "-o" "/var/tmp/portage/dev-lang/rust-1.74.1-r101/work/bootstrap/mrustc-stage0/rustc-build/build_rustc_llvm/llvm-wrapper/PassWrapper.o" "-c" "llvm-wrapper/PassWrapper.cpp"
> cargo:warning=llvm-wrapper/PassWrapper.cpp:3:10: fatal error: cstddef: No such file or directory
> cargo:warning= 3 | #include <cstddef>
> cargo:warning= | ^~~~~~~~~
> cargo:warning=compilation terminated.
> exit status: 1
2. Linker failure
Found on llvm profile for both glibc and musl if llvm-core/llvm is built
by GCC. The bundled llvm is always built by gcc because bootstrap with
murst requires gcc. Under the llvm profile `LLVM_USE_LIBCXX=1` is
defined, causing Rust build scripts to link with `-lc++` instead of
`-lstdc++`. Since mrustc’s g++-compiled objects depend on libstdc++,
linking fails with (glibc):
> /.../x86_64-pc-linux-musl/bin/ld: /var/tmp/portage/dev-lang/rust-1.74.1-r101/work/bootstrap/mrustc-stage0/rustc-build/build_rustc_llvm/libllvm-wrapper.a(PassWrapper.o): undefined reference to symbol '_ZNSt6localeD1Ev@@GLIBCXX_3.4'
> /.../x86_64-pc-linux-musl/bin/ld: /usr/lib/gcc/x86_64-pc-linux-musl/15/libstdc++.so.6: error adding symbols: DSO missing from command line
or (musl):
> /.../x86_64-pc-linux-musl/bin/ld: warning: x86_64.o: missing .note.GNU-stack section implies executable stack
> /.../x86_64-pc-linux-musl/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
> /.../x86_64-pc-linux-musl/bin/ld: /var/tmp/portage/dev-lang/rust-1.74.1-r101/work/bootstrap/mrustc-stage0/rustc-build/build_rustc_llvm/libllvm-wrapper.a(PassWrapper.o): in function `std::_Rb_tree_iterator<std::pair<unsigned long const, llvm::GlobalValue::LinkageTypes> >::operator--()':
> /usr/lib/gcc/x86_64-pc-linux-musl/14/include/g++-v14/bits/stl_tree.h:298:(.text._ZNSt8_Rb_treeImSt4pairIKmN4llvm11GlobalValue12LinkageTypesEESt10_Select1stIS5_ESt4lessImESaIS5_EE24_M_get_insert_unique_posERS1_.isra.0+0x93): undefined reference to `std::_Rb_tree_decrement(std::_Rb_tree_node_base*)'
Fix by unsetting `LLVM_USE_LIBCXX` during bootstrap, ensuring that the
build links against libstdc++ instead of libc++. See the relevant Rust code
in `compiler/rustc_llvm/build.rs`.
Note: llvm-config may refer to the bundled LLVM if USE="-system-llvm",
so we avoid relying on tc-get-cxx-stdlib in this context.
Signed-off-by: Z. Liu <zhixu.liu@gmail.com>
Part-of: https://github.com/gentoo/gentoo/pull/44129
Closes: https://github.com/gentoo/gentoo/pull/44129
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Result of running the command:
grep --include="*.ebuild" -r . -e 'KEYWORDS=.*[" ]sparc' -l | xargs ekeyword ~sparc
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
Add reminder to ebuild to update the git repo and make a new tag as
required instead of using filesdir: that's how we end up exceeding the
limit; things are very rarely cleaned up here!
Signed-off-by: Matt Jolly <kangie@gentoo.org>
|
|
As noted in 850d5e6b5cd12da2ad9bc37d3b21b87ef210c7f7, this is fine to do
these days. Combined with the LLVM_TARGET fixes from earlier today, this
should lead to a nice build-time improvement too.
Closes: https://bugs.gentoo.org/735154
Signed-off-by: Sam James <sam@gentoo.org>
|
|
We already depend on the right LLVM targets but without =, but we need
that as it's automagic otherwise. I'm not completely convinced we need
it here, but my aim is to avoid breaking things and then improve more
later.
Bug: https://bugs.gentoo.org/735154
Bug: https://bugs.gentoo.org/767700
Bug: https://bugs.gentoo.org/768267
Signed-off-by: Sam James <sam@gentoo.org>
|
|
My previous fix didn't actually unpack tarballs at all.
Signed-off-by: Matt Jolly <kangie@gentoo.org>
|
|
When the patch tarballs were added the ebuilds were not updated to
ensure that only upstream-signed files are verified.
Signed-off-by: Matt Jolly <kangie@gentoo.org>
|
|
Signed-off-by: Matt Jolly <kangie@gentoo.org>
|
|
After discussion with upstream, reduce the number of `v`s passed to
of our `x.py` invocations. There is no documentation on why `-vvv` was
added but it's suspected to be development troubleshooting shrapnel.
`-vv` is retained for tests where the extra verbosity may actually be
useful, however for most cases `-v` is suitable as it includes the
invocation along with any warnings or errors; we probably don't need
thousands of backtraces or diagnostic messages.
Signed-off-by: Matt Jolly <kangie@gentoo.org>
|
|
files/ has been too big for a while now. Instead use the rust-patches
repository that was created to manage these patches.
No revbumps required - they were either done beforehand when we dropped
a bad patch _or_ are not required as the only additions are backported
build-time fixes (done in previous commits).
Signed-off-by: Matt Jolly <kangie@gentoo.org>
|
|
Signed-off-by: Matt Jolly <kangie@gentoo.org>
|
|
I'm sick of seeing the pkgcheck output even though this is objectively worse.
Signed-off-by: Matt Jolly <kangie@gentoo.org>
|
|
We've been saying that we'll update this for years now.
Clearly not happening; it can live in Git history.
Signed-off-by: Matt Jolly <kangie@gentoo.org>
|
|
... otherwise CC at the time of building dev-lang/rust is baked in,
which is problematic if e.g. CC=clang-19 is used and then it gets
depcleaned later (as reported on the gentoo-user ML).
Signed-off-by: Sam James <sam@gentoo.org>
|
|
1. target in ALL_LLVM_TARGETS has prefix llvm_targets_, so the check in
last commit failed always.
2. using associate array for the test of experimental target's existence
3. sed -i 's:LLVM_EXPERIMENTAL_TARGETS:RUST_EXPERIMENTAL_TARGETS:g' to
fix warning on var name collide with ALL_LLVM_EXPERIMENTAL_TARGETS in
llvm.org.eclass
Fixes: ff8e2b548c258e60463b1df0224beda29c7aacec
Signed-off-by: Z. Liu <zhixu.liu@gmail.com>
Closes: https://github.com/gentoo/gentoo/pull/40698
Signed-off-by: Sam James <sam@gentoo.org>
|
|
Found while compiling with a fresh crossdev installation.
Without that, the build fails with the following error:
```[profiler_builtins 0.0.0] cargo::rerun-if-env-changed=LLVM_PROFILER_RT_LIB
[profiler_builtins 0.0.0] cargo::rerun-if-env-changed=RUST_COMPILER_RT_FOR_PROFILER
[profiler_builtins 0.0.0] cargo::rerun-if-changed=/usr/i686-pc-linux-musl/tmp/portage/dev-lang/rust-1.82.0-r102/work/rustc-1.82.0-src/src/llvm-project/compiler-rt/lib/profile
[profiler_builtins 0.0.0] cargo::rerun-if-changed=/usr/i686-pc-linux-musl/tmp/portage/dev-lang/rust-1.82.0-r102/work/rustc-1.82.0-src/src/llvm-project/compiler-rt/include
[profiler_builtins 0.0.0] TARGET = Some("i686-unknown-linux-gnu")
[profiler_builtins 0.0.0] OPT_LEVEL = Some("3")
[profiler_builtins 0.0.0] HOST = Some("x86_64-unknown-linux-gnu")
[profiler_builtins 0.0.0] cargo:rerun-if-env-changed=CC_i686-unknown-linux-gnu
[profiler_builtins 0.0.0] CC_i686-unknown-linux-gnu = None
[profiler_builtins 0.0.0] cargo:rerun-if-env-changed=CC_i686_unknown_linux_gnu
[profiler_builtins 0.0.0] CC_i686_unknown_linux_gnu = Some("i686-pc-linux-musl-gcc")
[profiler_builtins 0.0.0] cargo:rerun-if-env-changed=CC_ENABLE_DEBUG_OUTPUT
[profiler_builtins 0.0.0] cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
[profiler_builtins 0.0.0] CRATE_CC_NO_DEFAULTS = None
[profiler_builtins 0.0.0] DEBUG = Some("false")
[profiler_builtins 0.0.0] CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2")
[profiler_builtins 0.0.0] cargo:rerun-if-env-changed=CFLAGS_i686-unknown-linux-gnu
[profiler_builtins 0.0.0] CFLAGS_i686-unknown-linux-gnu = None
[profiler_builtins 0.0.0] cargo:rerun-if-env-changed=CFLAGS_i686_unknown_linux_gnu
[profiler_builtins 0.0.0] CFLAGS_i686_unknown_linux_gnu = Some("-ffunction-sections -fdata-sections -fPIC -m32 -march=i686")
[profiler_builtins 0.0.0] cargo:warning=i686-pc-linux-musl-gcc: error: /usr/i686-pc-linux-musl/tmp/portage/dev-lang/rust-1.82.0-r102/work/rustc-1.82.0-src/src/llvm-project/compiler-rt/lib/profile/InstrProfiling
Runtime.cpp: C++ compiler not installed on this system
[profiler_builtins 0.0.0]
[profiler_builtins 0.0.0]
[profiler_builtins 0.0.0] error occurred: Command "i686-pc-linux-musl-gcc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m32" "-march=i686" "-I" "/usr/i686-pc-linux-musl/tmp/portage/dev-lang/rust-1.82
.0-r102/work/rustc-1.82.0-src/src/llvm-project/compiler-rt/include" "-ffunction-sections" "-fdata-sections" "-fPIC" "-m32" "-march=i686" "-fno-builtin" "-fomit-frame-pointer" "-fvisibility=hidden" "-DVISIBILITY
_HIDDEN" "-DCOMPILER_RT_HAS_UNAME=1" "-DCOMPILER_RT_HAS_FCNTL_LCK=1" "-DCOMPILER_RT_HAS_ATOMICS=1" "-o" "/usr/i686-pc-linux-musl/tmp/portage/dev-lang/rust-1.82.0-r102/work/rustc-1.82.0-src/build/x86_64-unknown-
linux-gnu/stage1-std/i686-unknown-linux-gnu/release/build/profiler_builtins-acc5b54be66bd911/out/79fe831ac9526f6c-InstrProfilingRuntime.o" "-c" "/usr/i686-pc-linux-musl/tmp/portage/dev-lang/rust-1.82.0-r102/wor
k/rustc-1.82.0-src/src/llvm-project/compiler-rt/lib/profile/
InstrProfilingRuntime.cpp" with args i686-pc-linux-musl-gcc did not execute successfully (status code exit status: 1).
[profiler_builtins 0.0.0]
[profiler_builtins 0.0.0]
The following warnings were emitted during compilation:
warning: profiler_builtins@0.0.0: i686-pc-linux-musl-gcc: error: /usr/i686-pc-linux-musl/tmp/portage/dev-lang/rust-1.82.0-r102/work/rustc-1.82.0-src/src/llvm-project/compiler-rt/lib/profile/InstrProfilingRuntime.cpp: C++ compiler not installed on this system
error: failed to run custom build command for `profiler_builtins v0.0.0 (/usr/i686-pc-linux-musl/tmp/portage/dev-lang/rust-1.82.0-r102/work/rustc-1.82.0-src/library/profiler_builtins)`
note: To improve backtraces for build dependencies, set the CARGO_PROFILE_RELEASE_BUILD_OVERRIDE_DEBUG=true environment variable to enable debug information generation.```
Signed-off-by: Cristian Othón Martínez Vera <cfuga@cfuga.mx>
Closes: https://github.com/gentoo/gentoo/pull/40600
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
current experimental targets are defined from v1.73 only, so the final
experimental target list should be the intersection of
ALL_LLVM_EXPERIMENTAL_TARGETS in ALL_LLVM_TARGETS.
Fixes: 94e2375d8bbaa777c83a3bffd60355075ee6ff83
Fixes: 3d841904ebfe01e74cb01eae6456b30f6aeca7e8
Closes: https://bugs.gentoo.org/949795
Signed-off-by: Z. Liu <zhixu.liu@gmail.com>
Closes: https://github.com/gentoo/gentoo/pull/40594
Signed-off-by: Sam James <sam@gentoo.org>
|
|
We have to revbump for bug #949374 anyway so this is a good time to change
it.
Propagate the change we did in d7f3dfefc2ab978d5d38b50d1e061c4a530d85f8 for
older rusts accordingly.
Bug: https://bugs.gentoo.org/949374
Signed-off-by: Sam James <sam@gentoo.org>
|
|
For a reason lost to the sands of time, Gentoo was previously
disabling the `rpath` option in the Rust config.toml and instead
adding Rust the Rust lib path to `ld.so.conf` via entries installed
in `/etc/env.d`.
This was fine before we enabled slotting on the Rust package, however
with increasing numbers of Rust slots a hash collision was inevitable
and eventually happened between 1.84.0 and 1.84.1, resulting in
`undefined symbol` errors when invoking `rustc` or `cargo`.
Since we install Rust in a very similar way to upstream, it makes
sense to set the `RUNPATH` to `$ORIGIN/../lib` as their packaging
does and not pollute ld.so.conf with Rust paths.
This enables dev-lang/rust binaries to search relative to
their install location, and will therefore always respect EPREFIX.
Also drop obsolete 1.82.0-r100; no need to revbump that.
Closes: https://bugs.gentoo.org/949374
Signed-off-by: Matt Jolly <kangie@gentoo.org>
Signed-off-by: Sam James <sam@gentoo.org>
|
