Re: qt4 broken on i686
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
> >
> > int main()
> > {
> > QMap 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 gDO .bss 0048 Base_ZN8QMapData11shared_nullE
and libQtCore.so.4:
002fa460 gDO .data 0048 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.
--
Jakub Boguszhttp://qboosh.pl/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [packages/icu/icu-67] - build icu67 packages, qt4 does not build correctly with gcc 11, so let's fulfill the icu dependenc
On Thu, 16 Sep 2021, Jan Palus wrote: > On 28.08.2021 10:46, baggins wrote: > > commit 2cee6d28a25b124dbe274691e5c3d5969b3514ec > > Author: Jan Rękorajski > > Date: Sat Aug 28 10:45:38 2021 +0200 > > > > - build icu67 packages, qt4 does not build correctly with gcc 11, so > > let's fulfill the icu dependency with this > > > > This package is somewhat problematic due to the way poldek works. On one > of my machines still with icu 67 that's what happened: > > harfbuzz-icu-2.8.2-1.x86_64 obsoleted by harfbuzz-icu-2.9.1-1.x86_64 > > > [256/384] > harfbuzz-icu-2.9.1-1.x86_64 marks libicu-69.1-1.x86_64 (cap > libicuuc.so.69()(64bit)) > libicu-67.1-1.x86_64 obsoleted by libicu-69.1-1.x86_64 >orphaned QtCore-4.8.7-28.x86_64 marks libicu67-67.1-4.x86_64 (cap libicu = > 67.1) > > QtCore pulled libicu67 to satisfy broken dep, but it also left plenty of > other packages depending on libicu in old version since libicu67 > satisfied broken dep. In other words upgrade of libicu to 69 does not > pull all packages that should be upgraded. This in turn will likely lead > to multiple libicu versions being loaded for a single application which > in turn means problems. That's unfortunate. I would happily get rid of this, but to do so, we need to figure a way to reliably rebuild qt using gcc 11 -- Jan Rękorajski| PLD/Linux SysAdm | bagginspld-linux.org | http://www.pld-linux.org/ ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: qt4 broken on i686
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
>
> int main()
> {
> QMap 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.
--
Jan Rękorajski| PLD/Linux
SysAdm | bagginspld-linux.org | http://www.pld-linux.org/
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
