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: [email protected]
For additional commands, e-mail: [email protected]
