[blfs-dev] Error building firefox 63.0

[Tim Tassonis via blfs-dev]

Hi all


Just tried to build firefox 63.0 and got the folllowing error:


-12:10.16 /lgl-bld/firefox-63.0/js/src/vm/JSContext-inl.h:180:73: error:
no ‘void JSContext::checkImpl_63(int, const Head&, const Tail& ...)’
member function declared in class ‘JSContext’
12:10.16 JSContext::checkImpl(int argIndex, const Head& head, const
Tail&... tail)
12:10.16



I'm fully aware that this is my problem, just thought maybe someone
else stumbled on this an knows a fix.

This is with gcc 7.3.0 and the system_graphite2_harfbuzz-1 patch, but
without node.js




Bye
Tim

[Ken Moffat via blfs-dev]

Post by Tim Tassonis via blfs-dev
Hi all
-12:10.16 /lgl-bld/firefox-63.0/js/src/vm/JSContext-inl.h:180:73: error: no
‘void JSContext::checkImpl_63(int, const Head&, const Tail& ...)’ member
function declared in class ‘JSContext’
12:10.16 JSContext::checkImpl(int argIndex, const Head& head, const
Tail&... tail)
12:10.16
I'm fully aware that this is my problem, just thought maybe someone else
stumbled on this an knows a fix.
This is with gcc 7.3.0 and the system_graphite2_harfbuzz-1 patch, but
without node.js

As I think I said in the ticket, I get the same with gcc-7.3.0.
With a system from May using gcc-8.1 everything was fine so it seems
to be a gcc-7 problem.

