| Newsgroups |
gmane.linux.lfs.support |
| Message-ID |
<[email protected]> |
On Mon, 2025-02-03 at 12:30 -0600, Douglas R. Reno wrote:
> On 2/3/25 12:25 PM, tjoen ([email protected] via lfs-support Mailing List) wrote:
> > On 2/3/25 1:17 PM, Rainer Fiebig ([email protected] via lfs-support
> > Mailing List) wrote:
> > ...
> > > Naturally, this includes demanding an internet-connection during build.
> > > In self-defence I've written a little script that creates a
> > > downloadlist for the "crates" that are listed somewhere in the
> > > mesa-build-directory. The list for mesa-24.1.7 comprises the following:
> >
> > Yes I had a problem of missing ca-certificates.crt
> > That is solved now.
> > But a new problem rissen;
> > Where is __pthread_mutex_timedlock64 ?
> > See details on response to Xi Ruoyao
> >
> Good afternoon,
>
> That should be in /usr/include/pthread.h. If you've upgraded that system
> from a glibc version prior to (2.34), or upgraded GCC on said system,
> you may have an old version of pthread.h being picked up by GCC via
> /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.0/include-fixed.
> https://developers.redhat.com/articles/2021/12/17/why-glibc-234-removed-libpthread
> explains why that was done way back in 2021.
We've described it precisely in the book:
libpthread
Dummy library containing no functions. Previously contained functions
providing most of the interfaces specified by the POSIX.1b Realtime
Extension, now the functions are in libc
> We've encountered this
> issue before when upgrading LFS systems from LFS 11.x to 12.x.
LFS 11.0 has Glibc-2.34, so it shouldn't be a problem upgrading from LFS
11.x to 12.x.
Upgrading from versions from 10.x or earlier is unsupported, we make it
very clear in the book:
Upgrading Glibc on a LFS system prior to 11.0 (exclusive) is not
supported. Rebuild LFS if you are running such an old LFS system but you
need a newer Glibc.
There are some reasons we don't support doing so besides the libpthread
merge. For example, the upgrade process documented in the latest LFS
Glibc page only works when /lib is a symlink to usr/lib, but before LFS
11.0 /lib was a real directory.
If we assume the OP upgraded Glibc on LFS 10.x following the latest LFS
Glibc upgrade process (and again note that we are explicitly saying
doing so is unsupported so it's NOT a bug of the book):
1. The upgrade process would install the new libc.so.6 into /usr/lib,
but /lib/libc.so.6 will still be the old library.
2. The upgrade process would replace the old /usr/lib/libpthread.so.0
with the new one.
3. Per the LFS GCC page, the order of library paths searched by ld is:
SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64")
SEARCH_DIR("/usr/local/lib64")
SEARCH_DIR("/lib64")
SEARCH_DIR("/usr/lib64")
SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib")
SEARCH_DIR("/usr/local/lib")
SEARCH_DIR("/lib")
SEARCH_DIR("/usr/lib");
Now ld would find /lib/libc.so.6 (old, because /lib is before /usr/lib
in the list above) and /usr/lib/libpthread.so.0 (new), the latter is a
dummy library which does not have __pthread_mutex_timedlock64, and the
former is from Glibc < 2.34 so it also does not have
__pthread_mutex_timedlock64, so things are broken.
So yes the assumption can explain the phenomena. But then it means the
OP has done something explicitly unsupported and we are unlikely able to
help.
--
Xi Ruoyao <[email protected]>
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/sympa/info/lfs-support
Unsubscribe: See the above information page