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

[Rainer Orth]

Jacob Bachmeyer <jcb62281@gmail.com> writes:

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

I still believe that using the tried-and-try AC_SUBST (like automake
does in t/java-compile-run-flat.sh and t/java-compile-run-nested.sh with
#!@SHELL@) would solve most issues nicely:

* not writing to $srcdir

* supporting both in-tree and VPATH builds

* most likely the permission issue

This has been successfully used for years if not decades and is most
certainly well tested in situations we may not even have thought about :-)

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

Maybe (I haven't dug into this in detail) the fact that e.g. the gcc
testsuite uses the in-gcc-tree config.guess is because site.exp is
generated at make check time, emitting *_triplet into per-testsuite
versions of site.exp.

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

Creating new files in the source tree (and failing; gcc has gone to some
lenghts to avoid this) is one thing; modifying the unpacked sources in
place is quite another.

When you use AC_SUBST as I suggested, that usually takes an
in-source-tree runtest.exp.in (or some such; you can specify the exact
file names using AC_CONFIG_FILES) and write the result to the build
directory.  You just need to make sure that you use the generated file
during make check and make install, which is easy if the filenames differ.

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

As I said, the established convention is to use $CONFIG_SHELL if set and
fall back to /bin/sh if not.

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

No need to key off anything when using AC_SUBST: you pass the files to
be substituted via AC_CONFIG_FILES, then at configure time all uses of
the substituted variables (@SHELL@ in this case) are substituted and the
resulting files places in the build dir.  Alternatively, you could
create a global config file at configure time that contains something
like

set dg_shell = @SHELL@

and always source that.  If this is more reliable than just fixing
runtest.exp(.in) itself is your decision; I for one doubt it.

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

Seems like an incredibly complicated dance to me just to avoid chaning
the above

exec $config_guess

to

exec $dg_shell $config_guess

and be done with it: no need to modify imported files and working with
unmodified out-of-tree copies of config.guess at that.

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

Please keep in mind that this needs to continue working with existing
versions of automake.  As an example, gcc currently uses automake 1.15.1
and autoconf 2.69 and upgrading either or both is far from trivial,
certainly not going to be undertaken just to be able a newer version of
DejaGnu.