bug#47382: runtest doesn't work with Solaris 10 /bin/sh

[Jacob Bachmeyer]

Rainer Orth wrote:
> [...] that logic caused quite a number of issues:
>
> * On Solaris 10 with CONFIG_SHELL=/bin/ksh, configure substituted
>   /bin/ksh into the #! line of both config.guess and config.sub.
>   

It worked!  :-)

>   Unfortunately, this has many issues:
>
> * The modified files weren't made executable, leading to lots of
>   failures from the likes of
>
> Native configuration is couldn't execute 
> "/vol/src/gnu/dejagnu/dejagnu-1.6.3-rc3/config.guess": permission denied
>   

Oops... :-)  I said that logic was experimental.  :-D  I will need to 
rethink this again, since you mention other problems.

> * Even if I manually make the scripts executable, this isn't a proper
>   solution: runtest.exp looks for config.guess in quite a number of
>   places, and many projects rely on being able to drop newer
>   config.{guess,sub} versions into their source trees to support targets
>   that may not even have existed at the time the version of DejaGnu used
>   was released.

While runtest.exp *looks* in several places, it will almost always 
*find* config.guess in either $libdir (typical when running from DejaGnu 
source tree), $libdir/libexec (typical when installed), or $execpath 
(DejaGnu source tree, DEJAGNULIBS overriding $libdir).  I could replace 
the rest of those with $execpath/libexec to pick up the installed 
config.guess near runtest.exp even if DEJAGNULIBS is used and remove the 
others, as they would never be used.  They are already very unlikely to 
ever be used.

>   So using the CONFIG_SHELL should be in the exec line in
>   runtest.exp.
>   

This leads us right back to the same problem:

> * Besides, modifying files in the source tree is wrong for several
>   reasons:
>
> ** Read-only source trees need to be supported.
>   

(Aside:  Automake does not necessarily support read-only source trees.  
For example, building in an object tree can result in an Info file in 
the source tree being rebuilt.  I remember seeing this happen while 
building other GNU releases in the past.)

> ** If you share the same source tree between several targets, which is
>    quite common, you might end up with a shell in #! on a second target
>    that may not even exist there.
>
>   While this could be avoided by making the substitutions to a copy in
>   the build tree, the issue vanishes if runtest.exp uses the proper
>   shell in the exec.

For runtest.exp to use the proper shell, it must somehow *get* that 
information from configure.  So, instead of patching the #! line in 
config.guess, we would need to patch runtest.exp.  While, again, we 
could key the patch off of a unique line (here the only line containing 
"exec $config_guess" sans quotes) or arrange for a default value of 
"/bin/sh" if SHELL is still "@SHELL@" as it will be in the source 
directory prior to running configure, there are a few possibilities here:

* Fix the executable permission problem, but leave the NFS shared source 
tree issue to twist in the wind.  (bad)

* Patch the "exec $config_guess" in runtest.exp, also leaving the NFS 
shared source tree issue to twist in the wind. (also bad)

* Copy config.guess to the build tree and patch it there for 
installation.  This should be workable but will break running DejaGnu 
from a Git checkout on Solaris 10.  I note that this feature is 
currently broken on Solaris 10 anyway due to /bin/sh not being able to 
run config.guess.  This may also cause a few errors with the DejaGnu 
testsuite, as the DejaGnu tests would be run with a shell error in the 
place of a build triplet.  (Wait... why are we not picking up the build 
system triplet from site.exp if configure has been used?  That would 
avoid the need to run config.guess in the source directory, at least 
when building for installation...)

If host_triplet and/or build_triplet are set in the init files, such as 
site.exp, DejaGnu does not bother running config.guess at all.  This 
will cover the case of testing DejaGnu itself, and patching the 
installed copy of config.guess can cover the general case.  I should be 
able to use EXTRA_DEJAGNU_SITE_CONFIG to handle this for DejaGnu itself, 
and I will need to consider offering a patch to Automake to add that 
generally, since transferring build/host/target information through 
site.exp would probably be useful for most packages.


-- Jacob