This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
librt and libpthread in alternate prefix
- From: "Poor Yorick" <org dot sourceware dot libchelp at pooryorick dot com>
- To: libc-help at sourceware dot org
- Date: Mon, 04 May 2009 17:59:39 +0000
- Subject: librt and libpthread in alternate prefix
- Reply-to: "Poor Yorick" <org dot sourceware dot libchelp at pooryorick dot com>
Built and installed glibc-2.9 in an alternate location. <prefix>/bin/ldconfig
shows:
libpthread.so.0 (libc6, hwcap: 0x8000000000000000, OS ABI: Linux 2.4.20)
=> /lib/tls/libpthread.so.0
libpthread.so.0 (libc6, hwcap: 0x0008000000000000, OS ABI: Linux 2.4.1)
=> /lib/i686/libpthread.so.0
libpthread.so.0 (libc6, OS ABI: Linux 2.2.5) => /lib/libpthread.so.0
libpthread.so.0 (libc6, OS ABI: Linux 2.0.0) => <prefix>/glibc-2.9/lib/libpthread.so.0
Programs that link to /alternate/glibc-2.9/lib/librt.so.1 end up linked to
/lib/tls/libpthread.so.0 instead of to /alternate/libc-2.9/lib/libpthread.so.0,
presumably because the OS ABI is greater, but this combination causes
executables to segfault.
I thought the workaround might be to embed an RPATH/RUNPATH in librt.so so that
it always finds its sibling libpthread. I've tried getting paths embedded into
libc shared objects before, but the builds never completed succesfully. Any
hints on the right way to do this?
Or, if embedding R(UN)PATHis ill-advised (why?), short of setting environment
variables, how can I get librt.so to find the right libpthread.so?
--
Yorick