qt4 broken on i686

[Jan Palus]

On 19.09.2021 22:06, Jakub Bogusz wrote:
> On Sun, Sep 19, 2021 at 08:17:47PM +0200, Jan Rękorajski wrote:
> > On Thu, 19 Aug 2021, Jakub Bogusz wrote:
> > 
> > > On Wed, Aug 18, 2021 at 10:34:48PM +0200, Jan Rękorajski wrote:
> > > > New builds of qt4 on i686 exhibit crashes (ex. linguist in avogadro), or
> > > > infinite looping (ex. meinproc4 in kde4-kig).
> > > > 
> > > > I'm running out of ideas[1] and time to troubleshoot this and would
> > > > appreciate if anyone would be willing to try and figure out WTF is
> > > > broken there.
> > > > 
> > > > [1] neither -O0, nor -std=gnu98 seem to do the trick, it could be a
> > > > glibc 2.34 issue, but I don't have resources at hand to validate it.
> > > 
> > > I don't know yet if it's related to glibc, gcc or binutils, but simple
> > > testcase is searching in empty QMap:
> > > 
> > > ```
> > > #include <QtCore/QMap>
> > > 
> > > int main()
> > > {
> > >     QMap<int, std::string> mm;
> > >     mm.constFind(999);
> > > }
> > > ```
> > > 
> > > It hangs even on carme-x86_64.
> > > 
> > > Issue is probably related to shared_null static field (SIOF?)
> > 
> > My take is on gcc 11. I downgraded everything but gcc and it still crashed.
> > 
> > To verify that it's indeed gcc I need to rebuild it (gcc) locally due to
> > intertwined deps preventing simple package downgrade.
> 
> I tried to investigate the issue deeper - and the last I found was:
> 
> The symbol _ZN8QMapData11shared_nullE (demangled: QMapData::shared_null)
> resides both in executable (objdump -T from i686):
> 
> 0804c040 g    DO .bss   00000048  Base        _ZN8QMapData11shared_nullE
> 
> and libQtCore.so.4:
> 
> 002fa460 g    DO .data  00000048  Base        _ZN8QMapData11shared_nullE
> 
> 
> When compiled in current Th, the code in executable sees symbol mapped
> from executable and the library sees symbol mapped from library.
> 
> IIRC when compiled on slightly older system (qt4 built with gcc 7 or 8,
> glibc 2.33 etc.) in both cases symbol address was the same.
> 
> But in my current system (i686, glibc-2.34, binutils-2.37, gcc-8.4.0, qt4
> rebuilt in this environment) the result is the same as in Th: there are
> two instances of this symbol and testcase hangs.

Same findings here, workaround committed which makes avogadro compile
successfully. Root cause of this behavior still to be determined though.