Over at blastwave, we’ve been hard at work getting a new perl package togeather, and one of the things we like to do is have 64 bit binaries in the same package as the 32 bit binaries..
We achieve this with the help of a binary called isaexec; our packages install their binaries into (e.g for perl) /opt/csw/bin/sparcv9/perl and /opt/csw/bin/sparcv8/perl, and then a hard link is created as /opt/csw/bin/perl=isaexec in our package prototype.
When /opt/csw/bin/perl (which is actually isaexec) is run, it uses getexecname() and isaexec() to run the correct binary for that host.
On solaris 8 however, we noticed a bit of a strange problem. The /opt/csw/bin/perl link was working as expected, but when we use it in a script #!, we were seeing some unusl behaviour.
To demonstrate this, we’ll set up some isaexec links for bash:
root@mimas:/opt/csw/bin > cp bash sparcv8/bash_2
root@mimas:/opt/csw/bin > cp bash sparcv9/bash_2
root@mimas:/opt/csw/bin > ln isaexec bash_2
Next, a little script which calls the isaexec’d up /opt/csw/bin/bash_2:
houston@mimas:/tmp > cat test.sh
houston@mimas:/tmp > ./test.sh
/opt/csw/bin/bash_2: cannot find/execute “test.sh” in ISA subdirectories
To cut a very long story very short – there is no trivial way around this, the problem lies deep within exec on Solaris 8.
As a result, we’re making the sparcv8 binaries for perl (and anything else) the default for Solaris 8.
The v9 bins are still there, but if you want them you’ll need to use /opt/csw/bin/sparcv9/foo in your scripts.