#8951: rustc will apparently be needed for firefox-53.
-------------------------+-----------------------
Reporter: ken@… | Owner: ken@…
Type: enhancement | Status: assigned
Priority: normal | Milestone: 8.1
Component: BOOK | Version: SVN
Severity: normal | Resolution:
Keywords: |
-------------------------+-----------------------
Comment (by ken@…):
A few comments before I set this aside for a few days:
1. 1.16 is due for release on St Patrick's day. This is currently the beta
branch and includes the commit which may allow DESTDIR builds with
rustbuild. I say ''may'' because I can't build that branch and the commit
looks unlikely, with a description which suggests it might be a first
stage.
2. At the moment, the stable branch is essentially at 1.15.1, looks as if
that will be the last 1.15 release. I see that Arch were using 1.14.0 when
I last looked - if we '''have to''' build this, we might need to use a
not-latest version. For 1.15.1 DESTDIR works and it is also possible to
prevent it installing (but not building) arches such as AArch64, MIPS,
PowerPC, etc.
3. In both the master (development) and beta branches I get similar errors
(using rustbuild, it cannot be disabled in those versions). At first I
thought this was a missing file, but the original error is some way above
that - a file which is named as if it is a script, but is actually an ELF
file, fails without explanation.
4. There are references to running ./x.py in the configure output, but
1.15.1 does not have that. Using the master branch, I _thought_ I had
persuaded that to use config.toml to override certain defaults. But after
returning to 1.15.1 to get something that would actually build and
install, I found it installed in /usr/local instead of my intended
/opt/rust (I don't want a real install until I can tune it, that is a
next-best place in the absence of DESTDIR) and apparently ignored all the
settings I had provided. Possibly, config.toml is only useful where ./x.py
can be invoked.
5. With rustbuild there is (theoretically, in the light of point 4 above)
an option to specify a different number of codegen-units : this seems to
NOT be the same as 'make -jN'. From what I can see, rustbuild forces its
own optimizations (-O3) on release builds, and the codegen-units seem to
be soemthing along the lines of "build more quickly, but with poor code,
or build more slowly with good code" - for releases, the latter option is
chosen. This seems to be aimed at "build once on a build server, deploy
widely", rather than "build for the machine you are using".
6. And rustbuild appears to grab all the cores of hte build machine when
it can (from time to time, e.g. linking or copying a solib to somewhere,
only 100% CPU is used, but on my i7 it gets close to 800% usage for some
of the build.
7. With old-fashioned configure builds, it is possible to restrict which
architectures get installed (although they all appear to get compiled - I
was surprised that system LLVM with only the host architecture managed to
do this). In master this can apparently be done in config.toml.
8. On a powerful machine, building rust takes a lot longer than building
LLVM. I suggest that if we have to build this, we should encourage people
who upgrade firefox to use their current LLVM and rust versions whilst
those are still adequate - for the moment, it looks as if current rust
will not be ready for LLVM > 3.9 (at the moment there is a test for 3.7 to
3.9 as the only supported versions).
--
Ticket URL: <http://wiki.linuxfromscratch.org/blfs/ticket/8951#comment:4>
BLFS Trac <http://wiki.linuxfromscratch.org/blfs>
Beyond Linux From Scratch
--
http://lists.linuxfromscratch.org/listinfo/blfs-book
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
