GNU bug report logs - #47382
runtest doesn't work with Solaris 10 /bin/sh

Previous Next

Full log

Message #43 received at 47382 <at> debbugs.gnu.org (full text, mbox):

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE>
Cc: 47382 <at> debbugs.gnu.org
Subject: Re: bug#47382: runtest doesn't work with Solaris 10 /bin/sh
Date: Thu, 15 Apr 2021 23:46:29 -0500

Rainer Orth wrote:
> Jacob Bachmeyer <jcb62281 <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.