[PATCH 2.39] Always define __USE_TIME_BITS64 when 64 bit time_t is used
Adhemerval Zanella Netto
adhemerval.zanella@linaro.org
Thu Jun 6 20:12:53 GMT 2024
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.
> 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
More information about the Libc-stable
mailing list