Re: [blfs-dev] llvm-9.0.1 seems to break rustc-1.37.0
On Tue, Dec 24, 2019 at 04:59:53PM -0600, Douglas R. Reno via blfs-dev wrote: > > On 12/24/19 3:14 PM, Ken Moffat via blfs-dev wrote: > > On Mon, Dec 23, 2019 at 10:09:17PM +, Ken Moffat via blfs-dev wrote: > > > Arch have a patch for thunderbird, described as for rustc-1.39.0. > > > https://git.archlinux.org/svntogit/packages.git/plain/trunk/thunderbird-rust-1.39.patch?h=packages/thunderbird > > > > > There is also thunderbird beta in arch (currently 72.0b2 - > > thunderbird tracks firefox major releases, but non-ESR are only > > ever beta, although a comment suggests that might have changed) : > > https://aur.archlinux.org/packages/thunderbird-beta/?setlang=en > > > > I'm mentioning this because at the moment it is noted as broken by > > rustc-1.40.0. > > > > ĸen > > Good evening guys, > > Since we have LLVM-9 in the book now (since Sunday) and I had to leave the > house for a bit today, I ran a build of rustc-1.37 with the following > commit: > > https://github.com/rust-lang/rust/commit/04304fcd16e40c936dc5ba71c9ac3c445597f8bb > > I got past the LLVM build error, but now I have another one: > > Copying stage1 std from stage1 (x86_64-unknown-linux-gnu -> > x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu) > Building stage1 test artifacts (x86_64-unknown-linux-gnu -> > x86_64-unknown-linux-gnu) > Compiling proc_macro v0.0.0 (/sources/rustc-1.37.0-src/src/libproc_macro) > error: Could not compile `proc_macro`. > > Caused by: > process didn't exit successfully: > `/sources/rustc-1.37.0-src/build/bootstrap/debug/rustc --edition=2018 > --crate-name proc_macro src/libproc_macro/lib.rs --color always > --error-format json --crate-type lib --emit=dep-info,metadata,link -C > opt-level=2 -C metadata=b2a98432edc77a2f -C extra-filename=-b2a98432edc77a2f > --out-dir > /sources/rustc-1.37.0-src/build/x86_64-unknown-linux-gnu/stage1-test/x86_64-unknown-linux-gnu/release/deps > --target x86_64-unknown-linux-gnu -L > dependency=/sources/rustc-1.37.0-src/build/x86_64-unknown-linux-gnu/stage1-test/x86_64-unknown-linux-gnu/release/deps > -L > dependency=/sources/rustc-1.37.0-src/build/x86_64-unknown-linux-gnu/stage1-test/release/deps > -C link-args=-lffi` (signal: 11, SIGSEGV: invalid memory reference) > command did not execute successfully: > "/sources/rustc-1.37.0-src/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" > "build" "--target" "x86_64-unknown-linux-gnu" "-j" "1" "--release" > "--manifest-path" "/sources/rustc-1.37.0-src/src/libtest/Cargo.toml" > "--message-format" "json" > expected success, got: exit code: 101 > failed to run: /sources/rustc-1.37.0-src/build/bootstrap/debug/bootstrap > build --exclude src/tools/miri > Build completed unsuccessfully in 0:00:05 > > I don't think that I"m doing anything differently from the book. I copied > and pasted the stuff in there. > > One of the things that I dislike about Mozilla is that they expect the > version of rustc to be the same across the entire lifecycle of an ESR > release. From my interpretation of this thread, I think we only have a few > options: > I think that expectation is probably common in "enterprise" distros, it's just unusual that we happen to explicitly use such versions (thunderbird, and for convenience firefox). > 1 - Revert LLVM to 8.0.1 > > 2 - Force rustc to use it's internal LLVM version > > 3 - Backport the fix for rustc and LLVM, and then somehow fix the problems > with proc_macro > > 4 - Update rustc, and then patch Thunderbird and Firefox (and potentially > other consumers) > > I think the easiest will be number 2. I don't think we want to stay with > LLVM-8 for the rest of this release cycle at least. Eventually we will > encounter updates to Mesa and the like that may need a later LLVM. > Backporting that fix is the second easiest solution, but we might have a > chicken and egg problem with other rust consumers. IIRC the primary reason > why we had to upgrade rustc last time was due to librsvg. > > - Doug > No. 2 certainly sounds easier. The problem with no.4 is identifying the remaining fix(es). I can't say that I like no.2, and for my own usage (avoid llvm if possible, because gcc tends to have better security options in its available flags) llvm-8.0.1 is fine. But whether that is true in mesa releases before we release 9.1 is unknown. The big problem with rust is its lack of stability - other compilers deprecate things and then often remove them in a release or two, but that typically means 6 months or a year - with rust two releases is only about 12 weeks. BTW - since I've noted the time : Happy Xmas everyone. ĸen -- We've all got both light and dark inside of us. What matters is the part we choose to act on. -- Sirius Black -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] llvm-9.0.1 seems to break rustc-1.37.0
On 12/24/19 3:14 PM, Ken Moffat via blfs-dev wrote: On Mon, Dec 23, 2019 at 10:09:17PM +, Ken Moffat via blfs-dev wrote: Arch have a patch for thunderbird, described as for rustc-1.39.0. https://git.archlinux.org/svntogit/packages.git/plain/trunk/thunderbird-rust-1.39.patch?h=packages/thunderbird There is also thunderbird beta in arch (currently 72.0b2 - thunderbird tracks firefox major releases, but non-ESR are only ever beta, although a comment suggests that might have changed) : https://aur.archlinux.org/packages/thunderbird-beta/?setlang=en I'm mentioning this because at the moment it is noted as broken by rustc-1.40.0. ĸen Good evening guys, Since we have LLVM-9 in the book now (since Sunday) and I had to leave the house for a bit today, I ran a build of rustc-1.37 with the following commit: https://github.com/rust-lang/rust/commit/04304fcd16e40c936dc5ba71c9ac3c445597f8bb I got past the LLVM build error, but now I have another one: Copying stage1 std from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu) Building stage1 test artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu) Compiling proc_macro v0.0.0 (/sources/rustc-1.37.0-src/src/libproc_macro) error: Could not compile `proc_macro`. Caused by: process didn't exit successfully: `/sources/rustc-1.37.0-src/build/bootstrap/debug/rustc --edition=2018 --crate-name proc_macro src/libproc_macro/lib.rs --color always --error-format json --crate-type lib --emit=dep-info,metadata,link -C opt-level=2 -C metadata=b2a98432edc77a2f -C extra-filename=-b2a98432edc77a2f --out-dir /sources/rustc-1.37.0-src/build/x86_64-unknown-linux-gnu/stage1-test/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -L dependency=/sources/rustc-1.37.0-src/build/x86_64-unknown-linux-gnu/stage1-test/x86_64-unknown-linux-gnu/release/deps -L dependency=/sources/rustc-1.37.0-src/build/x86_64-unknown-linux-gnu/stage1-test/release/deps -C link-args=-lffi` (signal: 11, SIGSEGV: invalid memory reference) command did not execute successfully: "/sources/rustc-1.37.0-src/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-j" "1" "--release" "--manifest-path" "/sources/rustc-1.37.0-src/src/libtest/Cargo.toml" "--message-format" "json" expected success, got: exit code: 101 failed to run: /sources/rustc-1.37.0-src/build/bootstrap/debug/bootstrap build --exclude src/tools/miri Build completed unsuccessfully in 0:00:05 I don't think that I"m doing anything differently from the book. I copied and pasted the stuff in there. One of the things that I dislike about Mozilla is that they expect the version of rustc to be the same across the entire lifecycle of an ESR release. From my interpretation of this thread, I think we only have a few options: 1 - Revert LLVM to 8.0.1 2 - Force rustc to use it's internal LLVM version 3 - Backport the fix for rustc and LLVM, and then somehow fix the problems with proc_macro 4 - Update rustc, and then patch Thunderbird and Firefox (and potentially other consumers) I think the easiest will be number 2. I don't think we want to stay with LLVM-8 for the rest of this release cycle at least. Eventually we will encounter updates to Mesa and the like that may need a later LLVM. Backporting that fix is the second easiest solution, but we might have a chicken and egg problem with other rust consumers. IIRC the primary reason why we had to upgrade rustc last time was due to librsvg. - Doug -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] llvm-9.0.1 seems to break rustc-1.37.0
On Mon, Dec 23, 2019 at 10:09:17PM +, Ken Moffat via blfs-dev wrote: > Arch have a patch for thunderbird, described as for rustc-1.39.0. > https://git.archlinux.org/svntogit/packages.git/plain/trunk/thunderbird-rust-1.39.patch?h=packages/thunderbird > There is also thunderbird beta in arch (currently 72.0b2 - thunderbird tracks firefox major releases, but non-ESR are only ever beta, although a comment suggests that might have changed) : https://aur.archlinux.org/packages/thunderbird-beta/?setlang=en I'm mentioning this because at the moment it is noted as broken by rustc-1.40.0. ĸen -- We've all got both light and dark inside of us. What matters is the part we choose to act on. -- Sirius Black -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] llvm-9.0.1 seems to break rustc-1.37.0
On Tue, Dec 24, 2019 at 09:14:30AM +0100, Pierre Labastie via blfs-dev wrote:
> Le 23/12/2019 à 23:09, Ken Moffat via blfs-dev a écrit :
> > On Mon, Dec 23, 2019 at 09:08:48PM +, Ken Moffat via blfs-dev wrote:
> >> On Mon, Dec 23, 2019 at 09:33:48PM +0100, Pierre Labastie via blfs-dev
> >> wrote:
> >>>
> >>> Actually, I've found this patch:
> >>> https://github.com/rust-lang/rust/commit/04304fcd16e40c936dc5ba71c9ac3c445597f8bb
> >>> which seems to be included into 1.38 and following... Time to update rust?
> >>>
> >>> Pierre
> >>>
> >> From memory, the last time I tried to use 1.38 on thunderbird it did
> >> not build. I think that was 68.2 or 68.1, but the nature of
> >> esr releases is that little changes. Similarly, firefox will
> >> probably break.
> >>
Confirmed that firefox-68.3.0 breaks with rustc-1.40.0 (after _lots_
of warnings about deprecated items:
8:34.57 make[4]: Entering directory
'/scratch/working/firefox-68.3.0/firefox-build-dir/netwerk/ipc'
8:34.57 mkdir -p '.deps/'
8:34.57 make[4]: Leaving directory
'/scratch/working/firefox-68.3.0/firefox-build-dir/netwerk/ipc'
8:34.89 error[E0204]: the trait `Copy` may not be implemented for this type
8:34.89 -->
/scratch/working/firefox-68.3.0/firefox-build-dir/x86_64-unknown-linux-gnu/release/build/style-113c0dfcea0c84d0/out/gecko/structs.rs:4521:29
8:34.89 |
8:34.89 4521 | #[derive(Debug, Copy, Clone)]
8:34.89 |
8:34.89 4522 | pub struct URLParams_Param {
8:34.89 4523 | pub mKey: ::gecko_bindings::structs::nsString,
8:34.89 | -
this field does not implement `Copy`
8:34.89 4524 | pub mValue: ::gecko_bindings::structs::nsString,
8:34.89 | ---
this field does not implement `Copy`
Loads more, and eventually
8:35.28 error[E0119]: conflicting implementations of trait `std::clone::Clone`
for type `gecko_bindings::structs::root::mozilla::GeckoXUL`:
and eventually
8:35.40 error: aborting due to 60 previous errors
8:35.40 Some errors have detailed explanations: E0119, E0204.
Since I have no interest in monitoring detailed changes in newer
firefoxes now that they are moving towards a 4-week release
schedule, I have no interest in using llvm-9.0.1.
ĸen
--
We've all got both light and dark inside of us.
What matters is the part we choose to act on.
-- Sirius Black
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-dev] KDE and Qt-5.14
Hi, As reported on support, some of KDE frameworks are broken by QT-5.14. I've found upstream fixes, so I am now sure that the fixes are needed. They can be done as sed. I think we should also apply the patch reported by "spiky" on -support to Qt-5.14. I have tested that it applies and builds OK, but I have not tested the cursor yet (need to build the desktop first)... I am not sure how much I can do in the next few days, since I go and visit my family for Christmas. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] llvm-9.0.1 seems to break rustc-1.37.0
Le 23/12/2019 à 23:09, Ken Moffat via blfs-dev a écrit : > On Mon, Dec 23, 2019 at 09:08:48PM +, Ken Moffat via blfs-dev wrote: >> On Mon, Dec 23, 2019 at 09:33:48PM +0100, Pierre Labastie via blfs-dev wrote: >>> Hi >>> Looks like there has been some API change in llvm, leading to: >>> --- >>> error: failed to run custom build command for `rustc_llvm v0.0.0 >>> (/sources/rust/rustc-1.37.0-src/src/librustc_llvm)` >>> >>> Caused by: >>> process didn't exit successfully: >>> `/sources/rust/rustc-1.37.0-src/build/x86_64-unknown-linux-gnu/stage0-codegen/release/build/rustc_llvm-1acb7c1e485f87ef/build-script-build` >>> (exit code: 101) >>> --- stdout >> [...] >>> I think the problem is "error: too few arguments to function...", which >>> looks >>> like an API change. >>> >>> Actually, I've found this patch: >>> https://github.com/rust-lang/rust/commit/04304fcd16e40c936dc5ba71c9ac3c445597f8bb >>> which seems to be included into 1.38 and following... Time to update rust? >>> >>> Pierre >>> >> From memory, the last time I tried to use 1.38 on thunderbird it did >> not build. I think that was 68.2 or 68.1, but the nature of >> esr releases is that little changes. Similarly, firefox will >> probably break. >> > Arch have a patch for thunderbird, described as for rustc-1.39.0. > https://git.archlinux.org/svntogit/packages.git/plain/trunk/thunderbird-rust-1.39.patch?h=packages/thunderbird > > The first hunk looks pretty hairy, json format... I think one md5sum is changed, so diff writes the whole line. > I doubt that there is a similar > patch for firefox-68. If people want to use the latest llvm then > they'll have to use a newer firefox with newer rust (details of > firefox build changes for versions newer than 68-esr are in the > wiki). > FWIIW, I've built rustc-1.40.0 with current book instructions, and librsvg built OK. Not tried cbindgen, nor firefox or thunderbird. I am rather interested in building kde, which is broken by qt-5.14, ATM. Will try the other packages later. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
