Adhemerval Zanella Netto via Libc-stable <libc-stable@sourceware.org> writes:

> On 06/06/24 15:49, Reilly Brogan wrote:
>> We updated the glibc package on Solus to the latest in the 2.39
>> stable branch last week and started seeing build failures in other
>> packages. A git bisect revealed that
>> dd535f4f19ef2b5c367a362af445ecadcf45401e
>> <https://sourceware.org/git/?p=glibc.git;a=commit;h=dd535f4f19ef2b5c367a362af445ecadcf45401e>
>> was the first broken commit.
>> 
>> Error messages look like this (open-vm-tools 12.4.0):
>> ```
>> libtool: link: x86_64-solus-linux-gcc -shared  -fPIC -DPIC
>> .libs/libvmtools_la-i18n.o .libs/libvmtools_la-monotonicTimer.o
>> .libs/libvmtools_la-signalSource.o .libs/libvmtools_la-vmtools.o
>> .libs/libvmtools_la-vmtoolsConfig.o .libs/libvmtools_la-vmtoolsLog.o
>> .libs/libvmtools_la-vmxLogger.o .libs/libvmtools_la-stub-log.o 
>> -Wl,--whole-archive ../lib/lock/.libs/libLock.a
>> ../lib/backdoor/.libs/libBackdoor.a
>> ../lib/asyncsocket/.libs/libAsyncSocket.a
>> ../lib/sslDirect/.libs/libSslDirect.a
>> ../lib/pollGtk/.libs/libPollGtk.a ../lib/poll/.libs/libPoll.a
>> ../lib/dataMap/.libs/libDataMap.a ../lib/hashMap/.libs/libHashMap.a
>> ../lib/dict/.libs/libDict.a ../lib/dynxdr/.libs/libDynxdr.a
>> ../lib/err/.libs/libErr.a ../lib/file/.libs/libFile.a
>> ../lib/glibUtils/.libs/libGlibUtils.a
>> ../lib/guestApp/.libs/libGuestApp.a
>> ../lib/guestRpc/.libs/libGuestRpc.a
>> ../lib/guestStoreClientHelper/.libs/libGuestStoreClientHelper.a
>> ../lib/message/.libs/libMessage.a ../lib/netUtil/.libs/libNetUtil.a
>> ../lib/nicInfo/.libs/libNicInfo.a ../lib/panic/.libs/libPanic.a
>> ../lib/procMgr/.libs/libProcMgr.a
>> ../lib/rpcChannel/.libs/libRpcChannel.a
>> ../lib/rpcIn/.libs/libRpcIn.a ../lib/rpcOut/.libs/libRpcOut.a
>> ../lib/rpcVmx/.libs/libRpcVmx.a ../lib/string/.libs/libString.a
>> ../lib/jsmn/.libs/libJsmn.a ../lib/syncDriver/.libs/libSyncDriver.a
>> ../lib/system/.libs/libSystem.a ../lib/stubs/.libs/libStubsCS.a
>> ../lib/unicode/.libs/libUnicode.a ../lib/user/.libs/libUser.a
>> ../lib/vmCheck/.libs/libVmCheck.a
>> ../lib/vmSignal/.libs/libVmSignal.a ../lib/wiper/.libs/libWiper.a
>> ../lib/misc/.libs/libMisc.a ../lib/slashProc/.libs/libSlashProc.a
>> -Wl,--no-whole-archive  -ltirpc -lrt -lcrypt -lpthread -lglib-2.0
>> -lc  -mtune=generic -march=x86-64 -g2 -O2 -fstack-protector-strong
>> -mno-omit-leaf-frame-pointer -Wl,-z -Wl,defs -Wl,-O1 -Wl,-z
>> -Wl,relro -Wl,-z -Wl,max-page-size=0x1000 -Wl,-Bsymbolic-functions
>> -Wl,--sort-common -Wl,-z -Wl,pack-relative-relocs   -Wl,-soname
>> -Wl,libvmtools.so.0 -o
>> .libs/libvmtools.so.0.0.0
>> /usr/bin/ld: ../lib/lock/.libs/libLock.a(ulCondVar.o): in function `MXUserWaitInternal':
>> /home/build/YPKG/root/open-vm-tools/build/open-vm-tools-stable-12.4.0/open-vm-tools/lib/lock/ulCondVar.c:304:(.text+0x131): undefined reference to `__pthread_cond_timedwait64'
>> collect2: error: ld returned 1 exit status
>> ```
>> 
>
> It seems that your are building for x86_64, where __pthread_cond_timedwait64
> does not exist and pthread.h should not alias to it.
>
> This seems to a broken stage2 build, where compiler is referencing the system
> includes where it should be from the sysroot (where the new glibc is done).
> I saw a similar issue with your Linaro bots that we are fixing.

We're seeing this too but I haven't investigated it yet.

See https://bugs.gentoo.org/933282. I was pretty sure it was actually
fixincludes meaning an old copy of pthread.h was being picked up, but
someone else made a fresh report on IRC I haven't yet investigated (and
it sounded like they were using a fresh GCC build after we disabled
fixincludes again).

>
>> This is building with GCC 13.3 and binutils 2.42. Building with LLVM
>> 18.1.6 is successful however. Full log available here:
>> https://gist.githubusercontent.com/ReillyBrogan/51d046c0b59eb7feeeab48be3b17c78f/raw/58b8963cfe856f9b811638dbf1e905bcaba80ee7/gistfile1.txt
>> 
>> We've reverted to the prior commit for now, but it would be great if we could get this resolved so we can update again.
>> 
>> Regards,
>> 
>> Reilly