No idea what distros will be doing. Talking of problems, I'll also
mention that in _early_ betas I used clang/clang++ (saved space, but
not time), but that fell apart (looked like C++ scope problems, but
not fixed by playing with the possible switches.

So, for gcc-7.3.0 all I can do is recommend building 60.3.0esr with
the config we used to use for the 60 series and the later (60.2?)
system graphite patch (but not the ffmpeg patch, my old systems were
using ffmpeg-3.4.2). Tested with current rustc, because I'd already
updated those old systems.

If there is a fix, that would be good.

ĸen

[Bruce Dubbs via blfs-dev]

Post by Ken Moffat via blfs-dev

Post by Tim Tassonis via blfs-dev
Hi all
-12:10.16 /lgl-bld/firefox-63.0/js/src/vm/JSContext-inl.h:180:73: error: no
‘void JSContext::checkImpl_63(int, const Head&, const Tail& ...)’ member
function declared in class ‘JSContext’
12:10.16 JSContext::checkImpl(int argIndex, const Head& head, const
Tail&... tail)
12:10.16

I got a similar error in the same place:

/mnt/tmp/firefox/firefox-63.0/js/src/vm/JSContext-inl.h:180:1: error: no
declaration matches ‘void JSContext::checkImpl_63(int, const Head&,
const Tail& ...)’
0:06.42 JSContext::checkImpl(int argIndex, const Head& head, const
Tail&... tail)

I do have node-v9.11.2 installed.
Using gcc 8.2.

grepping for JSContext::checkImpl only finds a match in
js/src/vm/JSContext-inl.h

I could find nothing similar to JSContext::checkImpl in /usr/include

-- Bruce

Post by Ken Moffat via blfs-dev

Post by Tim Tassonis via blfs-dev
I'm fully aware that this is my problem, just thought maybe someone else
stumbled on this an knows a fix.
This is with gcc 7.3.0 and the system_graphite2_harfbuzz-1 patch, but
without node.js

As I think I said in the ticket, I get the same with gcc-7.3.0.
With a system from May using gcc-8.1 everything was fine so it seems
to be a gcc-7 problem.
No idea what distros will be doing. Talking of problems, I'll also
mention that in _early_ betas I used clang/clang++ (saved space, but
not time), but that fell apart (looked like C++ scope problems, but
not fixed by playing with the possible switches.
So, for gcc-7.3.0 all I can do is recommend building 60.3.0esr with
the config we used to use for the 60 series and the later (60.2?)
system graphite patch (but not the ffmpeg patch, my old systems were
using ffmpeg-3.4.2). Tested with current rustc, because I'd already
updated those old systems.
If there is a fix, that would be good.
ĸen

[renodr via blfs-dev]

Post by Tim Tassonis via blfs-dev
Hi all
-12:10.16 /lgl-bld/firefox-63.0/js/src/vm/JSContext-inl.h:180:73: error: no
‘void JSContext::checkImpl_63(int, const Head&, const Tail& ...)’ member
function declared in class ‘JSContext’
12:10.16 JSContext::checkImpl(int argIndex, const Head& head, const
Tail&... tail)
12:10.16

no declaration matches ‘void JSContext::checkImpl_63(int, const Head&,
const Tail& ...)’
0:06.42 JSContext::checkImpl(int argIndex, const Head& head, const
Tail&... tail)
I do have node-v9.11.2 installed.
Using gcc 8.2.
grepping for JSContext::checkImpl only finds a match in
js/src/vm/JSContext-inl.h
I could find nothing similar to JSContext::checkImpl in /usr/include
-- Bruce

In my case, I can build it fine if I run at -j1 (96 SBU!), but I cannot
install it. When I attempt to install it, it bombs out about "elfhack".
Something throws an "iostream" error:

BLFS Start INSTALL
0:00.72 /usr/bin/make -C . -j1 -s -w install
0:00.73 make: Entering directory
'/sources/firefox-63.0/firefox-63.0/firefox-build-dir'
0:00.79 make[1]: Entering directory
'/sources/firefox-63.0/firefox-63.0/firefox-build-dir/browser/installer'
0:45.74 terminate called after throwing an instance of
'std::__ios_failure'
0:45.76 what(): basic_ios::clear: iostream error
0:57.35 Traceback (most recent call last):
0:57.35 File
"/sources/firefox-63.0/firefox-63.0/toolkit/mozapps/installer/packager.py",
line 339, in <module>
0:57.35 main()
0:57.35 File
"/sources/firefox-63.0/firefox-63.0/toolkit/mozapps/installer/packager.py",
line 333, in main
0:57.35 copier.copy(args.destination)
0:57.35 File
"/sources/firefox-63.0/firefox-63.0/python/mozbuild/mozpack/copier.py",
line 431, in copy
0:58.01 copy_results.append((destfile, f.copy(destfile,
skip_if_older)))
0:58.01 File
"/sources/firefox-63.0/firefox-63.0/python/mozbuild/mozpack/files.py",
line 296, in copy
0:58.01 elfhack(dest)
0:58.01 File
"/sources/firefox-63.0/firefox-63.0/python/mozbuild/mozpack/executables.py",
line 124, in elfhack
0:58.29 errors.fatal('Error executing ' + ' '.join(cmd))
0:58.29 File
"/sources/firefox-63.0/firefox-63.0/python/mozbuild/mozpack/errors.py",
line 103, in fatal
0:58.33 self._handle(self.FATAL, msg)
0:58.33 File
"/sources/firefox-63.0/firefox-63.0/python/mozbuild/mozpack/errors.py",
line 98, in _handle
0:58.33 raise ErrorMessage(msg)
0:58.33 mozpack.errors.ErrorMessage: Error: Error executing
/sources/firefox-63.0/firefox-63.0/firefox-build-dir/build/unix/elfhack/elfhack
../../dist/firefox/libxul.so
0:58.35 make[1]: ***
[/sources/firefox-63.0/firefox-63.0/toolkit/mozapps/installer/packager.mk:22:
stage-package] Error 1
0:58.35 make[1]: Leaving directory
'/sources/firefox-63.0/firefox-63.0/firefox-build-dir/browser/installer'
0:58.35 make: ***
[/sources/firefox-63.0/firefox-63.0/browser/build.mk:15: install] Error
2
0:58.35 make: Leaving directory
'/sources/firefox-63.0/firefox-63.0/firefox-build-dir'

The only reason why I used -j1 (and shut off all of my other cores) is
because I found a resource leak in rust that leads to an OOM when
compiling Firefox (I have 64GB of RAM in this system):

[608008.254835] Out of memory: Kill process 28009 (rustc) score 346 or
sacrifice child
[608008.254843] Killed process 28009 (rustc) total-vm:3734704kB,
anon-rss:2777716kB, file-rss:0kB, shmem-rss:0kB
[608008.383204] oom_reaper: reaped process 28009 (rustc), now
anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

It repeated that (with a call trace) for all 12 "CPUs" in the system
(6c/12t CPU). Even at -j4, I'm leaking and OOMing. If I feel adventurous
(or if anyone suggests it), I can try a newer version of rustc to see if
the leaking problem is gone (the new librsvg that JUST came out needs
1.27 anyway
[https://mail.gnome.org/archives/ftp-release-list/2018-October/msg00087.html]).

I have 504 coredumps on this system (and it's not more than a couple
weeks old). A majority of them were due to ICE's (CPU was too new for
it's quirks to be covered in the kernel, as well as some Illegal
Operation errors), but I have one from elfhack here:

$ coredumpctl info
/sources/firefox-63.0/firefox-63.0/firefox-build-dir/build/unix/elfhack/elfhack
PID: 7047 (elfhack)
UID: 0 (root)
GID: 0 (root)
Signal: 6 (ABRT)
Timestamp: Wed 2018-10-24 17:52:09 CDT (2h 47min ago)
Command Line:
/sources/firefox-63.0/firefox-63.0/firefox-build-dir/build/unix/elfhack/elfhack
../../dist/firefox/libxul.so
Executable:
/sources/firefox-63.0/firefox-63.0/firefox-build-dir/build/unix/elfhack/elfhack
Control Group: /user.slice/user-1000.slice/session-c1.scope
Unit: session-c1.scope
Slice: user-1000.slice
Session: c1
Owner UID: 1000 (renodr)
Boot ID: 3ec1bf24fdbd4caf8556e29527e93458
Machine ID: 43c995037fc0492a843f1f7d6c9d14ed
Hostname: RENODR-LFSWKST
Storage:
/var/lib/systemd/coredump/core.elfhack.0.3ec1bf24fdbd4caf8556e29527e93458.7047.1540421529000000.xz
(inaccessible)
Message: Process 7047 (elfhack) of user 0 dumped core.

Off-topic:

As for the rest of my crashes, I've had three in lxpanel, several in
COGL/Clutter (I'm aware of those, have to update Mesa), and several in
wayland, GTK2, LLVM, ld, and ruby. This system hasn't been kind to me
for it's initial software load. I suppose I could do another build if
absolutely necessary, but I'd rather not, and they aren't related to
Firefox-63.

[Brendan L via blfs-dev]

On Wed, Oct 24, 2018 at 8:49 PM renodr via blfs-dev

Post by renodr via blfs-dev

Post by Tim Tassonis via blfs-dev
Hi all
-12:10.16 /lgl-bld/firefox-63.0/js/src/vm/JSContext-inl.h:180:73: error: no
‘void JSContext::checkImpl_63(int, const Head&, const Tail& ...)’ member
function declared in class ‘JSContext’
12:10.16 JSContext::checkImpl(int argIndex, const Head& head, const
Tail&... tail)
12:10.16

no declaration matches ‘void JSContext::checkImpl_63(int, const Head&,
const Tail& ...)’
0:06.42 JSContext::checkImpl(int argIndex, const Head& head, const
Tail&... tail)
I do have node-v9.11.2 installed.
Using gcc 8.2.
grepping for JSContext::checkImpl only finds a match in
js/src/vm/JSContext-inl.h
I could find nothing similar to JSContext::checkImpl in /usr/include
-- Bruce

In my case, I can build it fine if I run at -j1 (96 SBU!), but I cannot
install it. When I attempt to install it, it bombs out about "elfhack".

There is a mozconfig option --disable-elf-hack. I had to use it when
building firefox with clang and lld, otherwise the build would fail
right at the end. Maybe you could try it.

[Bruce Dubbs via blfs-dev]

Post by Brendan L via blfs-dev

Post by renodr via blfs-dev
In my case, I can build it fine if I run at -j1 (96 SBU!), but I cannot
install it. When I attempt to install it, it bombs out about "elfhack".

There is a mozconfig option --disable-elf-hack. I had to use it when
building firefox with clang and lld, otherwise the build would fail
right at the end. Maybe you could try it.

Thanks, but that option did not fix the build for me. I still got the
error about JSContext::checkImpl.

-- Bruce

[renodr via blfs-dev]

Post by Brendan L via blfs-dev
On Wed, Oct 24, 2018 at 8:49 PM renodr via blfs-dev

Post by renodr via blfs-dev

Post by Tim Tassonis via blfs-dev
Hi all
-12:10.16 /lgl-bld/firefox-63.0/js/src/vm/JSContext-inl.h:180:73: error: no
‘void JSContext::checkImpl_63(int, const Head&, const Tail& ...)’ member
function declared in class ‘JSContext’
12:10.16 JSContext::checkImpl(int argIndex, const Head& head, const
Tail&... tail)
12:10.16

no declaration matches ‘void JSContext::checkImpl_63(int, const Head&,
const Tail& ...)’
0:06.42 JSContext::checkImpl(int argIndex, const Head& head, const
Tail&... tail)
I do have node-v9.11.2 installed.
Using gcc 8.2.
grepping for JSContext::checkImpl only finds a match in
js/src/vm/JSContext-inl.h
I could find nothing similar to JSContext::checkImpl in /usr/include
-- Bruce

In my case, I can build it fine if I run at -j1 (96 SBU!), but I cannot
install it. When I attempt to install it, it bombs out about
"elfhack".

There is a mozconfig option --disable-elf-hack. I had to use it when
building firefox with clang and lld, otherwise the build would fail
right at the end. Maybe you could try it.

I'm giving that a shot right now to see what it does. Again, at -j1 (I
checked my RAM overnight per Ken's suggestion, and it came out fine). If
this works, Thank you!

[Bruce Dubbs via blfs-dev]

Post by renodr via blfs-dev
In my case, I can build it fine if I run at -j1 (96 SBU!), but I cannot
install it. When I attempt to install it, it bombs out about "elfhack".

I tried -j1 also, but it still failed for me at the same point:

At JSContext::checkImpl I got error: no declaration matches ...

-- Bruce

[renodr via blfs-dev]

Post by Bruce Dubbs via blfs-dev

Post by renodr via blfs-dev
In my case, I can build it fine if I run at -j1 (96 SBU!), but I
cannot install it. When I attempt to install it, it bombs out about

At JSContext::checkImpl I got error: no declaration matches ...
-- Bruce

Here's a list of my packages (at least as it pertains to Firefox
dependencies):

Wed Oct 17 22:26:59 CDT 2018 autoconf-2.13
Tue Oct 23 21:02:49 CDT 2018 cbindgen-0.6.6
Tue Oct 16 15:33:12 CDT 2018 llvm-7.0.0
Thu Oct 18 11:59:38 CDT 2018 gtk+-3.24.1 *
Thu Oct 18 11:12:36 CDT 2018 gtk+-2.24.32 *
Sun Oct 21 23:56:48 CDT 2018 libnotify-0.7.7
Tue Oct 16 16:38:50 CDT 2018 nss-3.39
Sat Oct 20 12:57:40 CDT 2018 pulseaudio-12.2
Sat Oct 20 11:38:09 CDT 2018 alsa-lib-1.1.6
Thu Oct 18 14:50:57 CDT 2018 rustc-1.29.2
Tue Oct 16 16:29:14 CDT 2018 unzip60
Thu Oct 18 10:24:17 CDT 2018 yasm-1.3.0
Tue Oct 16 02:29:54 CDT 2018 zip30
Tue Oct 16 19:10:44 CDT 2018 icu4c-62.1
Tue Oct 16 18:19:47 CDT 2018 libevent-2.1.8
Sun Oct 21 19:28:33 CDT 2018 libvpx-1.7.0
Tue Oct 23 21:48:02 CDT 2018 node-v9.11.2
Mon Oct 22 21:45:18 CDT 2018 sqlite-autoconf-3250200
Tue Oct 16 01:25:42 CDT 2018 curl-7.61.1
Thu Oct 18 11:24:23 CDT 2018 dbus-glib-0.110
Sat Oct 20 12:50:29 CDT 2018 GConf-3.2.6
Mon Oct 22 21:39:13 CDT 2018 ffmpeg-4.0.2
Sat Oct 20 16:26:30 CDT 2018 libwebp-1.0.0
Sat Oct 20 11:35:15 CDT 2018 startup-notification-0.12
Tue Oct 16 16:25:56 CDT 2018 valgrind-3.13.0
Tue Oct 16 18:50:39 CDT 2018 wget-1.19.5
Tue Oct 16 18:51:13 CDT 2018 wireless_tools-29
Wed Oct 17 19:50:42 CDT 2018 graphite2-1.3.11
Wed Oct 17 19:49:33 CDT 2018 harfbuzz-1.9.0

* = rebuilt at least once for printing support after CUPS was installed
NOTE - I do not have liboauth installed yet, and I don't have plans on
installing Doxygen or OpenJDK. I can if necessary though.

That magical combination of package versions lets me get to the end of
the build, up to the install process. I added --disable-elf-hack to my
mozconfig, and we'll see if that lets me get away with building it.

Without a doubt, there's a problem here somewhere.

[Bruce Dubbs via blfs-dev]

Post by renodr via blfs-dev

Post by renodr via blfs-dev
In my case, I can build it fine if I run at -j1 (96 SBU!), but I
cannot install it. When I attempt to install it, it bombs out about

At JSContext::checkImpl  I got error: no declaration matches ...
  -- Bruce

Here's a list of my packages (at least as it pertains to Firefox
Wed Oct 17 22:26:59 CDT 2018 autoconf-2.13
Tue Oct 23 21:02:49 CDT 2018 cbindgen-0.6.6
Tue Oct 16 15:33:12 CDT 2018 llvm-7.0.0

I only have -6.0.1 right now

Post by renodr via blfs-dev
Thu Oct 18 11:59:38 CDT 2018 gtk+-3.24.1 *

I only have -3.22.30 right now

Post by renodr via blfs-dev
Thu Oct 18 11:12:36 CDT 2018 gtk+-2.24.32 *
Sun Oct 21 23:56:48 CDT 2018 libnotify-0.7.7
Tue Oct 16 16:38:50 CDT 2018 nss-3.39
Sat Oct 20 12:57:40 CDT 2018 pulseaudio-12.2
Sat Oct 20 11:38:09 CDT 2018 alsa-lib-1.1.6
Thu Oct 18 14:50:57 CDT 2018 rustc-1.29.2
Tue Oct 16 16:29:14 CDT 2018 unzip60
Thu Oct 18 10:24:17 CDT 2018 yasm-1.3.0
Tue Oct 16 02:29:54 CDT 2018 zip30
Tue Oct 16 19:10:44 CDT 2018 icu4c-62.1

I have -63_1

Post by renodr via blfs-dev
Tue Oct 16 18:19:47 CDT 2018 libevent-2.1.8
Sun Oct 21 19:28:33 CDT 2018 libvpx-1.7.0
Tue Oct 23 21:48:02 CDT 2018 node-v9.11.2
Mon Oct 22 21:45:18 CDT 2018 sqlite-autoconf-3250200

I have -3240000

Post by renodr via blfs-dev
Tue Oct 16 01:25:42 CDT 2018 curl-7.61.1
Thu Oct 18 11:24:23 CDT 2018 dbus-glib-0.110
Sat Oct 20 12:50:29 CDT 2018 GConf-3.2.6
Mon Oct 22 21:39:13 CDT 2018 ffmpeg-4.0.2
Sat Oct 20 16:26:30 CDT 2018 libwebp-1.0.0
Sat Oct 20 11:35:15 CDT 2018 startup-notification-0.12
Tue Oct 16 16:25:56 CDT 2018 valgrind-3.13.0

I have -3.14.0

Post by renodr via blfs-dev
Tue Oct 16 18:50:39 CDT 2018 wget-1.19.5
Tue Oct 16 18:51:13 CDT 2018 wireless_tools-29
Wed Oct 17 19:50:42 CDT 2018 graphite2-1.3.11

I have -1.3.12

Post by renodr via blfs-dev
Wed Oct 17 19:49:33 CDT 2018 harfbuzz-1.9.0

I have -1.8.8, but got the same problem when using the included
harfbuzz.

To me, the only real candidate for the build issue is llvm.

Post by renodr via blfs-dev
* = rebuilt at least once for printing support after CUPS was installed
NOTE - I do not have liboauth installed yet, and I don't have plans on
installing Doxygen or OpenJDK. I can if necessary though.
That magical combination of package versions lets me get to the end of
the build, up to the install process. I added --disable-elf-hack to my
mozconfig, and we'll see if that lets me get away with building it.

I tried --disable-elf-hack last night and it did not affect the error I
was getting.

I was looking at the error last night and it was looking for

void JSContext::checkImpl_63(...

Note the _63. From best I can tell, this is occurring from a generated
file, but the ./mach output makes it difficult to tell. I tried adding
--verbose, but did not seem to get a lot of info. I'll try Ken's
suggestion to use clang.

Post by renodr via blfs-dev
Without a doubt, there's a problem here somewhere.

Agreed.

-- Bruce

[Ken Moffat via blfs-dev]

Post by Bruce Dubbs via blfs-dev

Post by renodr via blfs-dev
Here's a list of my packages (at least as it pertains to Firefox
Wed Oct 17 22:26:59 CDT 2018 autoconf-2.13
Tue Oct 23 21:02:49 CDT 2018 cbindgen-0.6.6
Tue Oct 16 15:33:12 CDT 2018 llvm-7.0.0

I only have -6.0.1 right now

Hi Bruce,

I guess you'll have seen my post by now.

Post by Bruce Dubbs via blfs-dev

Post by renodr via blfs-dev
Thu Oct 18 11:59:38 CDT 2018 gtk+-3.24.1 *

I only have -3.22.30 right now

Should be ok

Post by Bruce Dubbs via blfs-dev

Post by renodr via blfs-dev
Tue Oct 16 19:10:44 CDT 2018 icu4c-62.1

I have -63_1

^^^^^ - see the end of my reply

Post by Bruce Dubbs via blfs-dev

Post by renodr via blfs-dev
Tue Oct 16 18:19:47 CDT 2018 libevent-2.1.8
Sun Oct 21 19:28:33 CDT 2018 libvpx-1.7.0
Tue Oct 23 21:48:02 CDT 2018 node-v9.11.2
Mon Oct 22 21:45:18 CDT 2018 sqlite-autoconf-3250200

I have -3240000

Probably ok, but sqlite, nss and the certificates are things I
always update for a new firefox release.

Post by Bruce Dubbs via blfs-dev

Post by renodr via blfs-dev
Tue Oct 16 16:25:56 CDT 2018 valgrind-3.13.0

I have -3.14.0

I guess that is unlikely to matter

Post by Bruce Dubbs via blfs-dev

Post by renodr via blfs-dev
Wed Oct 17 19:50:42 CDT 2018 graphite2-1.3.11

I have -1.3.12

Necessary if enabling system graphite (unless I've botched the
patch). :

+dnl Check for graphite2
+dnl ========================================================
+if test -n "$MOZ_SYSTEM_GRAPHITE2"; then
+ dnl graphite2.pc has bogus version, check manually
+ _SAVE_CFLAGS=$CFLAGS
+ CFLAGS="$CFLAGS $MOZ_GRAPHITE2_CFLAGS"
+ AC_TRY_COMPILE([ #include <graphite2/Font.h>
+ #define GR2_VERSION_REQUIRE(major,minor,bugfix) \
+ ( GR2_VERSION_MAJOR * 10000 + GR2_VERSION_MINOR \
+ * 100 + GR2_VERSION_BUGFIX >= \
+ (major) * 10000 + (minor) * 100 + (bugfix) )
+ ], [
+ #if !GR2_VERSION_REQUIRE(1,3,12)
+ #error "Insufficient graphite2 version."
+ #endif
+ ], [],
+ [AC_MSG_ERROR([--with-system-graphite2 requested but no working libgraphite2 found])])
+ CFLAGS=$_SAVE_CFLAGS
+fi

That looks as if it should #error with 1.3.11. The shipped version
is 1.3.12. But without enabling it, should work (I only test with
both system graphite2 and harfbuzz enabled).

Post by Bruce Dubbs via blfs-dev

Post by renodr via blfs-dev
Wed Oct 17 19:49:33 CDT 2018 harfbuzz-1.9.0

I have -1.8.8, but got the same problem when using the included harfbuzz.

The included version is also 1.8.8

Post by Bruce Dubbs via blfs-dev
To me, the only real candidate for the build issue is llvm.

Disagree - icu. My BLFS-8.2 has icu_60_2, which might be too old,
and I think that fedora disable system icu. I said "if I'm reading
it right" because that seemed an odd thing to do.

Post by Bruce Dubbs via blfs-dev

Post by renodr via blfs-dev
* = rebuilt at least once for printing support after CUPS was installed
NOTE - I do not have liboauth installed yet, and I don't have plans on
installing Doxygen or OpenJDK. I can if necessary though.
That magical combination of package versions lets me get to the end of
the build, up to the install process. I added --disable-elf-hack to my
mozconfig, and we'll see if that lets me get away with building it.

I tried --disable-elf-hack last night and it did not affect the error I was
getting.

I think Douglas's problem is different, but I don't know what is
causing it (unless he has a newer libelf than what is in the book).

Post by Bruce Dubbs via blfs-dev
I was looking at the error last night and it was looking for
void JSContext::checkImpl_63(...
Note the _63. From best I can tell, this is occurring from a generated
file, but the ./mach output makes it difficult to tell. I tried adding
--verbose, but did not seem to get a lot of info. I'll try Ken's
suggestion to use clang.

Indeed, _63 implies it comes from icu.

Post by Bruce Dubbs via blfs-dev

Post by renodr via blfs-dev
Without a doubt, there's a problem here somewhere.

Agreed.
-- Bruce

After the clang build (probably) fails, can you try commenting out

ac_add_options --with-system-icu

please.

ĸen

[Bruce Dubbs via blfs-dev]

Post by Ken Moffat via blfs-dev

Post by Bruce Dubbs via blfs-dev

Post by renodr via blfs-dev
Here's a list of my packages (at least as it pertains to Firefox
Wed Oct 17 22:26:59 CDT 2018 autoconf-2.13
Tue Oct 23 21:02:49 CDT 2018 cbindgen-0.6.6
Tue Oct 16 15:33:12 CDT 2018 llvm-7.0.0

I only have -6.0.1 right now

Hi Bruce,
I guess you'll have seen my post by now.

Post by Bruce Dubbs via blfs-dev

Post by renodr via blfs-dev
Thu Oct 18 11:59:38 CDT 2018 gtk+-3.24.1 *

I only have -3.22.30 right now

Should be ok

Post by Bruce Dubbs via blfs-dev

Post by renodr via blfs-dev
Tue Oct 16 19:10:44 CDT 2018 icu4c-62.1

I have -63_1

^^^^^ - see the end of my reply

Post by Bruce Dubbs via blfs-dev

Post by renodr via blfs-dev
Tue Oct 16 18:19:47 CDT 2018 libevent-2.1.8
Sun Oct 21 19:28:33 CDT 2018 libvpx-1.7.0
Tue Oct 23 21:48:02 CDT 2018 node-v9.11.2
Mon Oct 22 21:45:18 CDT 2018 sqlite-autoconf-3250200

I have -3240000

Probably ok, but sqlite, nss and the certificates are things I
always update for a new firefox release.

Post by Bruce Dubbs via blfs-dev

Post by renodr via blfs-dev
Tue Oct 16 16:25:56 CDT 2018 valgrind-3.13.0

I have -3.14.0

I guess that is unlikely to matter

Post by Bruce Dubbs via blfs-dev

Post by renodr via blfs-dev
Wed Oct 17 19:50:42 CDT 2018 graphite2-1.3.11

I have -1.3.12

Necessary if enabling system graphite (unless I've botched the
+dnl Check for graphite2
+dnl ========================================================
+if test -n "$MOZ_SYSTEM_GRAPHITE2"; then
+ dnl graphite2.pc has bogus version, check manually
+ _SAVE_CFLAGS=$CFLAGS
+ CFLAGS="$CFLAGS $MOZ_GRAPHITE2_CFLAGS"
+ AC_TRY_COMPILE([ #include <graphite2/Font.h>
+ #define GR2_VERSION_REQUIRE(major,minor,bugfix) \
+ ( GR2_VERSION_MAJOR * 10000 + GR2_VERSION_MINOR \
+ * 100 + GR2_VERSION_BUGFIX >= \
+ (major) * 10000 + (minor) * 100 + (bugfix) )
+ ], [
+ #if !GR2_VERSION_REQUIRE(1,3,12)
+ #error "Insufficient graphite2 version."
+ #endif
+ ], [],
+ [AC_MSG_ERROR([--with-system-graphite2 requested but no working libgraphite2 found])])
+ CFLAGS=$_SAVE_CFLAGS
+fi
That looks as if it should #error with 1.3.11. The shipped version
is 1.3.12. But without enabling it, should work (I only test with
both system graphite2 and harfbuzz enabled).

Post by Bruce Dubbs via blfs-dev

Post by renodr via blfs-dev
Wed Oct 17 19:49:33 CDT 2018 harfbuzz-1.9.0

I have -1.8.8, but got the same problem when using the included harfbuzz.

The included version is also 1.8.8

Post by Bruce Dubbs via blfs-dev
To me, the only real candidate for the build issue is llvm.

Disagree - icu. My BLFS-8.2 has icu_60_2, which might be too old,
and I think that fedora disable system icu. I said "if I'm reading
it right" because that seemed an odd thing to do.

Post by Bruce Dubbs via blfs-dev

Post by renodr via blfs-dev
* = rebuilt at least once for printing support after CUPS was installed
NOTE - I do not have liboauth installed yet, and I don't have plans on
installing Doxygen or OpenJDK. I can if necessary though.
That magical combination of package versions lets me get to the end of
the build, up to the install process. I added --disable-elf-hack to my
mozconfig, and we'll see if that lets me get away with building it.

I tried --disable-elf-hack last night and it did not affect the error I was
getting.

I think Douglas's problem is different, but I don't know what is
causing it (unless he has a newer libelf than what is in the book).

Post by Bruce Dubbs via blfs-dev
I was looking at the error last night and it was looking for
void JSContext::checkImpl_63(...
Note the _63. From best I can tell, this is occurring from a generated
file, but the ./mach output makes it difficult to tell. I tried adding
--verbose, but did not seem to get a lot of info. I'll try Ken's
suggestion to use clang.

Indeed, _63 implies it comes from icu.

Post by Bruce Dubbs via blfs-dev

Post by renodr via blfs-dev
Without a doubt, there's a problem here somewhere.

Agreed.
-- Bruce

After the clang build (probably) fails, can you try commenting out
ac_add_options --with-system-icu

As you may have seen in my earlier post, I came to the same conclusion
independently. I did use the internal icu and FF built, installed, and
ran (very limited testing) fine. I did use both the clang exports and
the elfhack option. I'll try again without those, but I don't have time
today.

SBU=15.275 using all 12 cores.

-- Bruce

[Ken Moffat via blfs-dev]

Post by Bruce Dubbs via blfs-dev
As you may have seen in my earlier post, I came to the same conclusion
independently. I did use the internal icu and FF built, installed, and ran
(very limited testing) fine. I did use both the clang exports and the
elfhack option. I'll try again without those, but I don't have time today.

AFAICS, the only likely difference using clang is that the build is
considerably smaller. Worth doing for future builds on llvm-6+ now
that it again works, but not worth retesting.

For the elf hack, I'm in the dark about why it is needed.

Post by Bruce Dubbs via blfs-dev
SBU=15.275 using all 12 cores.
-- Bruce

I've just completed the build and install on my i7 haswell BLFS-8,2,
using the shipped icu. 19.3 SBU (only 8 cores).

Summary:

1. Drop system icu unless that is 61 or 62.

2. Enable clang if its major version is 6 or 7.

3. I need to check how to enable gold.

4. I need to look at fedora to see if I can find out why they
disable elfhack.

ĸen

[Ken Moffat via blfs-dev]

Post by Ken Moffat via blfs-dev
1. Drop system icu unless that is 61 or 62.
2. Enable clang if its major version is 6 or 7.
3. I need to check how to enable gold.
4. I need to look at fedora to see if I can find out why they
disable elfhack.

For elfhack, all I can find is a comment that that builds failed in
fedora 29, no details at all. Also, for 63, and probably for 62
befoe that, they use a patch to disable it. Not understood.

Holding fire on this part until (perhaps) Douglas can clarify what
might be different in his system.

I also looked at the hardening option, bu that is enabled by default
unless it is specifically disabled - so nothing to do for that part.

ĸen

[renodr via blfs-dev]

Post by Ken Moffat via blfs-dev

Post by Ken Moffat via blfs-dev
1. Drop system icu unless that is 61 or 62.
2. Enable clang if its major version is 6 or 7.
3. I need to check how to enable gold.
4. I need to look at fedora to see if I can find out why they
disable elfhack.

For elfhack, all I can find is a comment that that builds failed in
fedora 29, no details at all. Also, for 63, and probably for 62
befoe that, they use a patch to disable it. Not understood.
Holding fire on this part until (perhaps) Douglas can clarify what
might be different in his system.
I also looked at the hardening option, bu that is enabled by default
unless it is specifically disabled - so nothing to do for that part.
ĸen
--
Is it about a bicycle ?

I can't clarify what is different in my system. I used jhalfs to build
it with LFS 8.3 as a base, with the standard libelf in LFS. This is with
systemd, although I don't think it matters. I'm running kernel version
4.19 on this system.

I'm not 100% certain what is going on here. Wait for Bruce's results
without it to see what he says... this is all confusing...

[Ken Moffat via blfs-dev]

Post by Ken Moffat via blfs-dev
For elfhack, all I can find is a comment that that builds failed in
fedora 29, no details at all. Also, for 63, and probably for 62
befoe that, they use a patch to disable it. Not understood.
Holding fire on this part until (perhaps) Douglas can clarify what
might be different in his system.

I can't clarify what is different in my system. I used jhalfs to build it
with LFS 8.3 as a base, with the standard libelf in LFS. This is with
systemd, although I don't think it matters. I'm running kernel version 4.19
on this system.
I'm not 100% certain what is going on here. Wait for Bruce's results without
it to see what he says... this is all confusing...

OK. I'll maybe try a build with elfhack disabled tomorrow on my
haswell, to confirm space measurements and to see if the startup time
appears to be impacted.

Meanwhile, trying clang-5.0 on an 8.2 system (I know I said "don't",
but things need to be confirmed - and gentoo appear to require
llvm >= 4.0)..

ĸen

[Ken Moffat via blfs-dev]

Post by Ken Moffat via blfs-dev
Meanwhile, trying clang-5.0 on an 8.2 system (I know I said "don't",
but things need to be confirmed - and gentoo appear to require
llvm >= 4.0)..

Built and installed ok, works.

ĸen

[dueffert--- via blfs-dev]

Hi all,

Post by Ken Moffat via blfs-dev

Post by Bruce Dubbs via blfs-dev

Post by renodr via blfs-dev
Tue Oct 16 19:10:44 CDT 2018 icu4c-62.1

I have -63_1

^^^^^ - see the end of my reply
After the clang build (probably) fails, can you try commenting out
ac_add_options --with-system-icu

Thanks, that's it, at least for me: Build fails with system icu4c-63.1,
succeeds without --with-system-icu, and succeeds as well with system
icu4c-62.1 .

All other changes do not really matter for me. Others suspected rust, gcc,
llvm, libelf or parallelity to be the problem, but none of that made the
difference between working and non-working for me. They may influence
the exact way or time of failure, but not whether there is an
"unresolvable" final one.

I did see other "issues", though - in particular:

Build also fails without cbindgen (I rather experimentally installed
that for the first time ever, ff-62.0.3 builds fine without, but thats
not the real issue).

Build fails in different ways depending on whether /usr/bin/node exists
or whether --disable-nodejs was specified, but again: both isn't really
the problem. With "correct" icu, ff-63 builds fine - with
--disable-nodejs AND without any nodejs installed.

For me, the latter was the most unexpected point: ff-63 introduced the
nodejs dependency and the failure seems to relate to 63 and to js, but at
least my problem was neither ff-63 nor nodejs but icu-63.

Uwe

[dueffert--- via blfs-dev]

Hi all,

Post by dueffert--- via blfs-dev

Post by Ken Moffat via blfs-dev
After the clang build (probably) fails, can you try commenting out
ac_add_options --with-system-icu

Thanks, that's it, at least for me: Build fails with system icu4c-63.1,
succeeds without --with-system-icu, and succeeds as well with system
icu4c-62.1 .

Worked for the moment, but wasn't really a solution. So I waited for
firefox-63.0.1, but that did not change anything. Then I digged for the
source of the problem - and it is rather easy:

The relevant difference between icu-62.1 and icu-63.1 is that the latter
started to have "checkImpl" in their public headers. Which conflicts with
some completely different "checkImpl" in Firefox.

The usage of "checkImpl" in Firefox is pretty limited and I can easiely
get Firefox-63 to build and work fine with system icu-63.1 by applying:
sed -e 's/checkImpl/checkFFImpl/g' -i js/src/vm/JSContext*.h

I have no clue what upstream thinks about that, but my gut feeling is that
"checkImpl" sounds way too general to be exported like that. So I suppose
it's icu which would need some fixing, but as I can't guess their
intention (or its consequences), it's way easier for me to just patch
Firefox to build.

I'd appreciate if someone more confident would report that at either
upstream project...

Uwe

[Ken Moffat via blfs-dev]

Post by dueffert--- via blfs-dev
Hi all,

Post by dueffert--- via blfs-dev

Post by Ken Moffat via blfs-dev
After the clang build (probably) fails, can you try commenting out
ac_add_options --with-system-icu

Thanks, that's it, at least for me: Build fails with system icu4c-63.1,
succeeds without --with-system-icu, and succeeds as well with system
icu4c-62.1 .

Worked for the moment, but wasn't really a solution. So I waited for
firefox-63.0.1, but that did not change anything. Then I digged for the

AFAICS, Bruce's scripts think that doesn't exist, so I'm ignoring it
;-) Seriously, I'm "up to my arse in alligators" [1] in the perl
modules, so -ENOCYCLES.

But for older systems with older icu it probably won't help - those
maybe need an updated icu, or to continue to use the shipped icu.

And I haven't yet had time to look at FF64-beta, so no idea if that
has moved to a newer icu (seems unlikely, mozilla like old things
such as Python2, but who knows ?)

Post by dueffert--- via blfs-dev
The relevant difference between icu-62.1 and icu-63.1 is that the latter
started to have "checkImpl" in their public headers. Which conflicts with
some completely different "checkImpl" in Firefox.
The usage of "checkImpl" in Firefox is pretty limited and I can easiely get
sed -e 's/checkImpl/checkFFImpl/g' -i js/src/vm/JSContext*.h
I have no clue what upstream thinks about that, but my gut feeling is that
"checkImpl" sounds way too general to be exported like that. So I suppose
it's icu which would need some fixing, but as I can't guess their intention
(or its consequences), it's way easier for me to just patch Firefox to
build.
I'd appreciate if someone more confident would report that at either
upstream project...
Uwe

Unfortunately, I have little motivation to report things to firefox,
it seems they only really care about windows users and I suspect
they regard me as a PITA using odd options and odd hardware (AMD
Ryzen). And no experience of dealing with icu.

Your suggestion seems a reasonable thing for somebody to try in
BLFS.

ĸen

1. Edmund Heep in cartoons by Posy Simmonds in "The Grauniad" years
ago, these seem to pre-date gurgle's world view.

[Ken Moffat via blfs-dev]

Post by Ken Moffat via blfs-dev

Post by dueffert--- via blfs-dev
Worked for the moment, but wasn't really a solution. So I waited for
firefox-63.0.1, but that did not change anything. Then I digged for the

AFAICS, Bruce's scripts think that doesn't exist, so I'm ignoring it
;-) Seriously, I'm "up to my arse in alligators" [1] in the perl
modules, so -ENOCYCLES.

Getting ready for a fresh build (my first with ICU-63) -

Post by Ken Moffat via blfs-dev

Post by dueffert--- via blfs-dev
The relevant difference between icu-62.1 and icu-63.1 is that the latter
started to have "checkImpl" in their public headers. Which conflicts with
some completely different "checkImpl" in Firefox.
The usage of "checkImpl" in Firefox is pretty limited and I can easiely get
sed -e 's/checkImpl/checkFFImpl/g' -i js/src/vm/JSContext*.h
I have no clue what upstream thinks about that, but my gut feeling is that
"checkImpl" sounds way too general to be exported like that. So I suppose
it's icu which would need some fixing, but as I can't guess their intention
(or its consequences), it's way easier for me to just patch Firefox to
build.
I'd appreciate if someone more confident would report that at either
upstream project...
Uwe

You did not mention that people using old ICU (e.g. 60) also had the
problem. Looking at firefox, it claims to include 59.1, but
presumably something has been altered in the local version.

Anyway, with 63.0.1 on BLFS-8.2 (ICU 60) that sed works. It also
works on this-week's 64 beta on an 8.3 / 62 system where it is not
needed, so I think we should just pick it up.

I'm now getting ready to build a fresh system (my first with ICU
63). Will see how it goes, there are other changes which might
break it.

ĸen

[dueffert--- via blfs-dev]

Post by Ken Moffat via blfs-dev
You did not mention that people using old ICU (e.g. 60) also had the
problem.

Because I do not agree with that: For me, firefox-63 built just fine
without patching with either its internal icu (ISTR despite system
icu-63) or with system icu-62. The problem arose from system icu-63
starting to export (no idea whether on purpose) its "checkImpl" AND
firefox including that.

Post by Ken Moffat via blfs-dev
Anyway, with 63.0.1 on BLFS-8.2 (ICU 60) that sed works. It also
works on this-week's 64 beta on an 8.3 / 62 system where it is not
needed, so I think we should just pick it up.

That was my intention: Without having to understand what either developers
intend to do with their "checkImpl", I can avoid the name clash without
side effects by renaming the Firefox internal one to e.g. "checkFFImpl".

Post by Ken Moffat via blfs-dev
I'm now getting ready to build a fresh system (my first with ICU
63). Will see how it goes,

Good luck.

Uwe

[Jean-Marc Pigeon via blfs-dev]

Hello Bruce, Ken, Xi and list

Bruce suggested me to look at XFCE as it should easier
to implement than LXQT, So I compiled XFCE all components.

I do not concur, XFCE depend on rustc (and rustc is an heavy
heavy package), as I reported previously I "drop rustc overboard" and
then implementation complexity, between LXQt and XFCE, is even.
I would give a small advantage to LXQT (the whole 0.13 LXQT
implementation can be describe within one BLFS page).

BLFS-8.1 project was using LXQT-0.11.1, I have for my say
0.13 is fare easier than 0.11 (upstream project cleaned
dependencies).

Easy to say, could we see that ourselves?

Sure!
Last night I recompiled the whole LFS project (LFS-8.3-1.4.0)
from scratch and made an ISO.

The ISO can be used as an LFS rescue tool or as an install tool.

Once you have the ISO (CD or USB), the whole install procedure
can be completed in less than 20 minutes (DHCP, a 50Mb/s link
and a >= 100G spare disk).
Once fully installed:
#df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 2.0G 4.0K 2.0G 1% /dev
/dev/md3 20G 5.6G 13G 30% /
tmpfs 2.0G 21M 2.0G 2% /run
/dev/md1 5.9G 63M 5.5G 2% /boot
/dev/md5 34G 1.5G 31G 5% /var
/dev/md6 157G 466M 148G 1% /home

You can chose to install release-lxqt and/or
release-XFCE.
Install can be done from remote, using ssh (very
convenient), provided you set a root password to
the live-ISO session.

On purpose, inittab is not set to level 5 when installing
graphic. To test graphic use sddm|startx|X.
Once you have validated Graphic, it is up to you to change inittab
from 3 to 5.
Caution you may need to install (yum install) xf86-video-...
according your hardware.


Ken: Installation include browser 'falkon', I found it quite
operational, could you confirm it is better now.
The only weakness, seems to be, certificates, while falkon
is able to handle them nicely, I was not able to find a
way to manage/display certificate contents.
Caution: On a GeForce GT 710, falkon crash as soon
trying to display an URL, It was needed to implement the
last proprietary Nvidia driver (standard "Nvidia-....run" procedure).
For other (more recent nvidia card) falkon is working fine.

Xi: package include, Simplified/traditional Chinese font +
Japanese and Korean one.
Could you check it (sddm allow to login in numerous language)
and tell us if result are practicable or not.


ISO+install, is (roughly) what I am using to work on LFS,
for the last for 6 month.

2 main packages are missing.
cups, and an email reader (Thunderbird??)

But.... there is one game included.
(:-}}} for sure, only purpose is to test 3D rending and sound effects)


