Skip navigation

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
echo test
houston@mimas:/tmp > ./
/opt/csw/bin/bash_2: cannot find/execute “” 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.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: