On 2018-10-25 12:52, Ken Moffat via blfs-dev wrote:
Since I can only replicate the JS Context problem with old
gcc-7.3.0, it is difficult for me to know why all my builds on more
recent systems succeeded (with system graphite2 and harfbuzz)
whereas other people get failures. But in the hope of helping to
identify what differs:
1. Douglas's elfhack issue
Looking at fedora I see they disable elfhack if fedora is 29 or
newer, perhaps their toolchain is a lot newer than what we had
in 8.3. But, _our_ toolchain has not been updated since 8.3,
perhaps it is something else, e.g. libelf, which broke that ?
I see that my svn system is using elfutils-0.174, and 8.3 used
0.173.
I also noticed that, if I was reading correctly, fedora seem to use
the shipped sqlite and icu.
2. Package versions I've used successfully, re JSContext.
Adding 'X' for BLFS-8.2 which also had the problem
gcc 8.2.0, 8.1.0 X 7.3.0
binutils 2.31.1, 2.30 X 2.30
glibc 2.28, 2.27 X 2.27
python2 2.7.15 X 2.7.14
llvm 7.0.0, 6.0.1, 6.0.0 X 5.0.1
I built 7.0.0 with python3, the rest with python2.
rustc 1.29.2, 1.29.1 X 1.29.1
cbindgen 0.6.6, 0.6.4, 0.6.3 X 0.6.3
gtk3 3.24.0, 3.22.30 X 3.22.28
gtk2 2.24.32 X 2.24.32
libnotify 0.7.7 X 0.7.7
nss 3.39 X 3.39
pulse 12.2, 11.1 X 11.1
on one machine with 12.2 I enabled alsa 1.1.6
icu 62_1, 61_1 X 60_2
nodejs 9.11.2, 9.11.1 X 9.11.2
sqlite 3.25.2 X 3.25.2
graphite2 1.3.12 X 1.3.12
harfbuzz 1.9.0, 1.8.8 X 1.9.0
yasm 1.3.0 X 1.3.0
Perhaps people seeing this problem on recent systems can report
anything which differs in their systems ?
3. Off-the-wall suggestion
I looked at Arch this morning, both for firefox beta (now 64b from
an hg pull) and 63 (now on their second variant). They seem to
fiddle about with a few clang options, my impression was that for
63.0 they are using gcc. They also tell it to use gold (my memory
says it will find that if it is available, even when bfd is the
default).
Things which we don't have include a flag for hardening (dunno),
--enable-rust-simd (no idea, nor whether our build supports that)
and --enable-lto.
None of those sound particularly likely solutions. But I did notice
what they use to build with clang:
export CC=clang
export CXX=clang++
export AR=llvm-ar
export NM=llvm-nm
export RANLIB=llvm-ranlib
The AR, NM, RANLIB combination is new to me. With that, and using
the shipped graphite2 and harfbuzz I've successfully compiled and
DESTDIR installed 63.0 on my haswell (8.3, llvm-6.0.1, used all 8
cores) and my ryzen (svn from 20180920, llvm-7.0.0 built with
python3, (mostly only used 1 core, as is common on that machine,
took forever). The total space reduces to 8.8GB although the
installed files are 1MB bigger.
So, I'm going make the crazy suggestion that people try using clang
to build firefox-63.0 (if their llvm is 6.0.0 or newer) if nothing
else shows up.
ĸen
--
Is it about a bicycle ?
Heads up,
With --disable-elf-hack, the build completed fine for me. I'm using
Firefox 63.0 to type this.
Tomorrow, I will attempt Firefox 63.0 on my development system, which is
running LFS/BLFS SVN with a Skylake (i5-6600k) CPU. I'll try with
elf-hack first, and then without - to see if there are any differences.
Thank you,
Douglas R. Reno
*grumpiest man alive when dealing with Firefox and other large packages*
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
