This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: librt and libpthread in alternate prefix


Mike Frysinger wrote:
> On Tuesday 05 May 2009 04:26:01 Poor Yorick wrote:
>> Mike Frysinger wrote:
>>  > 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.
>>
>> But I am using the new ldso, and using all of the new glibc is precisely
>> what I'm trying to do.  It's just that the new ldso insists on linking
>> against another libpthread on the system.  In the output above, you'll see
>> that the new pthread is in the new ld.so.cache, but there are also other
>> libpthreads listed there which have a higher OS ABI.  I need the new libc
>> to use its own libpthread, but that isn't happening, and I'm not sure how
>> to make it happen, given that I do need the new ld.so.cache to also index a
>> few other paths (/lib, /usr/lib).  A cursory search through the wiki didn't
>> turn up a page that deals with this situation.  A pointer would be much
>> appreciated.
>
> more likely the ldso is doing exactly what it's told.  you probably arent
> setting the --library-path option manually which means it's going to search
> the standard paths and find the old glibc.  setting RPATH on a library or two
> wont matter as they are not the first ELFs processed by glibc -- the
> application being executed is.  please read the wiki i referred to earlier for
> how to properly invoke the ldso.  the values in the ld.so cache are irrelevant
> in terms of the search algorithm as it is exactly as it claims to be and
> nothing more -- a *cache*.
> -mike

Because my goal is to build a software collection in an alternate library path
which uses its own glibc, I'm trying to get the new loader to work from the
alternate location without setting --library-path.  I have embedded the new
ld.so into my test program (findutils), and created a new ld.so.cache which
includes both the /path/to/new/glibc/lib, and /usr/lib.  What doesn't add up is
why the new ld.so finds the correct /path/to/new/glibc/librt.so, but then goes
off and finds /lib/tls/libpthread.so.0 instead /path/to/new/glibc/libpthread.so

I have read many of the pages on the wiki, but am not sure which page you are
referring to.  I don't see much information on how to set up glibc as the
default library and loader for a secondary software collection.  Is this
feasible?

I did find a way to embed RPATH/RUNPATH into the libraries, and though it
solved the problem of finding libpthread, my test programs are failing in
unexpected ways:

    --- Makerules   2008-11-13 16:41:41.000000000 -0500
    +++ Makerules.new       2009-05-05 03:47:23.000000000 -0400
    @@ -448,7 +448,8 @@
    +         -L\$(subst :, -L,\$(rpath-link)) -Wl,-rpath-link=\$(rpath-link) \\
    +         -Wl,-enable-new-dtags -Wl,-rpath,/path/to/alternate/lib


-- Yorick



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]