[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#47382: runtest doesn't work with Solaris 10 /bin/sh
From: |
Jacob Bachmeyer |
Subject: |
bug#47382: runtest doesn't work with Solaris 10 /bin/sh |
Date: |
Wed, 14 Apr 2021 22:59:07 -0500 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17 Mnenhy/0.7.6.0 |
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