Re: Invoking executables and AC_TRY_RUN

[James Laird]

Hi Ralf,

On Wed, 29 Mar 2006, Ralf Wildenhues wrote:
> * James Laird wrote on Tue, Mar 28, 2006 at 07:50:53PM CEST:
> > 
> > When the AC_TRY_RUN macro runs a program, it invokes it with the simple 
> > command
> > ./a.out
> > When cross-compiling, obviously, this test will fail or produce output 
> > that isn't correct for the target platform.
> > 
> > However, on some multiprocessor machines with a separate execution node, 
> > it's possible to run test executables if they're preceded by a special 
> > invocation command.  For instance,
> > yod ./a.out
> > will run and produce informative results.
> 
> Interesting. What kind of system is this, if I may ask?

This one was a Cray XT3, I believe.  I know there are other machines with
similar setups, but I'm not the one doing the actual support on these
platforms.  I can try to come up with a list if it would help;  the
important common element is that the machines have one node that runs your
shell and another node that actually executes programs, so to run a
program you need to use a command to send it to the execution node.

> > For our automated tests, we set a value we call RUNSERIAL to invoke each 
> > test (using either a homebrew invocation or automake's TEST_ENVIRONMENT 
> > variable).  It would be great if we could do the same thing in configure.
> 
> There have been several[1] calls for or attempts to get functionality
> into Autoconf that
> - allows to start a simulator to execute binaries for $host,
> - allows to transfer binaries (and possibly other needed files, like
>   configuration files, or needed shared libraries) to another host which
>   may then execute the binary.
> - use a chroot, or whatnotelse, to setup a $host environment, ...
> 
> None of the attempts have been complete, in the sense that they tried to
> solve the issue for more than just their specific setup at hand (IIRC
> I'm echoing Paul here).  I actually tried to look into this a few weeks
> ago and decided after reading that I still did not know enough about the
> problem space to be able to propose a good solution in a short amount of
> time.
> 
> (For example, transferring multiple binaries may be magnitudes faster
> than doing all round trips for every test; or: how would you handle the
> need to authenticate?  How would you actually make sure the needed
> shared libraries are already installed and not just visible from the
> $build system?)
> 
> Some packages offer a separate script/binary to run/compile on the $host
> system that collects various data and writes them out in a way suitable
> for use as config.cache or config.site file.  For configure tests, this
> is a pretty good workaround.
> 
> I think it'd be a good idea to look at this issue again sometime after
> 2.60.

I'm not sure I have a good understanding of the problem in the general
case.

In our case, the "target platform" is actually a different node on the
same machine, so a lot of the issues you mention above don't apply.  Both
the build system and the host system share the same disk space, so we
don't need to transfer executables.  We're not worried about shared
libraries because the users will be running programs the same way we are:
logged in on the admin node invoking programs on an execution node.

I entirely support your efforts to support the general case--I think
that's a real strength of autoconf.  As far we're concerned, any solution
that allows us to specify a command to invoke executables will solve this
problem for us.

Thanks,
   James Laird

> [1] See
> http://thread.gmane.org/gmane.comp.sysutils.autoconf.general/6274 and
> the two complete threads referenced therein; or
> http://article.gmane.org/gmane.comp.sysutils.autoconf.general/6281 for a
> similar question with Autotest, which is similar to yours :)
>