[TRACKING] gcc 12 build failures

[Duncaen]

https://vasilek.cz/logs/gcc12-musl/bad/

• Carla
• The-Powder-Toy
• XQilla
• advancecomp
• afterstep
• amdvlk
• apl
• asignify
• attract
• barrier
• bctoolbox
• beignet
• bish
• blackboxwm
• blobby2
• bonnie++
• ccache
• cglm
• chromium
• clucene
• codeblocks
• codelite
• commoncpp2
• coreboot-utils
• cross-powerpc64le-linux-gnu
• cross-powerpcle-linux-gnu (marked broken)
• cross-x86_64-w64-mingw32
• darkice
• darkplaces
• edb-debugger
• electron19 (electron19: fix build with gcc 12 #40890)
• endless-sky-gl21
• facter
• ffmpeg
• flatbuffers
• fluxbox
• freeimage
• fsearch
• ghdl ghdl: update to 2.0.0. #40614
• glmark2
• glog
• gloox
• glslViewer
• goldendict
• grive2
• grub-customizer
• gstreamermm
• hashdeep
• htmlcxx
• igt-gpu-tools
• incron
• ipv6calc
• jigdo
• john
• juCi++
• kakoune
• kea
• kodi-addon-pvr-hts
• ldc ldc: build in 2 stages, update to 1.30.0 #40931
• leatherman
• libbitcoin-system
• libebml
• libgdal
• liblastfm-qt5
• libomxil-bellagio
• libpgf
• libreoffice
• linux4.14
• linux4.9
• lyx
• melonDS
• mercury
• mimic
• monero-gui
• mpdscribble
• msp430-toolchain
• netpgp
• network-ups-tools
• nmap
• ogmtools
• openbabel
• openjdk10-bootstrap
• openjdk9-bootstrap
• openmsx
• openmw
• opensc
• owncloudclient
• papi
• passwordsafe
• psensor
• qemu-user-static
• qemu
• qt5-doc
• qv4l2
• rdfind
• retroshare
• rlottie
• rmilter
• rocksdb
• rstudio
• singular
• slim
• snapper
• source-highlight
• subtitleeditor
• supertux2
• tab
• textadept
• textosaurus
• ucommon
• uhd
• unittest-cpp
• upx
• vtk
• xstow
• xwmfs
• yosys
• zeromq
• zynaddsubfx

[oreo639]

igt-gpu-tools

That should have been fixed here #39780.

Same for apl here: #39750

Edit: also coreboot-utils: 8ad38d9

[Anachron]

Can we tag maintainers or at least add their email addresses?
If I saw that correctly none of them is maintained by me.

[Duncaen]

No I don't want to have to wait 5 months because 100 different people fix minor issues.

[oreo639]

cross-powerpc64le-linux-gnu

I can't reproduce this build failure?

cross-powerpcle-linux-gnu

This is caused by glibc using big-endian specific instructions (that would normally trigger an exception in little-endian mode) that got blacklisted when assembling little-endian code in binutils 2.36.

Would it be best to just mark the package as broken for now?

cross-x86_64-w64-mingw32

That should be able to be fixed by updating it to gcc 12.2+:
gcc-mirror/gcc@de6f402
gcc-mirror/gcc@ad5d760

[dkwo]

singular should be fixed by #39866

[oreo639]

The qemu build failure is this: https://github.com/void-linux/void-packages/blob/master/srcpkgs/qemu/patches/musl-fix-sigevent-and-sigval_t.patch

The patch will need to be removed in the gcc12 PR.

Edit: this has been fixed in the gcc 12 PR.

[oreo639]

I was able to fix the build failure in openjdk10-bootstrap with gcc 12:
https://gist.github.com/oreo639/9fcd2f6736a84434a7678ba27b0c0e5e
However after that I get a build failure with glibc 2.36:
https://gist.github.com/oreo639/470e234e45134c56383bf722dd2d1ccb

[oreo639]

The ffmpeg build failure isn't related to gcc 12 and has already been resolved: #39648

Here is the libreoffice build failure on musl:

configure:23848: checking for CLucene/analysis/cjk/CJKAnalyzer.h
configure:23848: /usr/bin/ccache g++ -c -fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe   -DGLM_ENABLE_EXPERIMENTAL -DU_USING_ICU_NAMESPACE=1 -DGLM_ENABLE_EXPERIMENTAL -DU_USING_ICU_NAMESPACE=1  -fdebug-prefix-map=/builddir/libreoffice-7.3.3.2=.       conftest.cpp >&5
In file included from /usr/include/CLucene/debug/lucenebase.h:10,
                 from /usr/include/CLucene/SharedHeader.h:201,
                 from /usr/include/CLucene/StdHeader.h:20,
                 from /usr/include/CLucene.h:11,
                 from conftest.cpp:90:
/usr/include/CLucene/LuceneThreads.h:72:24: error: 'pthread_t' does not name a type
   72 |                 static _LUCENE_THREADID_TYPE _GetCurrentThreadId();
      |                        ^~~~~~~~~~~~~~~~~~~~~
/usr/include/CLucene/LuceneThreads.h:73:32: error: 'pthread_t' does not name a type
   73 |                         static _LUCENE_THREADID_TYPE CreateThread(luceneThreadStartRoutine* func, void* arg);
      |                                ^~~~~~~~~~~~~~~~~~~~~
/usr/include/CLucene/LuceneThreads.h:74:48: error: 'pthread_t' has not been declared
   74 |                         static void JoinThread(_LUCENE_THREADID_TYPE id);
      |                                                ^~~~~~~~~~~~~~~~~~~~~

(You'll need to use this patch: LibreOffice/core@f7e170e to fix a gpgme related configure error, since the function it checks for was removed)

Edit: rebuilding clucene fixes the issue so maybe the pthreads patch didn't get applied?
Edit 2: Yep 6af326e

[dkwo]

singular has now been updated, so it should be fine.

[oreo639]

The ldc build failure seems to be a segfault in ldc2.
Even after updating it still crashes.
The crash location I got was:
https://github.com/ldc-developers/ldc/blob/master/gen/target.cpp#L180

Program received signal SIGSEGV, Segmentation fault.
Target::_init (this=0xbc7d78 <target>, params=...) at /builddir/ldc-1.30.0/gen/target.cpp:180
180	    RealProperties.min_10_exp = -4931;
(gdb) 
(gdb) bt
#0  Target::_init (this=0xbc7d78 <target>, params=...)
    at /builddir/ldc-1.30.0/gen/target.cpp:180
#1  0x000000000081acfd in mars_mainBody(Param&, Array<char const*>&, Array<char const*>&) (params=..., files=..., libmodules=...)
    at /builddir/ldc-1.30.0/dmd/mars.d:336
#2  0x00000000009d1f0e in cppmain ()
    at /builddir/ldc-1.30.0/driver/main.cpp:1148
#3  0x000000000091a04d in _Dmain (_param_0=...)
    at /builddir/ldc-1.30.0/driver/main.d:27

Here is a snippet of the disas:

...
   0x000000000095e6ca <+1402>:	xor    %esi,%esi
   0x000000000095e6cc <+1404>:	mov    $0xaaf859,%edi
   0x000000000095e6d1 <+1409>:	fstpt  0x180(%rbx)
   0x000000000095e6d7 <+1415>:	call   0x913210 <_ZN7CTFloat5parseEPKcPb>
   0x000000000095e6dc <+1420>:	xor    %esi,%esi
   0x000000000095e6de <+1422>:	mov    $0xaaf864,%edi
   0x000000000095e6e3 <+1427>:	fstpt  0x190(%rbx)
   0x000000000095e6e9 <+1433>:	call   0x913210 <_ZN7CTFloat5parseEPKcPb>
   0x000000000095e6ee <+1438>:	movdqa 0x15138a(%rip),%xmm0        # 0xaafa80
   0x000000000095e6f6 <+1446>:	fstpt  0x1c0(%rbx)
=> 0x000000000095e6fc <+1452>:	movaps %xmm0,0x1d0(%rbx)

I assume this has to do with LLVM and libstdc++, alpine uses LLVM 14 although even after updating to that the crash still occurs (albeit in a slightly different place, but still in Target::_init()). I can also confirm that updating musl and using the gcc git snapshot alpine uses doesn't fix the crash either. The build failure also occurs with clang/clang++ and libstdc++ although when I try to build it with libc++ I get a bunch of undefined references to LLVM.

Also, sidenote but libexecinfo is broken on musl:
alpinelinux/aports@50795a1
Although removing it/stubbing it out didn't fix the issue it did stop libexecinfo from messing up the gdb backtrace.

EDIT 1: compiling ldc without using dmd works fine.

[oreo639]

ldc should be fixed by #41158