Re: librt and libpthread in alternate prefix

Poor Yorick
Sun May 17 18:46:00 GMT 2009

>  From: Ethan Grammatikidis <>
>  Sent: 2009-05-15 23:34
>  On Thu, 14 May 2009 20:00:36 -0400
>  Poor Yorick <> wrote:
>  >
>  > because the !# mechanism requires a binary, not a script.
>  False, you *can* call a script from the #! line.

Really?  On my system, the execve documentation says this:

    execve() executes the program pointed to by filename.  filename must be
    either a binary executable, or a script starting with  a  line  of  the
    form  "#! interpreter [arg]".  In the latter case, the interpreter must be
    a valid pathname for an executable which is  not  itself  a  script, which
    will be invoked as interpreter [arg] filename.

And on a fairly modern Linux kernel, the wrapper script is not invoked.
Instead, execve falls back on the default (/bin/sh):

    $ cat ./pyscript
    #! /path/to/pythonwrapper

    print("hello from python")

    $ cat ./pythonwrapper
    #! /bin/sh

    exec python "$@"

    $ ./pyscript
    ./pyscript: line 3: syntax error near unexpected token `"hello from
    ./pyscript: line 3: `print("hello from python")'

So it seemps that wrapper scripts are not acceptable for standard programs that
get used on the #! line as interpreters.  A compiled wrapper program could
probably be used, but it still seems to me that it should be possible to
configure a new to find its own C libraries, with no wrapper required.  I
forced librt to find the correct libpthread by finding a way to embed R(UN)PATH
into librt, but another solution would have been to configure an alternate with the alternate glibc directories preceeding the stanadard
directores, correct?

Has anyone out there build an alternate software collection that lives
alongside the standard directories, and uses its own glibc, and gotten
executables to work without using wrappers?

>  I suspected your permission denied error is something else, and recalling that I once got permission denied errors under very wierd, non-obvious circumstances, I eventially remembered it can be caused by a peculiar dynamic-linking problem. :)
>  /lib/ (actually /lib/ld-<version>.so) handles most of the dynamic linking in a system, but importantly it itself is a dynamically-linked library. It can't load itself, so what happens? It's loaded by a much more primitive kernel-based mechanism. When things go wrong the only error this primitive mechanism can give is permission denied!
>  I guess that whatever the binary is that finally ends up executing your wrapper scripts, it's somehow finding the wrong

More detail along these lines would be appreciated.  the interp section in my
binaries is explicitly set to the new  I would have thought this would
be sufficient to make it so.  But I have seen other emails alluding to
interactions with the kernel.  Again, further explanations would be greatly


More information about the Libc-help mailing list