tech-toolchain archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Fixing $ORGIN RPATHs - at least some of them
On Nov 7, 1:19am, n54%gmx.com@localhost (Kamil Rytarowski) wrote:
-- Subject: Re: Fixing $ORGIN RPATHs - at least some of them
| For the program name we could reuse this new variable.
|
| $ cat /proc/curproc/maps|head -3
| 0000000035400000-0000000035402000 r-xp 0000000000000000 00:00 91906
| /bin/cat
| 0000000035602000-0000000035603000 r--p 0000000000002000 00:00 91906
| /bin/cat
| 0000000035603000-0000000035604000 rw-p 0000000000000000 00:00 0
|
| If the variable is problematic in the given environment, we get errors.
This is a very complicated way to get the program name (but the process
maps). The maps are useful for other things...
| I mean code like this:
|
| http://netbsd.org/~kamil/execpath.c
|
| In the current implementation I'm getting the following questionable result:
|
| $ sudo ./a.out
| cwd='/'
| execname='/tmp/a.out'
| Cannot stat '/tmp/a.out'
Yes, this is a very special case and if we fix it, it can actually
fail if you chroot in a tree that's outside the tree the original
executable was executed from. Nevertheless, while it can be fixed,
we have bigger fish to fry.
christos
Home |
Main Index |
Thread Index |
Old Index