Re: Relocatable Perl 5.10.0 on Solaris

FWIW, I can confirm that $^X isn't working properly on Solaris.

It seems that - on Linux - the path to the executable is determined via /proc/self/exe¹. At least that's the impression I get from a quick look at the source, as well as the strace output of perl -e 'print "$^X\n"'. Unfortunately, Solaris doesn't seem to have /proc/self/exe.

A little digging shows that - on Solaris (10) - something like

$ perl -e 'printf "%s\n", readlink "/proc/self/path/a.out"'
/usr/local/perl-5.8.4/bin/perl
[download]

may have a better chance to provide the info that the symlink /proc/self/exe holds on Linux... (on this Solaris box, I currently don't have Perl-5.10, so I tested with an older version — the $^X mechanism doesn't seem to have changed much since, anyway).

(might do some more thorough digging later... as time permits — in which case I'll update the node)

___

¹ in case you want to look at the respective code fragments yourself, grep for one of S_set_caret_X, S_procself_val, PROCSELFEXE_PATH, HAS_PROCSELFEXE.

___

Update: (Note to the OP) In case the /proc/self/path/a.out symlink is working for you, too, you could try to extend the Configure script here (line 15563):

procselfexe=''
val="$undef"
case "$d_readlink" in
"$define")
    if $issymlink /proc/self/exe ; then
        $ls -l /proc/self/exe > reflect
        if $contains /`basename $ls` reflect >/dev/null 2>&1; then
            echo "You have Linux-like /proc/self/exe."
            procselfexe='"/proc/self/exe"'
            val="$define"
        fi
    fi
    ...
[download]

and see if it works then...

Comment on Re: Relocatable Perl 5.10.0 on Solaris Select or Download Code

Replies are listed 'Best First'.
Re^2: Relocatable Perl 5.10.0 on Solaris by Anonymous Monk on May 16, 2008 at 15:51 UTC
Unfortunately, the box is solaris 8, not 10 - and there doesn't seem to be a /proc/self/path/a.out symlink. I haven't (so far) been able to find anything I could use in place of /proc/self/exe either. Thanks for you help so far almut, I have to say I'm finding the level of support here outstanding.	[reply]
Re^3: Relocatable Perl 5.10.0 on Solaris by almut (Canon) on May 16, 2008 at 19:11 UTC
Unfortunately, the box is solaris 8, not 10 ... I was afraid you were going to say that :) — in this case you're essentially out of luck... On anything older than Solaris 10, the proc filesystem is rather limited. AFAIK, the only info remotely similar to `/proc/self/exe` (or `/proc/self/path/a.out` for that matter), is in `/proc/self/auxv` (aux vector — a binary structure), but it's not really the same, in particular on Solaris 8 (things have gotten somewhat better starting with Solaris 9). If you're really determined, you could try to hack up something based on the standard C library functions `getexecname`, which extracts the appropriate structure from `/proc/self/auxv`, together with `realpath`, which resolves all "..", "." and symbolic links in a path (, and possibly also `getcwd`). One ugly problem with `getexecname` on Solaris 8 is that it doesn't make a distinction between an executable script and its associated interpreter invoked via the shebang line. For example, with the following naive snippet `#include <stdlib.h> #include <limits.h> #include <stdio.h> int main() { const char execname; char execpath; char pathbuf[PATH_MAX]; execname = getexecname(); execpath = realpath(execname, pathbuf); printf("execname: %s\n", execname); printf("realpath: %s\n", execpath); }` [download] if you compile this with `cc foo.c -o foo` and put the resulting binary in - let's say - `/home/ck/bin/`, and then create a dummy script `bar` with the shebang line `#!/home/ck/bin/foo` in some other directory like `/home/ck/myscripts/`, and call it from there, you'd get on Solaris 8: `$ ./bar execname: bar realpath: /home/ck/myscripts/bar` [download] while on Solaris 9 or 10, the execname would be more useful `$ ./bar execname: /home/ck/bin/foo realpath: /home/ck/bin/foo` [download] You see the problem with Solaris 8 — and this is not the only one... (note that the code would of course have to be linked into perl (to set `$^X`), i.e. the `foo` in the example represents the Perl binary)	[reply] [d/l] [select]
Re^4: Relocatable Perl 5.10.0 on Solaris by shadowkat (Initiate) on May 19, 2008 at 08:57 UTC
You see the problem with Solaris 8 — and this is not the only one... Yep - I can see that. I'd have to conclude that there's no sane way of getting relocatable perl working on Solaris 8. :( I suppose we could recurse the PATH environment variable to find the first instance of perl to set $^X. Seems awfully hacky though. Thanks again for your thorough help on this!	[reply]
Re^2: Relocatable Perl 5.10.0 on Solaris by rmcgowan (Sexton) on Dec 06, 2010 at 22:32 UTC
IIRC, this type of problem is also happens with $0 in simple shell scripts. On some systems $0 is just the base file name, in others it's an absolute path to the script. FYI, you can get the thing to work if you use the full path to the perl: `$ type perl perl is /usr/local/test/perl/bin/perl $ perl -e 'print "$^X\n"' perl $ /usr/local/test/perl/bin/perl -e 'print "$^X\n"' /usr/local/test/perl/bin/perl` [download] So a shell script wrapper might also be a workaround, to set up an environment where the full path is used. More to the point, is there a fix for this, yet? Thanks, Bob	[reply] [d/l]