On Fri, 27 Oct 2017 13:23:25 -0500
gunnersky2...@gunnerhooper.tk wrote:
> File
> "/root/sources/firefox-52.4.1esr/toolkit/components/telemetry/gen-event-data.py",
> line 82, in write_common_event_table
> e.dataset),
> TypeError: %d format: a number is required, not float
Well, it looks like a ("simple") python issue to me and might not even
be related to older systems:
https://stackoverflow.com/questions/27030856/python-typeerror-d-format-a-number-is-required-not-nonetype
https://stackoverflow.com/questions/27324102/typeerror-d-format-a-number-is-required-not-getset-descriptor
https://stackoverflow.com/questions/34113421/pymysql-query-formatting-typeerror-d-format-a-number-is-required-not-str
It might be a good idea to ask some Python folks what is, or could be,
going wrong here. It also might be very helpful to insert some python
test code to print out all the affected field values to see what the
incorrectly passed value actually is.
But, given that I, like Ken, can't find any other example this particular
error on the net, it might be caused by a lack of RAM or SWAP problem.
It could also be triggered (only) by a very recent GCC. A hardware
problem is another possibility - most especially if the exact error
is not repeatable.
What does the Python code in gen-event-data.py", line 82, in
write_common_event_table look like? I think a (very similar,
newer version?) copy of it can be found online here:
https://github.com/mozilla/gecko-dev/blob/master/toolkit/components/telemetry/gen-event-data.py
From:
https://github.com/rg3/youtube-dl/issues/8299
note that this type of error happens when a nonnumerical option is
assigned a value that requires a number. e.g., --retries infinite
instead of --retries 100
Could anything like this be going on in your mozconfig or some
other typo in a setup/patch/config parameter?
On Fri, 27 Oct 2017 20:17:10 +0100
Ken Moffat <zarniwh...@ntlworld.com> wrote:
> I suspect there are no maintained graphical browsers which will work
> for you.
<rant>
IMHO, when buiding from source, non-SSE should always be an option even
if performance suffers as a result. Sometimes/often/always
requirements like this are simply the result of "lazy or indifferent"
developers rather the result of a real technical need.
</rant>
Anyway ...
I have some old notes on getting such things to work with older CPUs
that may be of help to someone. However, I have not tried any of this
with the most recent versions of packages, but I do suspect it will
still work.
For QT stuff, configure with the -no-sse2 option. For QtWebKit invoke
the --no-force-sse2 option.
Another, in my opinion better, option (given the enormous bloat of QT)
is WebkitGTK+ based browsers, especially Midori:
http://www.linuxfromscratch.org/blfs/view/svn/xsoft/midori.html
However, SSE instructions must be disable in WebkitGTK+. To do this,
apply the disable-jit-nonsse2.patch from debian:
https://packages.debian.org/source/sid/webkitgtk
found in webkitgtk_2.4.11-3.debian.tar.xz
http://http.debian.net/debian/pool/main/w/webkitgtk/webkitgtk_2.4.11-3.debian.tar.xz
*as well as* invoking the --disable-jit configure option
The Debian fix-ftbfs-gcc6.patch and x32_support.patch might also be
helpful/needed.
Those who have an older Xorg system might have to disable some other
things as well:
../configure --prefix=/usr --with-gtk=2.0 --disable-webkit2
--disable-gamepad --disable-webgl --disable-geolocation
--disable-glx --disable-accelerated-compositing
--disable-jit
The following won't be a problem for Gunnersky2002 because he is using
gcc 7.2.0, but just for the record here, some older versions of gcc
(pre 5.x series), may error with:
CXXLD libwebkitgtk-1.0.la
./.libs/../DerivedSources/WebInspectorUI/.libs/libWebCore_la-GResourceBundle.o:
In function `read':
GResourceBundle.c:(.text+0x0): multiple definition of `read'
which can be overcome by disabling -O2 and -D_FORTIFY_SOURCE=2
in CFLAGS - before running configure, edit .configure and
and change lines 21968-21982 from:
# Add the appropriate 'O' level for optimized builds.
if test "$enable_optimizations" = "yes"; then
CXXFLAGS="$CXXFLAGS -O2"
CFLAGS="$CFLAGS -O2"
if test "$c_compiler" = "gcc"; then
CFLAGS="$CFLAGS -D_FORTIFY_SOURCE=2"
fi
if test "$cxx_compiler" = "g++"; then
CXXFLAGS="$CXXFLAGS -D_FORTIFY_SOURCE=2"
fi
else
CXXFLAGS="$CXXFLAGS -O0"
CFLAGS="$CFLAGS -O0"
fi
to:
# Add the appropriate 'O' level for optimized builds.
if test "$enable_optimizations" = "yes"; then
CXXFLAGS="$CXXFLAGS -O1"
CFLAGS="$CFLAGS -O1"
else
CXXFLAGS="$CXXFLAGS -O0"
CFLAGS="$CFLAGS -O0"
fi
https://mail-index.netbsd.org/tech-pkg/2014/05/25/msg013114.html
Anyway, as Ken said, be sure you have at least 4GB of swap space lest
you encounter gcc errors such as "g++: internal compiler error".
In older machines of limited RAM, it might be helpful to provide
swap via a SSD drive, but I have not tested this so I don't know
what kind of performance increase can be expected from doing so.
Expect a WebkitGTK+ compilation time ranging from 12-48 hrs on
such old machines using a standard HD based swap.
Cheers,
Mike
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
