[Top][All Lists]

[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: Gecko/20090807 MultiZilla/ SeaMonkey/1.1.17 Mnenhy/

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

This leads us right back to the same problem:

* Besides, modifying files in the source tree is wrong for several

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]