ISO:
https://okrepo.safe.ca/osukiss/8.3/isos/LFS-8.3-1.4.0-rescue-x86_64.iso

All (564) packages available:
https://okrepo.safe.ca/osukiss/8.3/os-base/packages.listing

Sources (compilation flags, if you need)
https://okrepo.safe.ca/osukiss/8.3/os-base/srcrpm

The whole project:
http://www.osukiss.org

[Ken Moffat via blfs-dev]

Post by Jean-Marc Pigeon via blfs-dev
Ken: Installation include browser 'falkon', I found it quite
operational, could you confirm it is better now.

Apart from not opening a link which turned out to be a PDF (already
noted), I have not seen any recent problems.

Post by Jean-Marc Pigeon via blfs-dev
The only weakness, seems to be, certificates, while falkon
is able to handle them nicely, I was not able to find a
way to manage/display certificate contents.
Caution: On a GeForce GT 710, falkon crash as soon
trying to display an URL, It was needed to implement the
last proprietary Nvidia driver (standard "Nvidia-....run" procedure).
For other (more recent nvidia card) falkon is working fine.

I refuse to touch nvidia drivers, and after my experience with
nouveau on a GT710 (worked fine if Xorg not used, e.g. for a server,
disastrous for crashing if Xorg in use) and from reading reports
about the problems of using current nvidia cards with nouveau, I
will not again use nvidia cards on a desktop machine.

