[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: Thu, 15 Apr 2021 23:46:29 -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:
Jacob Bachmeyer <jcb62281@gmail.com> writes:
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.

If the reply I have seen on the DejaGnu list so far is correct, that is *exactly* what GCC already does, what I intend to do with EXTRA_DEJAGNU_SITE_CONFIG for 1.6.3, and what I intend to try to push to upstream Automake: carry the *_triplet values from configure into site.exp. DejaGnu does not run GCC's copy of config.guess, but is given the result that configure previously obtained by running it or the value that the user provided to configure.

However, DejaGnu will /still/ need to install (and possibly use) config.guess because initialization files are optional in DejaGnu, so we cannot depend on *_triplet being set in site.exp because site.exp is not actually required to exist. >-<

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

I have observed Automake-derived Makefiles rebuilding shipped Info files in the past (or complaining that makeinfo is not installed). I never bothered to look into why this happened, but I have seen it happen.

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.

To compensate for dropping support for the old Cygnus tree layout, we now support running DejaGnu directly from a Git checkout; this is extremely convenient for development and precludes using AC_SUBST to produce runtest.exp from a runtest.exp.in. (There are also many long-standing assumptions in the code about relative paths from runtest.exp to other parts of DejaGnu, so runtest.exp needs to be in the source tree, or the DejaGnu testsuite will have problems that I really do not want to try to fix on a release branch.)

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

If I understand correctly, CONFIG_SHELL may no longer be in the environment when "make check" is run, although its value will have been propagated to the SHELL make variable, but I do not think that Automake exports that back to the environment.

* 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

This will be a complicated dance no matter what I do, but I might have a simple answer below.

just to avoid chaning
the above

exec $config_guess


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.

There are a few problems here. The largest is that the NFS shared source tree problem comes back in a different form after installation: DejaGnu is installed in an architecture-independent tree (/usr/share/dejagnu) so the installed copy cannot depend on results from configure that could be valid on some machines in a testing lab and wrong on others. This is the same problem that we get with patching the #! line in config.guess.

I was considering getting a proper shell to use from the global initialization file, since that could be configured by the testing lab operators to check the hostname to determine which shell to use, but that would have to wait for the 1.7 release and will not work either: the global site.exp is allowed to assume that the *_triplet variables have already been set.

This leads to another possibility: could we simply require that CONFIG_SHELL be set in the environment if /bin/sh cannot run config.guess? The main runtest.exp could easily do:

   if { [info exists ::env(CONFIG_SHELL)] } {
       catch { exec $::env(CONFIG_SHELL) $config_guess } ...
   } else {
       catch { exec $config_guess } ...

The only problem I see here would be if it is common to do "CONFIG_SHELL=/bin/ksh /path/to/src/configure ..." instead of simply "export CONFIG_SHELL=/bin/ksh" in a .login or similar file. Two advantages here are that this preserves the current code path on all systems that can use it, and an "elseif" branch to check ::env(SHELL) could be easily added as well. DejaGnu will have to be a bit stricter about ensuring that config.guess actually ran and produced usable output, to catch the case of CONFIG_SHELL being needed but no longer set (or SHELL being tcsh), but this is looking feasible since it does not require "customizing" any of the supposedly machine-independent files.

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

This use of EXTRA_DEJAGNU_SITE_CONFIG is for DejaGnu itself and the DejaGnu testsuite, to avoid running config.guess when testing DejaGnu itself, because user-specified triplets should be carried through. As such, moving that upstream will cause other packages to carry *_triplet information through automatically when they move to newer Automake, and the EXTRA_DEJAGNU_SITE_CONFIG file added to DejaGnu can be removed when DejaGnu *itself* moves to a newer Automake that propagates the *_triplet values to site.exp by default.

As one answer to an RFC about this on the DejaGnu mailing list mentioned, GCC *already* overrides Automake's rule for site.exp and does exactly what I am planning to suggest that upstream Automake should do (and a lot more, so they will still need to override Automake's site.exp rule).

On the other hand, if we can use an environment variable in runtest.exp, all of this becomes moot for 1.6.3 and carrying *_triplet through can land in 1.6.4 instead, which I would prefer.

-- Jacob

reply via email to

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