A FreeBSD user is trying to unbreak the ppc64 build and ran into an issue with the sot module. I dig into it pretty deeply and it looks to me like a gcc bug. It's reproducable in amd64. It seems to affect gcc10, gcc11, and gcc12 builds. The build failure does not happen with gcc9.
It is not limited to FreeBSD. I get the same failure on Debian bullseye: cc --version cc (Debian 10.2.1-6) 10.2.1 20210110 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [ build LNK ] Library/libsot.so /usr/bin/ld: /home/dl/aoo/openoffice/main/solver/4111/unxlngx6.pro/workdir/CxxObject/sot/source/sdstor/ucbstorage.o: in function `UCBStorage_Impl::Init()': ucbstorage.cxx:(.text+0x72b4): undefined reference to `non-virtual thunk to cppu::WeakImplHelper1<com::sun::star::io::XInputStream>::acquire()' collect2: error: ld returned 1 exit status The problem appears to be that gcc is getting confused when compiling line 1884 of ucbstorage.cxx. It ends up trying to call the thunk to the acquire() method of a non-existent class. That thunk isn't defined, so the linker bombs on the undefined symbol. If I replace the-c flag with -S to get the assembler output: Working version from gcc9: .loc 2 1884 77 is_stmt 0 view .LVU7397 leaq 48(%rsp), %rax movq %rax, 16(%rsp) movq 16(%rsp), %rdi leaq 32(%rsp), %rax movq %rax, 8(%rsp) .LEHB557: call _ZN10comphelper24getProcessServiceFactoryEv@PLT .LVL3431: .LEHE557: .loc 2 1884 79 discriminator 1 view .LVU7398 movq 48(%rsp), %r8 Broken version from newer gcc: .loc 2 1884 77 view .LVU6791 leaq -176(%rbp), %r13 .LVL3116: .LBB5707: .LBB5706: .LBB5705: .loc 12 134 14 view .LVU6792 movq %rdi, -192(%rbp) .loc 12 136 23 view .LVU6793 call _ZThn40_N4cppu15WeakImplHelper1IN3com3sun4star2io12XInputStreamE E7acquireEv .loc 12 xxx xxx refers to the Reference() template in com/sun/star/uno/Reference.hxx lines 134-136, which calls acquire(). It would be nice if someone could put together a trimmed test case and file a gcc bug report. I don't have any good ideas about patching the source to work around the bug while waiting for a gcc fix. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org