ĸen

[Jean-Marc Pigeon via blfs-dev]

Hello,

Post by Ken Moffat via blfs-dev

Post by Jean-Marc Pigeon via blfs-dev
Ken: Installation include browser 'falkon', I found it quite
operational, could you confirm it is better now.

Apart from not opening a link which turned out to be a PDF (already
noted), I have not seen any recent problems.

Good to know, my understanding was you found falkon not usable,
I must have read it incorrectly.

PDF problem, seems to be a missing tool for falkon
(https://www.reddit.com/r/kde/comments/9swk1h/pdf_reader_extension_for_falkon/)

Post by Ken Moffat via blfs-dev

Post by Jean-Marc Pigeon via blfs-dev
The only weakness, seems to be, certificates, while falkon
is able to handle them nicely, I was not able to find a
way to manage/display certificate contents.
Caution: On a GeForce GT 710, falkon crash as soon
trying to display an URL, It was needed to implement the
last proprietary Nvidia driver (standard "Nvidia-....run" procedure).
For other (more recent nvidia card) falkon is working fine.

I refuse to touch nvidia drivers, and after my experience with
nouveau on a GT710 (worked fine if Xorg not used, e.g. for a server,
disastrous for crashing if Xorg in use) and from reading reports
about the problems of using current nvidia cards with nouveau, I
will not again use nvidia cards on a desktop machine.

I was providing "pure data".

The implication is the nouveau driver was not working A_One
for "old" card as GT 710.
I found no trouble with the nouveau driver (from LFS) with
other nvidia card I have here.
ATI cards seem to be working fine too.

It is my understanding nvidia card are pretty common, so
my comment was rather to help someone using an,
old and on the side, PC to do some tests (sharing finding,
this is the whole purpose of a mailing list).

Post by Ken Moffat via blfs-dev
Äžen

[Alain Toussaint via blfs-dev]

Post by Jean-Marc Pigeon via blfs-dev

Post by Ken Moffat via blfs-dev

Post by Jean-Marc Pigeon via blfs-dev
Caution: On a GeForce GT 710, falkon crash as soon
trying to display an URL, It was needed to implement the
last proprietary Nvidia driver (standard "Nvidia-....run"
procedure).
For other (more recent nvidia card) falkon is working fine.

I refuse to touch nvidia drivers, and after my experience with
nouveau on a GT710 (worked fine if Xorg not used, e.g. for a
server,
disastrous for crashing if Xorg in use) and from reading reports
about the problems of using current nvidia cards with nouveau, I
will not again use nvidia cards on a desktop machine.

I was providing "pure data".
The implication is the nouveau driver was not working A_One
for "old" card as GT 710.
I found no trouble with the nouveau driver (from LFS) with
other nvidia card I have here.
ATI cards seem to be working fine too.
It is my understanding nvidia card are pretty common, so
my comment was rather to help someone using an,
old and on the side, PC to do some tests (sharing finding,
this is the whole purpose of a mailing list).

In my case, I have an old GTX 460 card in this workforce and I can
attest that in kernel 4.18.X, nouveau is unusable for me and matter of
fact, the 4.18.X serie of kernels are unuseable so I reverted back to
one of the long-terms, that is 4.14.78 which work fine under the
proprietary drivers. I haven't tested with nouveau under 4.14.78 but
I'll see if I can test soon.

Alain

[Bruce Dubbs via blfs-dev]

Post by Ken Moffat via blfs-dev

Post by Jean-Marc Pigeon via blfs-dev
Ken: Installation include browser 'falkon', I found it quite
operational, could you confirm it is better now.

Apart from not opening a link which turned out to be a PDF (already
noted), I have not seen any recent problems.

Post by Jean-Marc Pigeon via blfs-dev
The only weakness, seems to be, certificates, while falkon
is able to handle them nicely, I was not able to find a
way to manage/display certificate contents.
Caution: On a GeForce GT 710, falkon crash as soon
trying to display an URL, It was needed to implement the
last proprietary Nvidia driver (standard "Nvidia-....run" procedure).
For other (more recent nvidia card) falkon is working fine.

I refuse to touch nvidia drivers, and after my experience with
nouveau on a GT710 (worked fine if Xorg not used, e.g. for a server,
disastrous for crashing if Xorg in use) and from reading reports
about the problems of using current nvidia cards with nouveau, I
will not again use nvidia cards on a desktop machine.

My experience is quite different. I have been using

01:00.0 VGA compatible controller: NVIDIA GT218 [GeForce 210]

for several years on my development system using the nouveau driver with
absolutely no problems. On the other hand, I tried a Radeon RX460 in
the same system and could not get it to work satisfactorily without an
initrd to load firmware. That creates for me extra work for every new
kernel.

Not so recently I also experimented with the proprietary Nvidia driver,
but I don't like it because of it's requirement to rebuild the kernel
with every update.

-- Bruce

P.S. My workstation has Intel HD Graphics 530 on my i5-6500 and that
runs quite nicely.

[Ken Moffat via blfs-dev]

Post by Bruce Dubbs via blfs-dev

Post by Ken Moffat via blfs-dev
I refuse to touch nvidia drivers, and after my experience with
nouveau on a GT710 (worked fine if Xorg not used, e.g. for a server,
disastrous for crashing if Xorg in use) and from reading reports
about the problems of using current nvidia cards with nouveau, I
will not again use nvidia cards on a desktop machine.

My experience is quite different. I have been using
01:00.0 VGA compatible controller: NVIDIA GT218 [GeForce 210]
for several years on my development system using the nouveau driver with
absolutely no problems.

Because I had preferred integrated graphics, I only looked at what
was currently-available when I needed to specify a machine, and
after previous problems I wanted to get a pre-assembled machine.
The GT710 was low power, and cheap - it was only later that I found
the open nouveau bugs (and added some more). But currently-available
nvidia, at least for new systems, seems to mean 1060 or later which
apparently bring a lot of problems (need firmware, maybe cannot
sleep).

Post by Bruce Dubbs via blfs-dev
On the other hand, I tried a Radeon RX460 in the
same system and could not get it to work satisfactorily without an initrd to
load firmware. That creates for me extra work for every new kernel.

Having determined what firmware is needed for ATI cards, I currently
build it into the kernel. Yes, that takes a little time for the
first few build/boot/reconfigure cycles, but after that it merely
wastes about 72K of kernel memory (based on the sizes of the files
in /lib/firmware for the Caicos card (R5/230) now on this box.

Unfortunately, current separate amdgpu cards can use a lot more
power, and they also don't support vga monitors - I need to make a
lot of hardware changes before I can try them.

Post by Bruce Dubbs via blfs-dev
Not so recently I also experimented with the proprietary Nvidia driver, but
I don't like it because of it's requirement to rebuild the kernel with every
update.

Yes indeed, and since I try to test -rc kernels it is expected that
either the nvidia driver would no-longer build because of kernel
changes, or else that any bug report would tend to be "not our
problem unless you can replicate without the binary driver".

Post by Bruce Dubbs via blfs-dev
P.S. My workstation has Intel HD Graphics 530 on my i5-6500 and that runs
quite nicely.

Yes, I don't understand the fascination with "improved" graphics
cards, except for gamers and fgor bragging rights. I much prefer
lower power consumption in graphics.

ĸen

[Ken Moffat via blfs-dev]

Post by Ken Moffat via blfs-dev

Post by Jean-Marc Pigeon via blfs-dev
Ken: Installation include browser 'falkon', I found it quite
operational, could you confirm it is better now.

Apart from not opening a link which turned out to be a PDF (already
noted), I have not seen any recent problems.

And now for some thing to make Jean-Marc really happy ;-)

https://www.gimp.org/news/2018/11/08/gimp-2-10-8-released/

In the part labelled 'GIF is dead? Long live WebP' after

And last but not least, we remind everyone that GIMP has already
had WebP support since GIMP 2.10.0!

On falkon I can see the animation (a penguin and some furry animal
on a swing). On firefox I get text telling my that my browser does
not support WebP yet.

The previous text suggests it is fixed in ff65. I'll need to move
by build of libwebp earlier, to be ready.

ĸen

[Jean-Marc Pigeon via blfs-dev]

Post by Ken Moffat via blfs-dev

Post by Ken Moffat via blfs-dev

Post by Jean-Marc Pigeon via blfs-dev
Ken: Installation include browser 'falkon', I found it quite
operational, could you confirm it is better now.

Apart from not opening a link which turned out to be a PDF (already
noted), I have not seen any recent problems.

And now for some thing to make Jean-Marc really happy ;-)

