Ken Moffat wrote:
On Sun, Jan 21, 2018 at 08:49:53PM -0600, Bruce Dubbs wrote:
Ken Moffat wrote:
On Sun, Jan 21, 2018 at 04:58:22AM +0000, Ken Moffat wrote:
I'll be putting rustc-1.23.0 into the book soon
Or maybe I won't.
I looked at arch also and did a DESTDIR install. I used:
cat << EOF > config.toml
# see src/bootstrap/config.toml.example for more possible options
I think that is now in the top-level directory.
Right, but that's what we have in the book now.
[llvm]
targets = "X86"
[build]
# install cargo as well as rust
cargo = "/usr/bin/cargo"
rustc = "/usr/bin/rustc"
extended = true
verbose = 1
Is the verbosity helpful ?
Not really. I thought it might be useful for trouble shooting, but I
didn't need it.
[install]
prefix = "/usr"
docdir = "share/doc/rustc-$VER"
[rust]
codegen-units = 0
debuginfo = true
I'm happy to go with the defaults, but I forget what they are.
In the early days of trying to build rustc, playing with the nmber
of codegen-units didn't seem to make any real difference.
I just used what Arh did.
# Whether or not line number debug information is emitted
#debuginfo-lines = false
channel = "stable"
EOF
####
python x.py build --jobs=10
Rust will use the number of available CPUs, unless you limit it
with taskset (both 1.22.1 and 1.23.0 use a recent enough version of
the num_cpus cargo crate to work with that).
I was watching top and it seemed to limit the jobs. cargo definitely can
use --jobs. I could be wrong about x.py though.
Hmm, you are using python2 ? Maybe I should try that instead of
python3.
Seems to work better.
DESTDIR="$DEST" python x.py install
----------
Those [rust] entries seemed to help. No files were downloaded.
Umm, I think you had already build the same version and had the
correct cargo files in ~/.cargo ?
Yup.
SBU=21.168
BUILD SIZE=4.2G including installed files.
Included in that 4.2G is 581M. The space is taken up with:
83M /usr/bin (34M stripped)
365M /usr/lib (333M stripped)
134M /usr/share Almost all in html documentation
looking at the output of ldd, I think we need a way to not have the system
use rpath. I think there is a way to do that. I'll try adding rpath = true
to the [rust] portion of config.toml.
For some reason arch removes:
-rw-r--r-- 1 132 Jan 21 20:15 usr/lib/rustlib/components
-rw-r--r-- 1 3430 Jan 21 20:15 usr/lib/rustlib/manifest-rustc
-rw-r--r-- 1 2 Jan 21 20:15 usr/lib/rustlib/rust-installer-version
but I do not see what harm those do.
-- Bruce
There is a lot of the proverbial brown-stuff installed, including
source files in /usr/lib.
Yes I see that in /usr/lib/rustlib/src. About 22M. But the big boy is in
/usr/lib/rustlib/x86_64-unknown-linux-gnu (224M). There are 15 json files
and a ton of .so and .rlib files there. I don't know if they are used or
not. file says that .rlib files are 'current ar archive', so I guess they
are just static libraries.
Thanks for the comments. At the moment I've got 4 cores allocated
to building 1.22.1, before I see what happens when the big guy tries
to DESTDIR it. If that works, I'll measure it in case it gets used.
I know 1.22.1 is good enough for firefox for the moment, but I don't
know if it is good enough for librsvg.
Will try building 1.23.0 with python2, in case it's a series of
Python issues. The problem is that the issues mostly surfaced after
doing several builds of rustc, so one good build won't be
definitive.
I've built three in a row that seem OK.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
