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?
Elmar
On 18.04.22 19:44, Elmar Stellnberger wrote:
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 -kestel...@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