:-}}}
Noted, Many Thanks.. It won't be right now, as there is many
dependencies on GIMP.
(working on LVM2, to do some experiments for now...).

So I'll be even happier with falkon :-}}

Post by Ken Moffat via blfs-dev
https://www.gimp.org/news/2018/11/08/gimp-2-10-8-released/
In the part labelled 'GIF is dead? Long live WebP' after
And last but not least, we remind everyone that GIMP has already
had WebP support since GIMP 2.10.0!
On falkon I can see the animation (a penguin and some furry animal
on a swing). On firefox I get text telling my that my browser does
not support WebP yet.
The previous text suggests it is fixed in ff65. I'll need to move
by build of libwebp earlier, to be ready.
Äžen

[Xi Ruoyao via blfs-dev]

Post by Jean-Marc Pigeon via blfs-dev
Xi: package include, Simplified/traditional Chinese font +
Japanese and Korean one.
Could you check it (sddm allow to login in numerous language)
and tell us if result are practicable or not.

I'll try this in 2-3 days. Now I'm busy drawing PCB :(. In the mean
time I can download the ISO.

[Ken Moffat via blfs-dev]

Post by Ken Moffat via blfs-dev
You did not mention that people using old ICU (e.g. 60) also had the
problem.

Because I do not agree with that: For me, firefox-63 built just fine without
patching with either its internal icu (ISTR despite system icu-63) or with
system icu-62. The problem arose from system icu-63 starting to export (no
idea whether on purpose) its "checkImpl" AND firefox including that.

I did not intend to describe either 62 or 61 as 'old ICU' in that
line. When the issue was first raised, I built ff-63.0 with system
icu of both those versions without problems.

But I had previously failed to build on 60 with the same problem.

Post by Ken Moffat via blfs-dev
Anyway, with 63.0.1 on BLFS-8.2 (ICU 60) that sed works. It also
works on this-week's 64 beta on an 8.3 / 62 system where it is not
needed, so I think we should just pick it up.

That was my intention: Without having to understand what either developers
intend to do with their "checkImpl", I can avoid the name clash without side
effects by renaming the Firefox internal one to e.g. "checkFFImpl".

Post by Ken Moffat via blfs-dev
I'm now getting ready to build a fresh system (my first with ICU
63). Will see how it goes,

