This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: librt and libpthread in alternate prefix
Mike Frysinger wrote:
> On Thursday 14 May 2009 20:00:36 Poor Yorick wrote:
>> Mike Frysinger wrote:
>> > On Tuesday 12 May 2009 10:15:16 Poor Yorick wrote:
>> >> Mike Frysinger wrote:
>> >> > On Monday 11 May 2009 23:34:16 Poor Yorick wrote:
>> >> >> 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.
>> >> >
>> >> > so use a wrapper script that builds paths using $0
>> >>
>> >> That's a kludge that doesn't work well, since wrapper scripts aren't
>> >> suitable for the #! line.
>> >
>> > i dont really know what you're talking about here. #!/bin/sh works just
>> > fine.
>>
>> I mean that I can't wrap binaries compiled against the alternate glibc in a
>> script that calls the real binary using the new loader. For example, if I
>> wrap awk in a script called awk_new, I can't do this:
>>
>> !# /path/to/alternate/awk_new
>>
>> because the !# mechanism requires a binary, not a script.
>
> your wrapper is a script that executes the right ldso with the right paths.
> use #!/bin/sh like normal.
> -mike
If this is what you had in mind (awk being a wrapper for the real awk):
#! /bin/sh /path/to/alternate/bin/awk
then there is no way to add the "-f" argument, since this is invalid:
#! /bin/sh /path/to/alternate/bin/awk -f
That's the kludge. wrapper scripts for standard executables are unexpected,
and cause endless problems. The system will be used by many people, so it
needs to behave like a normal system. If bash, awk, python, etc., are
wrappers, users will be calling up asking why their scripts do this:
bad interpreter: Permission denied
Executables, particularly those that might be used as interpreters on a #!
line, need to be executables, not wrappers. I suppose I could write a wrapper
as a small C program, but surely there is some other way?
Another other issue is that even bash links dynamically against libc.so.6, so
if the standard bash for the alternate software stack is
/path/to/alternate/bin/bash
and it was compiled against the new glibc, then your suggestion leads to a bash
script wrapping bash (unless static link is done), which is at least a little
twisted.
It would be helpful to know if anyone out there is using an alternate dynamic
loader as the basis for an alternate software collection that
. relies on its own glibc (and loader) rather than the system libc
. doesn't wrap all the new
. plays nice with the base system (short of mixing up ld.so->libc.so.6
pairs)
Perhaps the Linux from Scratch documentation will light the way. You seem,
however, to be saying that it can't be done.
--
Yorick