- Status New
- Percent Complete
- Task Type Bug Report
- Category Packages → Packages: Build-list
- Assigned To No-one
- Operating System i686
- Severity Low
- Priority Medium
- Reported Version
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#71 - rust doesn't rebuild
We need llvm 7.0 instead of 7.1.
If we muss a llvm update, bootstrapping rust fails (due to a to old libLLVM.so).
defined multiple times
- -> /build/rust/src/rustc-1.34.1-src/build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-02dad87448159bce/out/consts.rs:2112:5
|
2110 | pub type U1024 = UInt, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>;
| ------------------------------------------------------------------------------------------------------------------------------------- previous definition of the type `U1024` here
2111 | pub type P1024 = PInt; pub type N1024 = NInt;
2112 | pub type U1024 = UInt, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>, B0>;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `U1024` redefined here
https://github.com/paholg/typenum/commit/14a3322d1081fd63d5eb44bf8ab8f90676208228
Can anobody tell me, how we apply patches to downloaded artifacts while building?!
> Can anobody tell me, how we apply patches to downloaded artifacts while building?!
I only have a racy solutions for that. Put the following at the start of build():
while true; do
find $rust-build-dir-path -type f -name $name-to-patch -execdir patch -p1 -i $srcdir/patch \; && break
done &
trying to compile rust 1.34 with llvm-libs 7:
let's try again with:
injected in build() ... which is the mother of all race conditions
current error:
trying again with some even-more-racing build()
this is super-annoying: now the old "duplicate definition" error is back ... but in package_rust()
Let's build again (for several hours O.o) with this hack also applied in package_rust() ...
whoah, even more fun:
current approach: using rust-1.36 from manjaro32 (thanks, jonathon!) ... this fails in stage 1, because it does not find some library, which actually _is_ there (but apparently not in the search path).
symlinking the library to the correct one hidden in some "stage1" folder solved it. Now we have rust 1.36 for i686 in [build-support] - let's hope some build slave can build a regular rust (e.g. one where I do not extract additional files with bsdtar into the build chroot) from that and we can close this bug report.
Rebuilds of rust on i686 and pentium4 show:
Tried with precompiled binaries (AUR package 'rust-bin'):
https://aur.archlinux.org/packages/rust-bin/
Compiling 1.37.0 from source now results in LLVM: out of memory,
see also:
https://github.com/rust-lang/rust/issues/60294
Fedora 31 will also complain, so there is a chance Rust people are actually doing something
and not just ignoring us:
https://bugzilla.redhat.com/show_bug.cgi?id=1723064
Asked upstream about how rust is supposed to be built on a machine with 32-bit
address space:
https://github.com/rust-lang/rust/issues/60294
–debuginfo-level-std=1
in config.toml
works over the first out of memory situations.
Now I get:
error: failed to run custom build command for `backtrace-sys v0.1.27`
Caused by:
— stdout
command did not execute successfully: "/usr/bin/cargo" "build" "–target" "x86_64-unknown-linux-gnu" "-j" "1" "–release" "–frozen" "–features" "panic-unwind backtrace profiler" "–manifest-path" "/build/rust/src/rustc-1.37.0-src/src/libstd/Cargo.toml" "–message-format" "json"
expected success, got: exit code: 101
', /build/rust/src/rustc-1.37.0-src/vendor/cc/src/lib.rs:2398:5
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
I'm personally quite fed up with the quality and documentation of this compiler..
cargo:warning=cc1: sorry, unimplemented: 64-bit mode not compiled in
Does this mean that the architecture triplet is wrong?
Indeed. Fixed config.toml, which was completely wrong ([build] had a amd64 target,
building for two architectures instead one (i686)..
pentium4 went through, trying now the sed trick above on the i686 version..
There is no documentation how to use x.py properly, what the build does, what
the bootstrapping does. And life-patching of typenum is just the really last
straw (currently failing)..
Currently blocking:
- librsvg2 on i686 (rust-bin generates SSE2-code)
- firefox, thunderbird and friends on i686
- some random software on i686 like newsboat
We should try to understand x.py
https://github.com/rust-lang/rust/blob/master/src/bootstrap/README.md
To me it looks like we can have a PKGBUILD calling each stage individually and do
the necessary patching in-between.
Ok, I see several issues here:
rustc –target i686-unknown-linux-gnu –print cfg
says:
target_feature="sse"
target_feature="sse2"
rustc –target i586-unknown-linux-gnu –print cfg
has no SSE/SSE2, so we pick:
- i686-unknown-linux-gnu for our pentium4 and
- i586-unknown-linux-gnu for our i486 and i686
see also some interesting notes in:
- https://github.com/rust-lang/rust/issues/54740 - https://internals.rust-lang.org/t/is-pentium4-still-an-appropriate-base-cpu-for-i686/7353/6
The current config.toml.patch doesn't apply correctly and silently fails:
This needs proper treatment in the build scripts, as we cannot continue building
if patches apply partially!
Now I get the same typenum error also in stage2 of cargo on pentium4.
Trying the stage 2 –keep-stage 1 trick..
Some internal documentation on x.py:
https://rust-lang.github.io/rustc-guide/how-to-build-and-run.html
Cool, so the conflicting consts.rs of typenum appears out of the blue in the middle of a stage.
So this multi-layered building will also not work.
Trying an inotifywait approach watching for consts.rs to appear and calling a sed on it then:
The inotify-trick helped to rebuild 1.38 for pentium4.
So, rust 1.38 can only be built with rust 1.37, not with 1.38 (rebuilding itself),
see:
https://github.com/rust-lang/rust/issues/63911
This means, having a rust package building rust works, if you do it once,
otherwise I would suggest to upstream to have a rust137 and build rust138
which provides rust, so the build can be done more than once (especially
automatically).
When I use rust-bin for 1.37 I cannot build 1.38 again for i686 (out of
memory). This one I'm trying to tackle with debug_level=0 (which seems
to help). Didn't have this problem with 'rust' 1.37.0 on pentium4 for
rebuilding 1.38.0, so maybe rust-bin has some bad internal properties?
inotifywait and sed is in the middle of patching the consts.rs file, so you get
half of a source-file:
Maybe some mandatory file locking helps?
Otherwise, I start considering a "fuse-patching" pseudo-filesystem.
flock doesn't help, the file is now locked, but rust sees it as a sequence of \0.
The following works: wait for inotify event close_write on file consts.rs and patch
it then.
Kill the watcher (which also kills inotifywait).
Now I can rebuild rust 1.38 from 1.37, but I still have problems rebuilding 1.38
with an 1.38 compiler (*sigh*).
As we have to assume that rust 1.37 and 1.36 are broken, let's bootstrap again a
rust 1.38 from rust-bin 1.37.
Now someting hangs in the middle..
upstream fixed the boostrapping 1.38 with 1.38 issue (seems to be just some
superflous unsafe directives):
Trying again to rebuild 1.38 with 1.38 (both for i686 and pentium4) against my bootstrapped
1.38 version. When this works, I'll build official version in the regular way..
This seems to be a new trend. I don't like it, as it makes patching really hard..
i686 1.38 rebuild of 1.38 results in:
no error messages, exit code 101 means what exactly?