Good luck.

Thanks.

ken

[Ken Moffat via blfs-dev]

I have 504 coredumps on this system (and it's not more than a couple weeks
old). A majority of them were due to ICE's (CPU was too new for it's quirks
to be covered in the kernel, as well as some Illegal Operation errors), but

[...]

As for the rest of my crashes, I've had three in lxpanel, several in
COGL/Clutter (I'm aware of those, have to update Mesa), and several in
wayland, GTK2, LLVM, ld, and ruby. This system hasn't been kind to me for
it's initial software load. I suppose I could do another build if absolutely
necessary, but I'd rather not, and they aren't related to Firefox-63.

Have you tried testing the RAM/setup with memtest86 ?

Unfortunately, testing that much RAM will take a long time - but
problems sometimes show up fairly frequently. Also check the
timings in the BIOS/EFI (assuming those are available) against what
the RAM claims.

On one old machine of mine (low-end) I get fairly-frequent ICE's
when compiling, in that case I suspect it slightly undervolts the
RAM and there is no option in the BIOS to change that. But there,
dropping the caches with 'echo 3 >/proc/sys/vm/drop-caches' and
retrying usually lets it compile.

ĸen

[dueffert--- via blfs-dev]

Hi,
so far I fail to build FF63 too (while 62.0.3 was fine)...

Post by Tim Tassonis via blfs-dev
This is with gcc 7.3.0 and the system_graphite2_harfbuzz-1 patch, but
without node.js

... with gcc 8.2.0 and with nodejs11 as well as with nodejs9 as well as
without. At first glance your particular error looks as if you were
missing
ac_add_options --disable-nodejs

but even with that the build still fails for me for less obvious
reason. So this is at least not a pure gcc 7.3 issue...

Uwe

[Ken Moffat via blfs-dev]

Post by dueffert--- via blfs-dev
Hi,
so far I fail to build FF63 too (while 62.0.3 was fine)...

Post by Tim Tassonis via blfs-dev
This is with gcc 7.3.0 and the system_graphite2_harfbuzz-1 patch, but
without node.js

... with gcc 8.2.0 and with nodejs11 as well as with nodejs9 as well as
without. At first glance your particular error looks as if you were missing
ac_add_options --disable-nodejs

I'll note that I used the version of nodejs which is in the book
(9.11.2).

Post by dueffert--- via blfs-dev
but even with that the build still fails for me for less obvious reason. So
this is at least not a pure gcc 7.3 issue...
Uwe

Ughh, this sounds problematic.

ĸen

[Tim Tassonis via blfs-dev]

Post by dueffert--- via blfs-dev
Hi,
so far I fail to build FF63 too (while 62.0.3 was fine)...

Post by Tim Tassonis via blfs-dev
This is with gcc 7.3.0 and the system_graphite2_harfbuzz-1 patch, but
without node.js

... with gcc 8.2.0 and with nodejs11 as well as with nodejs9 as well as
without. At first glance your particular error looks as if you were missing
ac_add_options --disable-nodejs
but even with that the build still fails for me for less obvious reason.
So this is at least not a pure gcc 7.3 issue...

Yeah, I tried both, with or without node.js. It's definitely not a
node.js issue.

I already googled the error message, but so far, no solutions popped up.
Maybe tomorrow, there'll be something, or mozilla will release 63.0.1
with a fix for this.

Bye
Tim

Post by dueffert--- via blfs-dev
Uwe