[blfs-dev] shared-mime-info need make -j1
Hello, I had two build failures compiling shared-mime-info while ALFS was set to use make -j5. Fixing the build script to use make -j1 fixes the build. Alain -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On 04/14/2018 11:05 PM, Bruce Dubbs wrote: On 04/14/2018 08:22 PM, Ken Moffat wrote: On Sat, Apr 14, 2018 at 10:50:11PM +0100, Ken Moffat wrote: On Sat, Apr 14, 2018 at 10:26:22PM +0200, Pierre Labastie wrote: Given that one of the old issues I found suggested that the problem only happened with static libs, and that libffi is being pulled in by libclang.so when built my way, I suspect this is the cause of Bruce's failure as well as Pierre's. So, I suggest rebuilding llvm with -DLLVM_LINK_LLVM_DYLIB=ON and confirming that rustc will then build with the config.toml that is in the book. If that works, as well as changing llvm the rust build needs to mention "clang from llvm-6.0 (built with -DLLVM_LINK_LLVM_DYLIB=ON)". Will do that, and have results in the morning. Didn't take that long. I rebuilt llvm, but still get a failure: Compiling rustc_llvm v0.0.0 (file:///tmp/rustc-test/rustc-1.25.0-src/src/librustc_llvm) Finished release [optimized] target(s) in 88.40 secs Assembling stage1 compiler (x86_64-unknown-linux-gnu) Building stage1 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu) error: process didn't exit successfully: `/tmp/rustc-test/rustc-1.25.0-src/build/bootstrap/debug/rustc -vV` (exit code: 101) --- stdout rustc 1.25.0 binary: rustc commit-hash: unknown commit-date: unknown host: x86_64-unknown-linux-gnu release: 1.25.0 --- stderr error: couldn't load codegen backend "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so": "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so: undefined symbol: ffi_type_float" thread 'main' panicked at 'command did not execute successfully: "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-j" "12" "--release" "--features" "panic-unwind jemalloc backtrace" "--manifest-path" "/tmp/rustc-test/rustc-1.25.0-src/src/libstd/Cargo.toml" "--message-format" "json" expected success, got: exit code: 101', bootstrap/compile.rs:1060:9 note: Run with `RUST_BACKTRACE=1` for a backtrace. failed to run: /tmp/rustc-test/rustc-1.25.0-src/build/bootstrap/debug/bootstrap build Build completed unsuccessfully in 0:14:36 876.1 Elapsed Time - rustc-1.25.0-src -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On 04/14/2018 08:22 PM, Ken Moffat wrote: On Sat, Apr 14, 2018 at 10:50:11PM +0100, Ken Moffat wrote: On Sat, Apr 14, 2018 at 10:26:22PM +0200, Pierre Labastie wrote: Given that one of the old issues I found suggested that the problem only happened with static libs, and that libffi is being pulled in by libclang.so when built my way, I suspect this is the cause of Bruce's failure as well as Pierre's. So, I suggest rebuilding llvm with -DLLVM_LINK_LLVM_DYLIB=ON and confirming that rustc will then build with the config.toml that is in the book. If that works, as well as changing llvm the rust build needs to mention "clang from llvm-6.0 (built with -DLLVM_LINK_LLVM_DYLIB=ON)". Will do that, and have results in the morning. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On Sun, Apr 15, 2018 at 02:22:13AM +0100, Ken Moffat wrote: > > for the binaries, a lot of differences, mostly in size. > Attached as bindiff > I knew I'd forget. Attached now. -- In my seventh decade astride this planet, and as my own cells degrade, there are some things I cannot do now: skydiving, marathon running, calculus. I couldn't do them in my 20s either, so no big loss. -- Derek Smalls, formerly of Spinal Tap --- ONLYBIN 2018-04-15 01:55:09.045724116 +0100 +++ LINKBIN 2018-04-15 01:55:36.411731966 +0100 @@ -1,70 +1,70 @@ -38449680 bugpoint -23974352 c-index-test +450528 bugpoint +19913640 c-index-test 9 clang -> clang-6.0 5 clang++ -> clang -78155776 clang-6.0 -52740152 clang-check +38385304 clang-6.0 +26335792 clang-check 5 clang-cl -> clang 5 clang-cpp -> clang -2350072 clang-format -20694800 clang-func-mapping -26105496 clang-import-test -3249920 clang-offload-bundler -22747784 clang-refactor -21584336 clang-rename +1954608 clang-format +19521848 clang-func-mapping +22662728 clang-import-test +69568 clang-offload-bundler +21579248 clang-refactor +20409440 clang-rename 21791 git-clang-format -36919360 llc -27256848 lli -9990016 llvm-ar -2885792 llvm-as -316320 llvm-bcanalyzer -2589976 llvm-cat -11973920 llvm-cfi-verify -196600 llvm-config -3544736 llvm-cov -25986584 llvm-c-test -2998840 llvm-cvtres -2992104 llvm-cxxdump -326112 llvm-cxxfilt -2427584 llvm-diff -2046000 llvm-dis +195064 llc +490008 lli +85496 llvm-ar +25968 llvm-as +80368 llvm-bcanalyzer +32856 llvm-cat +125256 llvm-cfi-verify +71432 llvm-config +340360 llvm-cov +131592 llvm-c-test +45016 llvm-cvtres +88960 llvm-cxxdump +33304 llvm-cxxfilt +97792 llvm-diff +38384 llvm-dis 7 llvm-dlltool -> llvm-ar -26241528 llvm-dsymutil -8724632 llvm-dwarfdump -25607632 llvm-dwp -3753488 llvm-extract +345968 llvm-dsymutil +120680 llvm-dwarfdump +110136 llvm-dwp +53320 llvm-extract 7 llvm-lib -> llvm-ar -3553312 llvm-link -33127080 llvm-lto -35172528 llvm-lto2 -9569064 llvm-mc -245176 llvm-mcmarkup -2730584 llvm-modextract -279936 llvm-mt -10065240 llvm-nm -3202168 llvm-objcopy -10956784 llvm-objdump -432120 llvm-opt-report -5414616 llvm-pdbutil -1384128 llvm-profdata +72024 llvm-link +217792 llvm-lto +177176 llvm-lto2 +105808 llvm-mc +26064 llvm-mcmarkup +26584 llvm-modextract +30664 llvm-mt +137440 llvm-nm +298376 llvm-objcopy +538112 llvm-objdump +68912 llvm-opt-report +1106168 llvm-pdbutil +138408 llvm-profdata 7 llvm-ranlib -> llvm-ar -409160 llvm-rc +189872 llvm-rc 12 llvm-readelf -> llvm-readobj -4304624 llvm-readobj -8577904 llvm-rtdyld -2986632 llvm-size -3313400 llvm-split -3604088 llvm-stress -243808 llvm-strings -3427776 llvm-symbolizer +964056 llvm-readobj +95768 llvm-rtdyld +95872 llvm-size +21376 llvm-split +84648 llvm-stress +38416 llvm-strings +58488 llvm-symbolizer 2694128 llvm-tblgen -3889168 llvm-xray -4743224 obj2yaml -39672280 opt -10468400 sancov -3358304 sanstats +463880 llvm-xray +318096 obj2yaml +407424 opt +132504 sancov +29184 sanstats 53444 scan-build 4504 scan-view -3207656 verify-uselistorder -1611968 yaml2obj +69960 verify-uselistorder +168088 yaml2obj -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On Sat, Apr 14, 2018 at 10:50:11PM +0100, Ken Moffat wrote:
> On Sat, Apr 14, 2018 at 10:26:22PM +0200, Pierre Labastie wrote:
> >
> > thread 'main' panicked at 'command did not execute successfully:
> > "/usr/bin/llvm-config" "--link-shared" "--libs" "--system-libs" "asmparser"
> > "bitreader" "bitwriter" "instrumentation" "interpreter" "ipo" "linker" "lto"
> > "mcjit" "x86"
[...]
> >
> > The book uses the LLVM_BUILD_LLVM_DYLIB option.
> >
> Indeed it does, but I see that I also use -DLLVM_LINK_LLVM_DYLIB=ON.
> I assume that might have been in the book at some time, but it's
> what I've been using without obvious problems.
> Sorry to offer that different suggestion after you have gone to bed.
>
> I'll try a couple of manual DESTDIR llvm builds to confirm what gets
> installed, including clang and compiler-rt (does anybody know of
> anything that actually needs compiler-rt, I don't bother building it
> on all machines and so far nothing seems to need it ?).
>
Now completed, the book's version DESTDIR'd to BUILDONLY, the one
with added -DLLVM_LINK_LLVM_DYLIB=ON to BUILDLINK.
ken@origin /scratch/ken $du -sh BUILD*
588MBUILDLINK
1.2GBUILDONLY
TRying to get only the important things into listings (size, name,
and symlink details) so that I can diff them:
ls -l BUILDONLY/usr/bin | awk '{ print $5 " " $9 " " $10 " " $11 }' >ONLYBIN
ditto for BUILDLINK to LINKBIN
similarly for /usr/lib to ONLYLIB and LINKLIB
for the binaries, a lot of differences, mostly in size.
Attached as bindiff
Comparing ldd output for the first file, bugpoint, the BUILDONLY
version (i.e. what is in the book) lacks
libLLVM-6.0.so => /scratch/ken/BUILDLINK/usr/bin/../lib/libLLVM-6.0.so
(0x7f20c8697000)
libffi.so.6 => /usr/lib/libffi.so.6 (0x7f20c7586000)
libxml2.so.2 => /usr/lib/libxml2.so.2 (0x7f20c6987000)
libicui18n.so.60 => /usr/lib/libicui18n.so.60 (0x7f20c64d9000)
libicuuc.so.60 => /usr/lib/libicuuc.so.60 (0x7f20c611b000)
libicudata.so.60 => /usr/lib/libicudata.so.60 (0x7f20c4573000)
liblzma.so.5 => /lib/liblzma.so.5 (0x7f20c434d000)
Diffing the contents of /usr/lib (but not its subdirectories) only
shows differences in size for libclang.so.6.0 and libLTO.so.6.0.0
Comparing the ldd output for libclang.so.6.0 shows a similar
difference, i.e. it pulls in libLLVM, libffi, libxml2, libicu*,
liblzma.
Given that one of the old issues I found suggested that the problem
only happened with static libs, and that libffi is being pulled in
by libclang.so when built my way, I suspect this is the cause of
Bruce's failure as well as Pierre's.
So, I suggest rebuilding llvm with -DLLVM_LINK_LLVM_DYLIB=ON and
confirming that rustc will then build with the config.toml that is
in the book.
If that works, as well as changing llvm the rust build needs to
mention "clang from llvm-6.0 (built with
-DLLVM_LINK_LLVM_DYLIB=ON)".
NB I haven't built the docs or run the tests, so I don't have a view
on the space used by llvm built like this, except that it will be
smaller. I blew away the initial source from building like the
book, but building my way the source is 1.7GB (1740 MB) and the
DESTDIR is 588 MB (2.3 GB). Interestingly, for the book's build I'm
at 1740+1142 (2.8 GB).
ĸen
--
In my seventh decade astride this planet, and as my own cells degrade,
there are some things I cannot do now: skydiving, marathon running,
calculus. I couldn't do them in my 20s either, so no big loss.
-- Derek Smalls, formerly of Spinal Tap
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On Sat, Apr 14, 2018 at 11:35:56AM -0500, Bruce Dubbs wrote: > On 04/14/2018 11:20 AM, Ken Moffat wrote: > > On Fri, Apr 13, 2018 at 11:38:26PM -0500, Bruce Dubbs wrote: > > > > There was a suggestion from several years ago that this used to > > happen if _static_ llvm libs were used. Latest issue was > > https://github.com/rust-lang/rust/issues/39880 but that should have > > been fixed. > > I have not removed the static clang libraries. > > > I don't know why I didn't get the libffi problem (building > > on 8.2 and newer). > > I don't know if it makes a difference, but I have: > > $ ls -l /usr/lib/clang/* -d > drwxr-xr-x 4 root root 4096 Feb 18 13:34 /usr/lib/clang/5.0.1 > drwxr-xr-x 4 root root 4096 Mar 26 17:21 /usr/lib/clang/6.0.0 > I have similar. And on investigation I have not hidden the static libs (maybe I should, just to see what other pain I can get from rust) - they are a bit further down than I care about (usually only static libs in /usr/lib or in /opt/*/lib for qt and kde). Will reply to my previous post after doing the two DESTDIR installs, but I suspect that might be a separate issue. ĸen -- In my seventh decade astride this planet, and as my own cells degrade, there are some things I cannot do now: skydiving, marathon running, calculus. I couldn't do them in my 20s either, so no big loss. -- Derek Smalls, formerly of Spinal Tap -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On Sat, Apr 14, 2018 at 10:26:22PM +0200, Pierre Labastie wrote: > > >> > >> Do we need to adjust the book's instructions? > >> > > > > I'd say not before understanding what is going on... Let me try building > > rust > > with the new instructions, after installing llvm 6, and removing completely > > llvm 5 (using porg). > > > > And then... Another error on my side: > - > [...] > cargo:rustc-link-search=native=/sources/rust/rustc-1.25.0-src/build/x86_64-unkno > wn-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/build/rustc_llvm-7878 > f9d37a1306fb/out > > --- stderr > llvm-config: error: missing: /usr/lib/libLLVMDemangle.so > llvm-config: error: missing: /usr/lib/libLLVMSupport.so [...] > [... fifty so lines like that ...] > llvm-config: error: missing: /usr/lib/libLLVMX86AsmParser.so > llvm-config: error: missing: /usr/lib/libLLVMX86Disassembler.so > thread 'main' panicked at 'command did not execute successfully: > "/usr/bin/llvm-config" "--link-shared" "--libs" "--system-libs" "asmparser" > "bitreader" "bitwriter" "instrumentation" "interpreter" "ipo" "linker" "lto" > "mcjit" "x86" > --- > And indeed, running the command: > --- > $ llvm-config --link-shared --libs > --- > returns the same list of errors as above, while > --- > $ llvm-config --libs > --- > returns a bunch of static libraries without errors. > > I think there is a switch for building shared libraries in llvm. The book was > using it at a time, but there were problems with mesa IIRC. > > The switch is -DBUILD_SHARED_LIBS=ON, and the documentation still says: > ``BUILD_SHARED_LIBS is only recommended for use by LLVM developers. If you > want to build LLVM as a shared library, you should use the > LLVM_BUILD_LLVM_DYLIB option.'' > > The book uses the LLVM_BUILD_LLVM_DYLIB option. > Indeed it does, but I see that I also use -DLLVM_LINK_LLVM_DYLIB=ON. I assume that might have been in the book at some time, but it's what I've been using without obvious problems. This is my only machine which currently has 6.0 (5.0.1 seems to be good enough) and for the above commands I get: ken@origin /sources/scripts/lfs-dev/git $llvm-config --version 6.0.0 ken@origin /sources/scripts/lfs-dev/git $llvm-config --libs -lLLVM-6.0 ken@origin /sources/scripts/lfs-dev/git $llvm-config --link-shared --libs -lLLVM-6.0 I very rarely remove the static libs, I just rename them so that I have to take special measures to make them available (needed for e.g. some of kde). I have ls -l /usr/lib/libLLVM* lrwxrwxrwx 1 root root 14 Mar 28 04:26 /usr/lib/libLLVM-5.0.1.so -> libLLVM-5.0.so -rwxr-xr-x 1 root root 45474200 Mar 28 04:21 /usr/lib/libLLVM-5.0.so lrwxrwxrwx 1 root root 14 Apr 10 00:56 /usr/lib/libLLVM-6.0.0.so -> libLLVM-6.0.so -rwxr-xr-x 1 root root 49620320 Apr 10 00:53 /usr/lib/libLLVM-6.0.so -rw-r--r-- 1 root root 812692 Apr 10 00:29 /usr/lib/libLLVMAMDGPUAsmParser.a.hidden -rw-r--r-- 1 root root 320266 Apr 10 00:29 /usr/lib/libLLVMAMDGPUAsmPrinter.a.hidden [...] -rw-r--r-- 1 root root 182332 Apr 10 00:12 /usr/lib/libLLVMDemangle.a.hidden [...] lrwxrwxrwx 1 root root 14 Apr 10 00:56 /usr/lib/libLLVM.so -> libLLVM-6.0.so -rw-r--r-- 1 root root 2904212 Apr 10 00:13 /usr/lib/libLLVMSupport.a.hidden [...] -rw-r--r-- 1 root root 1053706 Apr 10 00:51 /usr/lib/libLLVMX86AsmParser.a.hidden [...] -rw-r--r-- 1 root root 1503248 Apr 10 00:51 /usr/lib/libLLVMX86Disassembler.a.hidden So, I think -DLLVM_LINK_LLVM_DYLIB=ON is probably the difference. > So: three persons; three different outcomes... > > Let me rebuild llvm with -DBUILD_SHARED_LIBS=ON. I'll give the results > tomorrow (my time), since llvm+rustc build time ~ 3 hours, and I'll be > sleeping when it ends. > > Pierre > Sorry to offer that different suggestion after you have gone to bed. I'll try a couple of manual DESTDIR llvm builds to confirm what gets installed, including clang and compiler-rt (does anybody know of anything that actually needs compiler-rt, I don't bother building it on all machines and so far nothing seems to need it ?). ĸen -- In my seventh decade astride this planet, and as my own cells degrade, there are some things I cannot do now: skydiving, marathon running, calculus. I couldn't do them in my 20s either, so no big loss. -- Derek Smalls, formerly of Spinal Tap -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
> So: three persons; three different outcomes...
Most likely 4 differents outcome by tomorrow, I'll be getting a 2010 model Mac
Pro, with, I think, a
6 core nehalem as a minimum which will heat the place compiling software under
travis-ci (https://gi
thub.com/travis-ci/travis-ci ) or something similar. It'll be dedicated to
{A,B,}LFS only and
compile 24/7 unattended.
Alain
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On 14/04/2018 19:18, Pierre Labastie wrote: > On 14/04/2018 18:18, Bruce Dubbs wrote: >> On 04/13/2018 11:38 PM, Bruce Dubbs wrote: >>> Using the new instructions in the book O could not get rustc to build. I was >>> getting: >>> >>> --- stderr >>> error: couldn't load codegen backend >>> "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so": >>> "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so: >>> undefined symbol: ffi_type_float" >>> >>> === >>> >>> Note: ffi_type_float is defined as a symbol in libffi.so. >>> >>> >> >> Do we need to adjust the book's instructions? >> > > I'd say not before understanding what is going on... Let me try building rust > with the new instructions, after installing llvm 6, and removing completely > llvm 5 (using porg). > And then... Another error on my side: - [...] cargo:rustc-link-search=native=/sources/rust/rustc-1.25.0-src/build/x86_64-unkno wn-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/build/rustc_llvm-7878 f9d37a1306fb/out --- stderr llvm-config: error: missing: /usr/lib/libLLVMDemangle.so llvm-config: error: missing: /usr/lib/libLLVMSupport.so llvm-config: error: missing: /usr/lib/libLLVMBinaryFormat.so llvm-config: error: missing: /usr/lib/libLLVMCore.so llvm-config: error: missing: /usr/lib/libLLVMAsmParser.so llvm-config: error: missing: /usr/lib/libLLVMBitReader.so llvm-config: error: missing: /usr/lib/libLLVMMC.so llvm-config: error: missing: /usr/lib/libLLVMMCParser.so llvm-config: error: missing: /usr/lib/libLLVMObject.so [... fifty so lines like that ...] llvm-config: error: missing: /usr/lib/libLLVMX86AsmParser.so llvm-config: error: missing: /usr/lib/libLLVMX86Disassembler.so thread 'main' panicked at 'command did not execute successfully: "/usr/bin/llvm-config" "--link-shared" "--libs" "--system-libs" "asmparser" "bitreader" "bitwriter" "instrumentation" "interpreter" "ipo" "linker" "lto" "mcjit" "x86" --- And indeed, running the command: --- $ llvm-config --link-shared --libs --- returns the same list of errors as above, while --- $ llvm-config --libs --- returns a bunch of static libraries without errors. I think there is a switch for building shared libraries in llvm. The book was using it at a time, but there were problems with mesa IIRC. The switch is -DBUILD_SHARED_LIBS=ON, and the documentation still says: ``BUILD_SHARED_LIBS is only recommended for use by LLVM developers. If you want to build LLVM as a shared library, you should use the LLVM_BUILD_LLVM_DYLIB option.'' The book uses the LLVM_BUILD_LLVM_DYLIB option. So: three persons; three different outcomes... Let me rebuild llvm with -DBUILD_SHARED_LIBS=ON. I'll give the results tomorrow (my time), since llvm+rustc build time ~ 3 hours, and I'll be sleeping when it ends. 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] rustc-1.25
On 04/14/2018 12:24 PM, Alain Toussaint wrote: Le samedi 14 avril 2018 à 19:18 +0200, Pierre Labastie a écrit : On 14/04/2018 18:18, Bruce Dubbs wrote: On 04/13/2018 11:38 PM, Bruce Dubbs wrote: When I removed the line llvm-config = "/usr/bin/llvm-config" from config.toml, it seem to work (still building, but past the problem area.) The build completed and everything seems OK. I do not know why rustc does not like my version of clang. $ clang --version clang version 6.0.0 (tags/RELEASE_600/final) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin Do we need to adjust the book's instructions? I'd say not before understanding what is going on... Let me try building rust with the new instructions, after installing llvm 6, and removing completely llvm 5 (using porg). Pierre I have a nearly ready made system done with llvm 6 and rust 1.22.1: root [ ~ ]# llvm-config --version 6.0.0 root [ ~ ]# rust rustc rustdocrust-gdb rust-lldb root [ ~ ]# rustc --version rustc 1.22.1 root [ ~ ]# I can try to build rust 1.25 and report back but are there any pitfall of doing so when rust 1.22.1 is installed? That would be helpful. The more people that do this, the more confident we can be with the instructions. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
Le samedi 14 avril 2018 à 19:18 +0200, Pierre Labastie a écrit : > On 14/04/2018 18:18, Bruce Dubbs wrote: > > On 04/13/2018 11:38 PM, Bruce Dubbs wrote: > > > Using the new instructions in the book O could not get rustc to build. I > > > was > > > getting: > > > > > > --- stderr > > > error: couldn't load codegen backend > > > "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64- > > > unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so": > > > "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64- > > > unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so: > > > undefined symbol: ffi_type_float" > > > > > > === > > > > > > Note: ffi_type_float is defined as a symbol in libffi.so. > > > > > > > > > When I removed the line > > > > > > llvm-config = "/usr/bin/llvm-config" > > > > > > from config.toml, it seem to work (still building, but past the problem > > > area.) > > > > The build completed and everything seems OK. I do not know why rustc does > > not > > like my version of clang. > > > > $ clang --version > > clang version 6.0.0 (tags/RELEASE_600/final) > > Target: x86_64-unknown-linux-gnu > > Thread model: posix > > InstalledDir: /usr/bin > > > > Do we need to adjust the book's instructions? > > > > I'd say not before understanding what is going on... Let me try building rust > with the new instructions, after installing llvm 6, and removing completely > llvm 5 (using porg). > > Pierre > I have a nearly ready made system done with llvm 6 and rust 1.22.1: root [ ~ ]# llvm-config --version 6.0.0 root [ ~ ]# rust rustc rustdocrust-gdb rust-lldb root [ ~ ]# rustc --version rustc 1.22.1 root [ ~ ]# I can try to build rust 1.25 and report back but are there any pitfall of doing so when rust 1.22.1 is installed? Alain -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On 14/04/2018 18:18, Bruce Dubbs wrote: > On 04/13/2018 11:38 PM, Bruce Dubbs wrote: >> Using the new instructions in the book O could not get rustc to build. I was >> getting: >> >> --- stderr >> error: couldn't load codegen backend >> "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so": >> "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so: >> undefined symbol: ffi_type_float" >> >> === >> >> Note: ffi_type_float is defined as a symbol in libffi.so. >> >> >> When I removed the line >> >> llvm-config = "/usr/bin/llvm-config" >> >> from config.toml, it seem to work (still building, but past the problem >> area.) > > The build completed and everything seems OK. I do not know why rustc does not > like my version of clang. > > $ clang --version > clang version 6.0.0 (tags/RELEASE_600/final) > Target: x86_64-unknown-linux-gnu > Thread model: posix > InstalledDir: /usr/bin > > Do we need to adjust the book's instructions? > I'd say not before understanding what is going on... Let me try building rust with the new instructions, after installing llvm 6, and removing completely llvm 5 (using porg). 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] rustc-1.25
On Sat, Apr 14, 2018 at 11:18:06AM -0500, Bruce Dubbs wrote: > > The build completed and everything seems OK. I do not know why rustc does > not like my version of clang. > > $ clang --version > clang version 6.0.0 (tags/RELEASE_600/final) > Target: x86_64-unknown-linux-gnu > Thread model: posix > InstalledDir: /usr/bin > > Do we need to adjust the book's instructions? > > -- Bruce As for any reported problem, potentially yes. I'm just going out now, I'll take a look later at my newest system to see if I an gain any insights. All that I have found since my previous reply is that the problem is only if system llvm has the -D flag to enable FFI: but I checked my llvm script in git blame and I've been building like that for years. ĸen -- In my seventh decade astride this planet, and as my own cells degrade, there are some things I cannot do now: skydiving, marathon running, calculus. I couldn't do them in my 20s either, so no big loss. -- Derek Smalls, formerly of Spinal Tap -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On 04/14/2018 11:20 AM, Ken Moffat wrote: On Fri, Apr 13, 2018 at 11:38:26PM -0500, Bruce Dubbs wrote: Using the new instructions in the book O could not get rustc to build. I was getting: --- stderr error: couldn't load codegen backend "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so": "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so: undefined symbol: ffi_type_float" === Note: ffi_type_float is defined as a symbol in libffi.so. When I removed the line llvm-config = "/usr/bin/llvm-config" from config.toml, it seem to work (still building, but past the problem area.) With that change, it should be building its shipped llvm. If you have a log, you should see something like: Compiling rustc-main v0.0.0 (file:///scratch/working/rustc-1.25.0-src/src/rustc) Finished release [optimized] target(s) in 458.11 secs Copying stage0 rustc from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu) Building LLVM for x86_64-unknown-linux-gnu running: "cmake" "/scratch/working/rustc-1.25.0-src/src/llvm" "-DLLVM_ENABLE_ASSERTIONS=OFF" "-DLLVM_TARGETS_TO_BUILD=X86" "-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=WebAssembly" "-DLLVM_INCLUDE_EXAMPLES=OFF" "-DLLVM_INCLUDE_TESTS=OFF" "-DLLVM_INCLUDE_DOCS=OFF" "-DLLVM_ENABLE_ZLIB=OFF" "-DWITH_POLLY=OFF" "-DLLVM_ENABLE_TERMINFO=OFF" "-DLLVM_ENABLE_LIBEDIT=OFF" "-DLLVM_PARALLEL_COMPILE_JOBS=4" "-DLLVM_TARGET_ARCH=x86_64" "-DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-unknown-linux-gnu" "-DLLVM_LINK_LLVM_DYLIB=ON" "-DCMAKE_C_COMPILER=cc" "-DCMAKE_CXX_COMPILER=c++" "-DCMAKE_C_FLAGS=-ffunction-sections -fdata-sections -fPIC -march=native -m64" "-DCMAKE_CXX_FLAGS=-ffunction-sections -fdata-sections -fPIC -march=native -m64" "-DCMAKE_INSTALL_PREFIX=/scratch/working/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/llvm" "-DCMAKE_BUILD_TYPE=Release" -- The C compiler identification is GNU 7.3.0 Yes, I have that. I can only find old references on this. I think arch used to have something, but their current build seems to use the shipped llvm (they force ninja, which will only be used by cmake, i.e. building llvm). There was a suggestion from several years ago that this used to happen if _static_ llvm libs were used. Latest issue was https://github.com/rust-lang/rust/issues/39880 but that should have been fixed. I have not removed the static clang libraries. I don't know why I didn't get the libffi problem (building on 8.2 and newer). I don't know if it makes a difference, but I have: $ ls -l /usr/lib/clang/* -d drwxr-xr-x 4 root root 4096 Feb 18 13:34 /usr/lib/clang/5.0.1 drwxr-xr-x 4 root root 4096 Mar 26 17:21 /usr/lib/clang/6.0.0 -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On Fri, Apr 13, 2018 at 11:38:26PM -0500, Bruce Dubbs wrote: > Using the new instructions in the book O could not get rustc to build. I was > getting: > > --- stderr > error: couldn't load codegen backend > "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so": > > "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so: > undefined symbol: ffi_type_float" > > === > > Note: ffi_type_float is defined as a symbol in libffi.so. > > > When I removed the line > > llvm-config = "/usr/bin/llvm-config" > > from config.toml, it seem to work (still building, but past the problem > area.) > With that change, it should be building its shipped llvm. If you have a log, you should see something like: Compiling rustc-main v0.0.0 (file:///scratch/working/rustc-1.25.0-src/src/rustc) Finished release [optimized] target(s) in 458.11 secs Copying stage0 rustc from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu) Building LLVM for x86_64-unknown-linux-gnu running: "cmake" "/scratch/working/rustc-1.25.0-src/src/llvm" "-DLLVM_ENABLE_ASSERTIONS=OFF" "-DLLVM_TARGETS_TO_BUILD=X86" "-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=WebAssembly" "-DLLVM_INCLUDE_EXAMPLES=OFF" "-DLLVM_INCLUDE_TESTS=OFF" "-DLLVM_INCLUDE_DOCS=OFF" "-DLLVM_ENABLE_ZLIB=OFF" "-DWITH_POLLY=OFF" "-DLLVM_ENABLE_TERMINFO=OFF" "-DLLVM_ENABLE_LIBEDIT=OFF" "-DLLVM_PARALLEL_COMPILE_JOBS=4" "-DLLVM_TARGET_ARCH=x86_64" "-DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-unknown-linux-gnu" "-DLLVM_LINK_LLVM_DYLIB=ON" "-DCMAKE_C_COMPILER=cc" "-DCMAKE_CXX_COMPILER=c++" "-DCMAKE_C_FLAGS=-ffunction-sections -fdata-sections -fPIC -march=native -m64" "-DCMAKE_CXX_FLAGS=-ffunction-sections -fdata-sections -fPIC -march=native -m64" "-DCMAKE_INSTALL_PREFIX=/scratch/working/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/llvm" "-DCMAKE_BUILD_TYPE=Release" -- The C compiler identification is GNU 7.3.0 I can only find old references on this. I think arch used to have something, but their current build seems to use the shipped llvm (they force ninja, which will only be used by cmake, i.e. building llvm). There was a suggestion from several years ago that this used to happen if _static_ llvm libs were used. Latest issue was https://github.com/rust-lang/rust/issues/39880 but that should have been fixed. I don't know why I didn't get the libffi problem (building on 8.2 and newer). ĸen -- In my seventh decade astride this planet, and as my own cells degrade, there are some things I cannot do now: skydiving, marathon running, calculus. I couldn't do them in my 20s either, so no big loss. -- Derek Smalls, formerly of Spinal Tap -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] rustc-1.25
On 04/13/2018 11:38 PM, Bruce Dubbs wrote: Using the new instructions in the book O could not get rustc to build. I was getting: --- stderr error: couldn't load codegen backend "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so": "/tmp/rustc-test/rustc-1.25.0-src/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_trans-llvm.so: undefined symbol: ffi_type_float" === Note: ffi_type_float is defined as a symbol in libffi.so. When I removed the line llvm-config = "/usr/bin/llvm-config" from config.toml, it seem to work (still building, but past the problem area.) The build completed and everything seems OK. I do not know why rustc does not like my version of clang. $ clang --version clang version 6.0.0 (tags/RELEASE_600/final) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin Do we need to adjust the book's instructions? -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
