This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: librt and libpthread in alternate prefix
- From: Mike Frysinger <vapier at gentoo dot org>
- To: libc-help at sourceware dot org,"Poor Yorick" <org dot sourceware dot libchelp at pooryorick dot com>
- Date: Mon, 4 May 2009 19:41:18 -0400
- Subject: Re: librt and libpthread in alternate prefix
- References: <20090504175939.24462.qmail@s461.sureserver.com>
On Monday 04 May 2009 13:59:39 Poor Yorick wrote:
> 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.
you must either use all of the new glibc or none of it. mixing glibc libs is
not supported in any way and will most likely crash.
> 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?
no, using runpaths isnt going to matter because you need to execute the new
ldso as well. please review the glibc wiki as there are pages covering how to
do this.
-mike