For the oldstable distribution (buster), these problems have
been fixed in version 91.8.0esr-1~deb10u1.
For the oldstable distribution (buster), these problems have
been fixed in version 91.8.0esr-1~deb10u1.
Where can I get this from for buster and architecture i386? <http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz>
does not have it.
Friedhelm Waitzmann wrote:
The Firefox ESR91 series triggers an internal compiler errorFor the oldstable distribution (buster), these problems haveWhere can I get this from for buster and architecture i386?
been fixed in version 91.8.0esr-1~deb10u1.
<http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz>
does not have it.
with the GCC version included in Debian 10, so there's no build
available currently.
There's one for Debian 11 (where GCC builds it correctly), but
I'd instead suggest to switch to amd64 instead.
Cheers,
Moritz
The Firefox ESR91 series triggers an internal compiler error
with the GCC version included in Debian 10, so there's no build
available currently.
I am still using i386 on some machines. Isnt it possible to build with another gcc or to update gcc?
Friedhelm Waitzmann wrote:
For the oldstable distribution (buster), these problems have
been fixed in version 91.8.0esr-1~deb10u1.
Where can I get this from for buster and architecture i386?
<http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz>
does not have it.
The Firefox ESR91 series triggers an internal compiler error
with the GCC version included in Debian 10, so there's no build
available currently.
There's one for Debian 11 (where GCC builds it correctly),
but I'd instead suggest to switch to amd64 instead.
Friedhelm Waitzmann wrote:
For the oldstable distribution (buster), these problems have
been fixed in version 91.8.0esr-1~deb10u1.
Where can I get this from for buster and architecture i386?
<http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz>
does not have it.
The Firefox ESR91 series triggers an internal compiler error
with the GCC version included in Debian 10, so there's no build
available currently.
There's one for Debian 11 (where GCC builds it correctly), but
I'd instead suggest to switch to amd64 instead.
Cheers,
Moritz
On 09.04.22 23:31, Moritz Mhlenhoff wrote:
Friedhelm Waitzmann wrote:
For the oldstable distribution (buster), these problems have
been fixed in version 91.8.0esr-1~deb10u1.
Where can I get this from for buster and architecture i386?
<http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz>
does not have it.
The Firefox ESR91 series triggers an internal compiler error
with the GCC version included in Debian 10, so there's no build
available currently.
There's one for Debian 11 (where GCC builds it correctly), but
I'd instead suggest to switch to amd64 instead.
Cheers,
Moritz
Could it be that also other programs are affected by this issue?
I have been building Coan (one of my programs) recently on the OBS and it
did not build on Debian10/i586 giving an error at /usr/lib/qt5/bin/moc. The amd64 target did build well. Since all reasonable Qt programs use moc (Qts meta object compiler, see: signals) that would then mean that none of the Qt programs would build. Can that be true?
Are you running KDE programs on a Pentium 4?
How can that work without hardware acceleration?
export LIBGL_ALWAYS_SOFTWARE=1
On 14.04.22 10:52, Elmar Stellnberger wrote:
Could it be that also other programs are affected by this issue?
I have been building Coan (one of my programs) recently on the OBS and it did not build on Debian10/i586 giving an error at /usr/lib/qt5/bin/moc. The
amd64 target did build well. Since all reasonable Qt programs use moc (Qts
meta object compiler, see: signals) that would then mean that none of the Qt
programs would build. Can that be true?
I am still using Mageia 7 on an old PIV of mine and it has a
similar gcc. Neither does there appear to be a problem with
Firefox. Anyone knows if the same issue appears with other
distros as well?
On Sat, Apr 09, 2022 at 11:31:01PM +0200, Moritz Mhlenhoff wrote:** 4:8.3.0-1 being offered by
Friedhelm Waitzmann wrote:
For the oldstable distribution (buster), these problems have
been fixed in version 91.8.0esr-1~deb10u1.
Where can I get this from for buster and architecture i386? <http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz>
does not have it.
The Firefox ESR91 series triggers an internal compiler error
with the GCC version included in Debian 10, so there's no build
available currently.
I am also running Debian 10 on my Asus eeePC (Pentium M). I
am mainly using it as a dictionary. Although I am performing
security updates quite regularely I have not run into this
issue. Having updated just now I am with Firefox
78.15.0-esr-1~deb10u1 and with
apt-cache.
Have I missed something or is the problem already resolved?
Friedhelm Waitzmann wrote:
For the oldstable distribution (buster), these problems have
been fixed in version 91.8.0esr-1~deb10u1.
Where can I get this from for buster and architecture i386? <http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz>
does not have it.
The Firefox ESR91 series triggers an internal compiler error
with the GCC version included in Debian 10, so there's no build
available currently.
I am also running Debian 10 on my Asus eeePC (Pentium M). I** gcc 4:8.3.0-1 being offered by
am mainly using it as a dictionary. Although I am performing
security updates quite regularly I have not run into this
issue. Having updated just now I am with Firefox
78.15.0-esr-1~deb10u1 and with
Where can I get this from for buster and architecture i386?
does not have it.
Package : firefox-esrCVE-2022-28281
CVE ID : CVE-2022-1097 CVE-2022-1196 CVE-2022-24713
CVE-2022-28282 CVE-2022-28285 CVE-2022-28286CVE-2022-28289
Multiple security issues have been found in the Mozilla Firefox web
browser, which could potentially result in the execution of arbitrary
code, information disclosure or spoofing.
For the oldstable distribution (buster), these problems have been fixed
in version 91.8.0esr-1~deb10u1.
For the stable distribution (bullseye), these problems have been fixed in version 91.8.0esr-1~deb11u1.
We recommend that you upgrade your firefox-esr packages.
Where can I get this from for buster and architecture i386?
<http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz>
does not have it.
Friedhelm, how have you taken notice about this issue?
Was the file really not there or do you think you have forgotten to
type firefox-esr instead of firefox or something the like?
[…]Package : firefox-esr
CVE ID : CVE-2022-1097 CVE-2022-1196 CVE-2022-24713
CVE-2022-28281 CVE-2022-28282 CVE-2022-28285
CVE-2022-28286 CVE-2022-28289
Multiple security issues have been found in the Mozilla
Firefox web browser,
[…]For the oldstable distribution (buster), these problems have
been fixed in version 91.8.0esr-1~deb10u1.
We recommend that you upgrade your firefox-esr packages.
At me it apparently has really kept an old unfixed version.
The message says fixed for oldstable, not mentioning that the fix has
not yet been achieved for i386 and that it was only applied to amd64.
...
exist. It truely is this g++ bug that prevents Firefox and any
Qt programs from building under Buster/i586. I have noted that
there are also some amd64 targets on the OBS that expose the
exact same g++ bug. My question would be on why the fixup/patch
from amd64 can not be used for g++/i386 on Debian?
On Fri, Apr 15, 2022 at 04:52:55PM +0200, Elmar Stellnberger wrote:
...
exist. It truely is this g++ bug that prevents Firefox and any
Qt programs from building under Buster/i586. I have noted that
there are also some amd64 targets on the OBS that expose the
exact same g++ bug. My question would be on why the fixup/patch
from amd64 can not be used for g++/i386 on Debian?
May I see what has fixed the issue for amd64 on Debian10 /
Buster? That may greatly facilitate the development for a patch
on i386. I believe the issue should really be fixed.
Elmar
Given that this should not be possible for some reason, please
share your knowledge about these bugs, so that people like me
can try to find a fix.
Elmar
It is possible; if someone tracks down the respective GCC change and backports
it to GCC 8 in Buster or alternatively lands a patch in the ESR91 branch which changes the code to no longer trigger the ICE, that would fix it.
But realistically the number of people who actively care about i386 support is
really, really small so I wouldn't count on it...
Cheers,
Moritz
I have now downloaded the source package and examined the backtrace
of building Firefox and examined all the differences between gcc 8.3.0-1 (known bad from Debian10) and gcc 9.2.0 with gcc 9.2.1 being known to be
good for moc/Qt5 from Ubuntu 19.10. There was only one difference I
found along the backtrace for gcc and I have documented this in the
following gcc/g++ bug report. You can also download the patch from here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293
I have rebuilt with the posted patch and the output has shown me that
all package files must have been created successfully:
Build Dependencies:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture
Description +++-=========================-======================-============-===============================================================================
ii binutils 2.31.1-16 i386 GNU
assembler, linker and binary utilities
ii binutils-common:i386 2.31.1-16 i386 Common
files for the GNU assembler, linker and binary utilities
ii binutils-hppa64-linux-gnu 2.31.1-16 i386 GNU
assembler, linker and binary utilities targeted for hppa64-linux
ii binutils-i686-linux-gnu 2.31.1-16 i386 GNU
binary utilities, for i686-linux-gnu target
ii g++-8 8.3.0-6 i386 GNU
C++ compiler
ii g++-8-dbgsym 8.3.0-6 i386 debug
symbols for g++-8
ii g++-8-multilib 8.3.0-6 i386 GNU
C++ compiler (multilib support)
ii g++-multilib 4:8.3.0-1 i386 GNU
C++ compiler (multilib files)
ii libc6:i386 2.28-10+deb10u1 i386 GNU C
Library: Shared libraries
ii libgmp-dev:i386 2:6.1.2+dfsg-4+deb10u1 i386 Multiprecision
arithmetic library developers tools
ii libisl-dev:i386 0.20-2 i386 manipulating
sets and relations of integer points bounded by linear constraints
ii libmpc-dev:i386 1.1.0-1 i386 multiple
precision complex floating-point library development package
ii libmpfr-dev:i386 4.0.2-1 i386 multiple
precision floating-point computation developers tools
(from gcc-bug:, this is terror by Western secret services, as also
referenced by elstel.org/DualSat) "I have looked into the same directory
as before but unfortunately I found not a single .deb there and nowhere
else under /usr/src. The files can only have been deleted like the ssh
user from /etc/passwd at my nslu2 machine. Another time I found out
about a chmod -x /etc/init.d/sshd as I suddenly could not connect to my
nslu2 via ssh any more. This looks very similar as what I have
experienced with arm-linux-gnueabihf-ld when the program did neither
produce an error message, an !=0 return value and no output file as
given with -o txtfmt."
If you know programs like gcc or the linker ld, then you know they
will always produce an error message if something fails. Even if there
was a bug in ld to display no error it would have returned a non-zero
exit status. Anyone who has worked with tools like gcc or ld/collect2
knows that. I have really searched for a txtfmt/a.out everywhere possible.
I am quite sure that the posted patch would resolve the issue. I
would appreciate it very much if someone was ready to compile that with
a Debian10/i386 chroot:
as root:
; debootstrap --arch i386 buster /dst/dbuster-i386
; xchroot /dst/dbuster-i386
; ... install build-essential apt-src locales-all etc.
; cd /usr/src
; apt-src update
; apt-src install gcc-8
Compiling may need more than a day; however you may hibernate in
between. Make sure you have copied the patch into
gcc-8-8.3.0/debian/patches/ and check that file has been patched some
good minutes after compilation has started:
grep "chkp_reset_rtl_bounds ();" gcc-8-8.3.0/src/gcc/cfgexpand.c || echo ok
before it should not echo ok but the line with chkp_reset_rtl_bounds
invoke the build inside the gcc-8-8.3.0 directory:
dpkg-buildpackage -b -uc -us [-nc] 2>&1 | tee compile-gcc.msg
// -b ... build binary
// -uc -us ... do not sign (I use -kestellnb@elstel.org, see gpg
--list-keys)
You can stop as soon as it has created the .deb packages. Grep for a
line like "ii.*libgmp-dev:i386" in compile-gcc.msg to find that out. Do
not forget to shield the + characters of g++ i.e. grep
"g[+][+]-8-multilib "
It will be of great help if anyone decides to do so!
Remember it should resolve several dependent bugs in Buster/i586 and
also distributions of similar time.
Regards,
Elmar
On 16.04.22 17:20, Odo Poppinger wrote:
Why not?
On 16.04.22 16:05, Elmar Stellnberger wrote:
; Given that this should not be possible for some reason, please
share your knowledge about these bugs, so that people like me
can try to find a fix.
;
Elmar
On 11.04.22 23:57, Moritz Muehlenhoff wrote:
It is possible; if someone tracks down the respective GCC change and
backports
it to GCC 8 in Buster or alternatively lands a patch in the ESR91 branch >>> which changes the code to no longer trigger the ICE, that would fix it.
But realistically the number of people who actively care about i386
support is
really, really small so I wouldn't count on it...
Cheers,
Moritz
Why not?
On 16.04.22 16:05, Elmar Stellnberger wrote:
Given that this should not be possible for some reason, please
share your knowledge about these bugs, so that people like me
can try to find a fix.
Elmar
On 11.04.22 23:57, Moritz Muehlenhoff wrote:
It is possible; if someone tracks down the respective GCC change and
backports
it to GCC 8 in Buster or alternatively lands a patch in the ESR91 branch
which changes the code to no longer trigger the ICE, that would fix it.
But realistically the number of people who actively care about i386
support is
really, really small so I wouldn't count on it...
Cheers,
Moritz
Likely it is possible to comment out the tournament checks after
compilation (which did not succeed to find this error any way) in debian/rules; I would do it like this:
check:
check22: $(check_stamp)
$(check_stamp): $(build_stamp)
$(MAKE) -f debian/rules2 $@
(here I have renamed check into check22 and created a new empty check goal) That should save 80% of the compilation time.
Elmar
On 17.04.22 17:46, Elmar Stellnberger wrote:
I have now downloaded the source package and examined the backtrace
of building Firefox and examined all the differences between gcc
8.3.0-1 (known bad from Debian10) and gcc 9.2.0 with gcc 9.2.1 being
known to be good for moc/Qt5 from Ubuntu 19.10. There was only one
difference I found along the backtrace for gcc and I have documented
this in the following gcc/g++ bug report. You can also download the
patch from here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293
I have rebuilt with the posted patch and the output has shown me that
all package files must have been created successfully:
Build Dependencies:
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend >>
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture
Description
+++-=========================-======================-============-===============================================================================
ii binutils 2.31.1-16 i386 GNU
assembler, linker and binary utilities
ii binutils-common:i386 2.31.1-16 i386 >> Common files for the GNU assembler, linker and binary utilities
ii binutils-hppa64-linux-gnu 2.31.1-16 i386 GNU
assembler, linker and binary utilities targeted for hppa64-linux
ii binutils-i686-linux-gnu 2.31.1-16 i386 GNU
binary utilities, for i686-linux-gnu target
ii g++-8 8.3.0-6 i386 GNU
C++ compiler
ii g++-8-dbgsym 8.3.0-6 i386
debug symbols for g++-8
ii g++-8-multilib 8.3.0-6 i386 GNU
C++ compiler (multilib support)
ii g++-multilib 4:8.3.0-1 i386 GNU
C++ compiler (multilib files)
ii libc6:i386 2.28-10+deb10u1 i386 GNU
C Library: Shared libraries
ii libgmp-dev:i386 2:6.1.2+dfsg-4+deb10u1 i386
Multiprecision arithmetic library developers tools
ii libisl-dev:i386 0.20-2 i386 manipulating
sets and relations of integer points bounded by linear constraints
ii libmpc-dev:i386 1.1.0-1 i386 multiple
precision complex floating-point library development package
ii libmpfr-dev:i386 4.0.2-1 i386 multiple
precision floating-point computation developers tools
(from gcc-bug:, this is terror by Western secret services, as also
referenced by elstel.org/DualSat) "I have looked into the same
directory as before but unfortunately I found not a single .deb there
and nowhere else under /usr/src. The files can only have been deleted
like the ssh user from /etc/passwd at my nslu2 machine. Another time I
found out about a chmod -x /etc/init.d/sshd as I suddenly could not
connect to my nslu2 via ssh any more. This looks very similar as what
I have experienced with arm-linux-gnueabihf-ld when the program did
neither produce an error message, an !=0 return value and no output
file as given with -o txtfmt."
If you know programs like gcc or the linker ld, then you know they
will always produce an error message if something fails. Even if there
was a bug in ld to display no error it would have returned a non-zero
exit status. Anyone who has worked with tools like gcc or ld/collect2
knows that. I have really searched for a txtfmt/a.out everywhere
possible.
I am quite sure that the posted patch would resolve the issue. I
would appreciate it very much if someone was ready to compile that
with a Debian10/i386 chroot:
as root:
> debootstrap --arch i386 buster /dst/dbuster-i386
> xchroot /dst/dbuster-i386
> ... install build-essential apt-src locales-all etc.
> cd /usr/src
> apt-src update
> apt-src install gcc-8
Compiling may need more than a day; however you may hibernate in
between. Make sure you have copied the patch into
gcc-8-8.3.0/debian/patches/ and check that file has been patched some
good minutes after compilation has started:
grep "chkp_reset_rtl_bounds ();" gcc-8-8.3.0/src/gcc/cfgexpand.c ||
echo ok
before it should not echo ok but the line with chkp_reset_rtl_bounds
invoke the build inside the gcc-8-8.3.0 directory:
dpkg-buildpackage -b -uc -us [-nc] 2>&1 | tee compile-gcc.msg
// -b ... build binary
// -uc -us ... do not sign (I use -kestellnb@elstel.org, see gpg
--list-keys)
You can stop as soon as it has created the .deb packages. Grep for
a line like "ii.*libgmp-dev:i386" in compile-gcc.msg to find that out.
Do not forget to shield the + characters of g++ i.e. grep
"g[+][+]-8-multilib "
It will be of great help if anyone decides to do so!
Remember it should resolve several dependent bugs in Buster/i586 and
also distributions of similar time.
Regards,
Elmar
On 16.04.22 17:20, Odo Poppinger wrote:
Why not?
On 16.04.22 16:05, Elmar Stellnberger wrote:
; Given that this should not be possible for some reason, please >>> > share your knowledge about these bugs, so that people like me
can try to find a fix.
;
Elmar
On 11.04.22 23:57, Moritz Muehlenhoff wrote:
It is possible; if someone tracks down the respective GCC change and
backports
it to GCC 8 in Buster or alternatively lands a patch in the ESR91
branch
which changes the code to no longer trigger the ICE, that would fix it. >>>>
But realistically the number of people who actively care about i386
support is
really, really small so I wouldn't count on it...
Cheers,
Moritz
I have now downloaded the source package and examined the backtrace
of building Firefox and examined all the differences between gcc 8.3.0-1 (known bad from Debian10) and gcc 9.2.0 with gcc 9.2.1 being known to be
good for moc/Qt5 from Ubuntu 19.10. There was only one difference I
found along the backtrace for gcc and I have documented this in the
following gcc/g++ bug report. You can also download the patch from here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293
I have rebuilt with the posted patch and the output has shown me that
all package files must have been created successfully:
Build Dependencies:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture
Description +++-=========================-======================-============-===============================================================================
ii binutils 2.31.1-16 i386 GNU
assembler, linker and binary utilities
ii binutils-common:i386 2.31.1-16 i386 Common
files for the GNU assembler, linker and binary utilities
ii binutils-hppa64-linux-gnu 2.31.1-16 i386 GNU
assembler, linker and binary utilities targeted for hppa64-linux
ii binutils-i686-linux-gnu 2.31.1-16 i386 GNU
binary utilities, for i686-linux-gnu target
ii g++-8 8.3.0-6 i386 GNU
C++ compiler
ii g++-8-dbgsym 8.3.0-6 i386 debug
symbols for g++-8
ii g++-8-multilib 8.3.0-6 i386 GNU
C++ compiler (multilib support)
ii g++-multilib 4:8.3.0-1 i386 GNU
C++ compiler (multilib files)
ii libc6:i386 2.28-10+deb10u1 i386 GNU C
Library: Shared libraries
ii libgmp-dev:i386 2:6.1.2+dfsg-4+deb10u1 i386 Multiprecision
arithmetic library developers tools
ii libisl-dev:i386 0.20-2 i386 manipulating
sets and relations of integer points bounded by linear constraints
ii libmpc-dev:i386 1.1.0-1 i386 multiple
precision complex floating-point library development package
ii libmpfr-dev:i386 4.0.2-1 i386 multiple
precision floating-point computation developers tools
(from gcc-bug:, this is terror by Western secret services, as also
referenced by elstel.org/DualSat) "I have looked into the same directory
as before but unfortunately I found not a single .deb there and nowhere
else under /usr/src. The files can only have been deleted like the ssh
user from /etc/passwd at my nslu2 machine. Another time I found out
about a chmod -x /etc/init.d/sshd as I suddenly could not connect to my
nslu2 via ssh any more. This looks very similar as what I have
experienced with arm-linux-gnueabihf-ld when the program did neither
produce an error message, an !=0 return value and no output file as
given with -o txtfmt."
If you know programs like gcc or the linker ld, then you know they
will always produce an error message if something fails. Even if there
was a bug in ld to display no error it would have returned a non-zero
exit status. Anyone who has worked with tools like gcc or ld/collect2
knows that. I have really searched for a txtfmt/a.out everywhere possible.
I am quite sure that the posted patch would resolve the issue. I
would appreciate it very much if someone was ready to compile that with
a Debian10/i386 chroot:
as root:
; debootstrap --arch i386 buster /dst/dbuster-i386
; xchroot /dst/dbuster-i386
; ... install build-essential apt-src locales-all etc.
; cd /usr/src
; apt-src update
; apt-src install gcc-8
Compiling may need more than a day; however you may hibernate in
between. Make sure you have copied the patch into
gcc-8-8.3.0/debian/patches/ and check that file has been patched some
good minutes after compilation has started:
grep "chkp_reset_rtl_bounds ();" gcc-8-8.3.0/src/gcc/cfgexpand.c || echo ok
before it should not echo ok but the line with chkp_reset_rtl_bounds
invoke the build inside the gcc-8-8.3.0 directory:
dpkg-buildpackage -b -uc -us [-nc] 2>&1 | tee compile-gcc.msg
// -b ... build binary
// -uc -us ... do not sign (I use -kestellnb@elstel.org, see gpg
--list-keys)
You can stop as soon as it has created the .deb packages. Grep for a
line like "ii.*libgmp-dev:i386" in compile-gcc.msg to find that out. Do
not forget to shield the + characters of g++ i.e. grep
"g[+][+]-8-multilib "
It will be of great help if anyone decides to do so!
Remember it should resolve several dependent bugs in Buster/i586 and
also distributions of similar time.
Regards,
Elmar
On 16.04.22 17:20, Odo Poppinger wrote:
Why not?
On 16.04.22 16:05, Elmar Stellnberger wrote:
; Given that this should not be possible for some reason, please
share your knowledge about these bugs, so that people like me
can try to find a fix.
;
Elmar
On 11.04.22 23:57, Moritz Muehlenhoff wrote:
It is possible; if someone tracks down the respective GCC change and
backports
it to GCC 8 in Buster or alternatively lands a patch in the ESR91 branch >>> which changes the code to no longer trigger the ICE, that would fix it.
But realistically the number of people who actively care about i386
support is
really, really small so I wouldn't count on it...
Cheers,
Moritz
The patch from yesterday could be tested by manually shipping the executable. Today I have developed another patch (since the first one
did not resolve it), one that compares against the backtrace with Debian
11 which is known to have a working gcc. The assumption that the Firefox
and Qt5/moc bug both have gcc as a cause is likely not valid as Firefox stopped with an internal compiler error while moc may produce spurious
output for some totally different reason.
You can find the new patch here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293
However this time absolutely no chance to test it by me! Compilation
did not work though only one line of source had been moved up and even a safety copy of the old g++ got deleted at me (and I have not done that).
On 17.04.22 17:46, Elmar Stellnberger wrote:
I have now downloaded the source package and examined the backtrace
of building Firefox and examined all the differences between gcc
8.3.0-1 (known bad from Debian10) and gcc 9.2.0 with gcc 9.2.1 being
known to be good for moc/Qt5 from Ubuntu 19.10. There was only one
difference I found along the backtrace for gcc and I have documented
this in the following gcc/g++ bug report. You can also download the
patch from here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293
I have rebuilt with the posted patch and the output has shown me that
all package files must have been created successfully:
Build Dependencies:
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend >>
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture
Description
+++-=========================-======================-============-===============================================================================
ii binutils 2.31.1-16 i386 GNU
assembler, linker and binary utilities
ii binutils-common:i386 2.31.1-16 i386 >> Common files for the GNU assembler, linker and binary utilities
ii binutils-hppa64-linux-gnu 2.31.1-16 i386 GNU
assembler, linker and binary utilities targeted for hppa64-linux
ii binutils-i686-linux-gnu 2.31.1-16 i386 GNU
binary utilities, for i686-linux-gnu target
ii g++-8 8.3.0-6 i386 GNU
C++ compiler
ii g++-8-dbgsym 8.3.0-6 i386
debug symbols for g++-8
ii g++-8-multilib 8.3.0-6 i386 GNU
C++ compiler (multilib support)
ii g++-multilib 4:8.3.0-1 i386 GNU
C++ compiler (multilib files)
ii libc6:i386 2.28-10+deb10u1 i386 GNU
C Library: Shared libraries
ii libgmp-dev:i386 2:6.1.2+dfsg-4+deb10u1 i386
Multiprecision arithmetic library developers tools
ii libisl-dev:i386 0.20-2 i386 manipulating
sets and relations of integer points bounded by linear constraints
ii libmpc-dev:i386 1.1.0-1 i386 multiple
precision complex floating-point library development package
ii libmpfr-dev:i386 4.0.2-1 i386 multiple
precision floating-point computation developers tools
(from gcc-bug:, this is terror by Western secret services, as also
referenced by elstel.org/DualSat) "I have looked into the same
directory as before but unfortunately I found not a single .deb there
and nowhere else under /usr/src. The files can only have been deleted
like the ssh user from /etc/passwd at my nslu2 machine. Another time I
found out about a chmod -x /etc/init.d/sshd as I suddenly could not
connect to my nslu2 via ssh any more. This looks very similar as what
I have experienced with arm-linux-gnueabihf-ld when the program did
neither produce an error message, an !=0 return value and no output
file as given with -o txtfmt."
If you know programs like gcc or the linker ld, then you know they
will always produce an error message if something fails. Even if there
was a bug in ld to display no error it would have returned a non-zero
exit status. Anyone who has worked with tools like gcc or ld/collect2
knows that. I have really searched for a txtfmt/a.out everywhere
possible.
I am quite sure that the posted patch would resolve the issue. I
would appreciate it very much if someone was ready to compile that
with a Debian10/i386 chroot:
as root:
> debootstrap --arch i386 buster /dst/dbuster-i386
> xchroot /dst/dbuster-i386
> ... install build-essential apt-src locales-all etc.
> cd /usr/src
> apt-src update
> apt-src install gcc-8
Compiling may need more than a day; however you may hibernate in
between. Make sure you have copied the patch into
gcc-8-8.3.0/debian/patches/ and check that file has been patched some
good minutes after compilation has started:
grep "chkp_reset_rtl_bounds ();" gcc-8-8.3.0/src/gcc/cfgexpand.c ||
echo ok
before it should not echo ok but the line with chkp_reset_rtl_bounds
invoke the build inside the gcc-8-8.3.0 directory:
dpkg-buildpackage -b -uc -us [-nc] 2>&1 | tee compile-gcc.msg
// -b ... build binary
// -uc -us ... do not sign (I use -kestellnb@elstel.org, see gpg
--list-keys)
You can stop as soon as it has created the .deb packages. Grep for
a line like "ii.*libgmp-dev:i386" in compile-gcc.msg to find that out.
Do not forget to shield the + characters of g++ i.e. grep
"g[+][+]-8-multilib "
It will be of great help if anyone decides to do so!
Remember it should resolve several dependent bugs in Buster/i586 and
also distributions of similar time.
Regards,
Elmar
On 16.04.22 17:20, Odo Poppinger wrote:
Why not?
On 16.04.22 16:05, Elmar Stellnberger wrote:
; Given that this should not be possible for some reason, please >>> > share your knowledge about these bugs, so that people like me
can try to find a fix.
;
Elmar
On 11.04.22 23:57, Moritz Muehlenhoff wrote:
It is possible; if someone tracks down the respective GCC change and
backports
it to GCC 8 in Buster or alternatively lands a patch in the ESR91
branch
which changes the code to no longer trigger the ICE, that would fix it. >>>>
But realistically the number of people who actively care about i386
support is
really, really small so I wouldn't count on it...
Cheers,
Moritz
Today I have received response on my g++ bug report at gcc.gnu.org.
Gcc 8.3.0 as used in Debian 10 is no longer supported as the 8 branch
has a newer version which is gcc 8.5. Why do Debian maintainers not
update gcc, if there is a known bug that prevents updated sources like firefox-esr-91.8.0 from building?
apt-get upgradePaketlisten werden gelesen... Fertig
Friedhelm Waitzmann wrote:
For the oldstable distribution (buster), these problems have
been fixed in version 91.8.0esr-1~deb10u1.
Where can I get this from for buster and architecture i386?
<http://security.debian.org/debian-security/dists/buster/updates/main/binary-i386/Packages.xz>
does not have it.
The Firefox ESR91 series triggers an internal compiler error
with the GCC version included in Debian 10, so there's no build
available currently.
There's one for Debian 11 (where GCC builds it correctly), but
I'd instead suggest to switch to amd64 instead.
Cheers,
Moritz
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 09:24:03 |
| Calls: | 6,666 |
| Files: | 12,213 |
| Messages: | 5,336,266 |