Re: librt and libpthread in alternate prefix

Poor Yorick default@pooryorick.com
Sun May 17 18:46:00 GMT 2009


>  From: Ethan Grammatikidis <eekee57@fastmail.fm>
>  Sent: 2009-05-15 23:34
>  
>  On Thu, 14 May 2009 20:00:36 -0400
>  Poor Yorick <org.sourceware.libchelp@pooryorick.com> wrote:
[SNIP]
>  >
>  > 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
    python"'
    ./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 ld.so 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
ld.so.conf 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/ld.so (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 ld.so.
>  

More detail along these lines would be appreciated.  the interp section in my
binaries is explicitly set to the new ld.so.  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
appreciated.


-- 
Yorick



More information about the Libc-help mailing list