Re: Invoking executables and AC_TRY_RUN

[Ralf Wildenhues]

Hi James,

* 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?

> 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.

Cheers,
Ralf

[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 :)