Please don't top post. Moving to the bottom...
On Fri, Oct 26, 2018 at 6:33 PM Bruce Dubbs via blfs-dev
<[email protected]> wrote:
On 10/26/2018 05:54 PM, Ken Moffat via blfs-dev wrote:
I'm slowly getting to a point where I've got the proposed changes
for firefox ready (use clang, use gold, drop system icu).
What initially concerns me is Douglas's (and fedora 29's) need to
use --disable-elf-hack [ and I do not understand why fedora added a
patch, if I use --disable-elfhack the configure stage quickly
complains, but with --disable-elf-hack the log has no mentions of
elfhack so it clearly did get disabled ].
Given that Douglas has had many problems on his new machine, I am
tempted to say that his problem with python failing in the install
seems to be unique to that machine. And for fedora's problems I can
find no details of what architecture(s) were involved, nor how they
failed.
From what I can find, elfhack seems to be there to make libxul.so
load faster - one report said it saved several hundred milliseconds
and also saved several megabytes in the size of libxul.so. From
that, I decided to do real installs of the different configs, and to
see how long it took fo a killed firefox (from previous install) to
be reloaded (libxul.so gets overwritten as part of the install).
I clicked on the firefox menu entry as the seconds in the clock
changed, and then after the *Sorry, we're having trouble ..." screen
appeared I clicked on restore when the seconds changed. In all
cases the times were "less than two seconds" and "about 1 second".
Finally (the version without elfhack was installed) I rebooted, but
this time I did not restore and instead went for a new session with
just my home page. Again, the timings were similar.
All the builds were on my haswell, from a term limited to 4 cores
(4-7, the siblings of 0-3) and the system was otherwise mostly idle
apart from xscreensaver. These are on 8.3, so I was initially using
system ICU. The build with shipped ICU took a bit longer, and was a
bit bigger - as expected - but what I did not expect was that
disabling the elfhack would also take longer. However, these are
all quicker than the 63.0b14 gcc build where I last used only 4 cores.
The gcc build apparently used the bfd linker, with system icu,
graphite2, harfbuzz. The other builds used clang, the gold linker,
system graphite2 and harfbuzz.
Type SBU Build dir Installed
gcc 29.7 9.8 GB 141 MB
clang 19.6 8.3 GB 142 MB
+ shipped icu 21.8 8.5 GB 155 MB
+ no elf hack 22.6 8.5 GB 162 MB
My worry about disabling the elfhack is that (apart from fedora,
whose problem might be on a different architecture), no other distro
appears to need to do this. Therefore, I would prefer to keep it.
More generally, as the pythonistas and rustaceans take over it seems
that using system libraries is generally becoming harder (first sys
cairo was dropped, now ICU needs a specific and not-latest version).
I almost wonder if we should just drop system libraries and hope that
mozilla will fix vulnerabilities in their shipped libs quickly,
although past experience over the years suggests not.
I think your approach is good.
Just for info, I did a search for 'elf-hack' and the only place it
seemed to be used was in toolkit/moz.configure and that set a variable
USE_ELF_HACK.
Searching for that, the only thing I found that seemed significant was
in build/unix/moz.build and that sets DIRS += ['elfhack'].
From there I found build/unix/elfhack/elfhack.cpp
Some of that is dedicated to specific architectures, but from what I can
tell it is an optimization of relocations when loading dynamic
libraries. However I could be completely wrong about that.
Judging from your tests and what most of the main stream distros are
doing, I suggest we not mention the hack until we have a solid reason to
do so.
On 10/26/2018 08:48 PM, Brendan L via blfs-dev wrote:
Here is the bug where elfhack was implemented. In the comments there
is a link to a blog with details about it.
https://bugzilla.mozilla.org/show_bug.cgi?id=606145
On 10/26/2018 08:48 PM, Brendan L via blfs-dev wrote:
Here is the bug where elfhack was implemented. In the comments there
is a link to a blog with details about it.
https://bugzilla.mozilla.org/show_bug.cgi?id=606145
Most of this bug is 8 years old, but it's probably still relevant.
I've been thinking about this a bit more. Doug's problem is during the
install where something in the installer relating to the elfhack code is
throwing an uncaught exception. Perhaps we should add a comment into
the mozconfig that on some systems this happens and that it can be fixed
with uncommenting
#ac_add_options --disable-elf-hack
The hack itself only appears to give a very minor speedup to the initial
start process and it would appear that the faster the machine, the less
important the hack becomes.
We should also keep an eye on this issue as the 63.0.x releases and
beyond are released. I suspect we will see several before our next
stable release is scheduled next March.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
