[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:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17 Mnenhy/0.7.6.0 |
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
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.
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
DejaGnu.
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