This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: librt and libpthread in alternate prefix
- From: "Poor Yorick" <default at pooryorick dot com>
- To: "Ethan Grammatikidis" <eekee57 at fastmail dot fm>, "" <libc-help at sourceware dot org>
- Date: Sun, 17 May 2009 18:46:26 +0000
- Subject: Re: librt and libpthread in alternate prefix
- Reply-to: "Poor Yorick" <default at pooryorick dot com>
> 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