librt and libpthread in alternate prefix

[Poor Yorick]

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