Re: dejagnu version update?

[Jeff Law via Gcc]

On 10/27/2021 5:00 PM, Bernhard Reutner-Fischer wrote:

On Sat, 4 Aug 2018 18:32:24 +0200
Bernhard Reutner-Fischer  wrote:


On Tue, 16 May 2017 at 21:08, Mike Stump  wrote:

On May 16, 2017, at 5:16 AM, Jonathan Wakely  wrote:

The change I care about in 1.5.3

So, we haven't talked much about the version people want most.  If we update, 
might as well get something that more people care about.  1.5.3 is in ubuntu 
LTS 16.04 and Fedora 24, so it's been around awhile.  SUSU is said to be using 
1.6, in the post 1.4.4 systems.  People stated they want 1.5.2 and 1.5.3, so, 
I'm inclined to say, let's shoot for 1.5.3 when we do update.

As for the machines in the FSF compile farm, nah, tail wagging the dog.  I'd 
rather just update the requirement, and the owners or users of those machines 
can install a new dejagnu, if they are using one that is too old and they want 
to support testing gcc.

So.. let me ping that, again, now that another year has passed :)

or another 3 or 4 :)

PS: Recap: https://gcc.gnu.org/ml/fortran/2012-03/msg00094.html was
later applied as
http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5481f29161477520c691d525653323b82fa47ad7
and was part of the dejagnu-1.5.2 release from 2015. Jonathan requires
1.5.3 for libstdc++ testing.

(i.e.
http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5256bd82343000c76bc0e48139003f90b6184347
 )

The libdirs fix would allow us to remove the 150 occurrences of the
load_gcc_lib hack, refer to the patch to the fortran list back then.
AFAIR this is still not fixed: +# BUG: gcc-dg calls
gcc-set-multilib-library-path but does not load gcc-defs!

debian-stable (i think 9 ATM), Ubuntu LTS ship versions recent enough
to contain both fixes. Commercial distros seem to ship fixed versions,
too.

It seems in May 2020 there was a thread on gcc with about the same
subject: https://gcc.gnu.org/pipermail/gcc/2020-May/232427.html
where Mike suggests to have approved to bump the required minimum
version to 1.5.3.
So who's in the position to update the
https://gcc.gnu.org/install/prerequisites.html
to s/1.4.4/1.5.3/g && git commit -m 'bump dejagnu required version' ?
All kinds of people.  Submit a patch and I bet it'll get approved. More 
than anything I suspect it's out-of-sight-out-of-mind at this point 
holding us back.


jeff

Re: dejagnu version update?

[Bernhard Reutner-Fischer via Gcc]

On Sat, 4 Aug 2018 18:32:24 +0200
Bernhard Reutner-Fischer  wrote:

> On Tue, 16 May 2017 at 21:08, Mike Stump  wrote:
> >
> > On May 16, 2017, at 5:16 AM, Jonathan Wakely  wrote: 
> >  
> > > The change I care about in 1.5.3  
> >
> > So, we haven't talked much about the version people want most.  If we 
> > update, might as well get something that more people care about.  1.5.3 is 
> > in ubuntu LTS 16.04 and Fedora 24, so it's been around awhile.  SUSU is 
> > said to be using 1.6, in the post 1.4.4 systems.  People stated they want 
> > 1.5.2 and 1.5.3, so, I'm inclined to say, let's shoot for 1.5.3 when we do 
> > update.
> >
> > As for the machines in the FSF compile farm, nah, tail wagging the dog.  
> > I'd rather just update the requirement, and the owners or users of those 
> > machines can install a new dejagnu, if they are using one that is too old 
> > and they want to support testing gcc.  
> 
> So.. let me ping that, again, now that another year has passed :)

or another 3 or 4 :)
> 
> PS: Recap: https://gcc.gnu.org/ml/fortran/2012-03/msg00094.html was
> later applied as
> http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5481f29161477520c691d525653323b82fa47ad7
> and was part of the dejagnu-1.5.2 release from 2015. Jonathan requires
> 1.5.3 for libstdc++ testing.
(i.e.
http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5256bd82343000c76bc0e48139003f90b6184347
 )
> The libdirs fix would allow us to remove the 150 occurrences of the
> load_gcc_lib hack, refer to the patch to the fortran list back then.
> AFAIR this is still not fixed: +# BUG: gcc-dg calls
> gcc-set-multilib-library-path but does not load gcc-defs!
> 
> debian-stable (i think 9 ATM), Ubuntu LTS ship versions recent enough
> to contain both fixes. Commercial distros seem to ship fixed versions,
> too.

It seems in May 2020 there was a thread on gcc with about the same
subject: https://gcc.gnu.org/pipermail/gcc/2020-May/232427.html
where Mike suggests to have approved to bump the required minimum
version to 1.5.3.
So who's in the position to update the
https://gcc.gnu.org/install/prerequisites.html
to s/1.4.4/1.5.3/g && git commit -m 'bump dejagnu required version' ?

Just asking patiently and politely.
I don't want to rush anybody into such a bump :)

But as you may remember, folks routinely run afoul of using too old
versions (without the 5256bd8 multilib prepending for example, recently
someone doing ARM stuff IIRC) so a bump would just be fair IMHO.

Maybe now, for gcc-12, is the time to bump prerequisites to 1.5.3?

thanks and sorry for my impatience (and, once again, the noise).
cheers,

Re: dejagnu version update?

[Christophe Lyon via Gcc]

Hi,

On Wed, 27 May 2020 at 03:58, Rob Savoye  wrote:
>
> On 5/26/20 7:20 PM, Maciej W. Rozycki wrote:
>
> >  I'll run some RISC-V remote GCC/GDB testing and compare results for
> > DejaGnu 1.6/1.6.1 vs trunk.  It will take several days though, as it takes
> > many hours to go through these testsuite runs.
>
>   That'd be great. I'd rather push out a stable release, than have to
> fix bugs right after it gets released.
>
> - rob -


I ran our GCC validation harness using dejagnu master branch and
compared to the results we get using our linaro-local/stable branch
(https://git.linaro.org/toolchain/dejagnu.git/)

I noticed that we'd need to add patches (1) and (2) at least.

Patch (1) enables us to run tests on aarch64-elf using Arm's Foundation Model.

Patch (2) was posted in 2016:
https://lists.gnu.org/archive/html/dejagnu/2016-03/msg5.html.
It fixes problems with tests output patterns (in fortran, ubsan and asan tests)

Patch (3) was posted in 2016 too:
https://lists.gnu.org/archive/html/dejagnu/2016-03/msg00034.html
I'm not 100% sure it made a difference in these test runs because we
still see some random failures anyway.

Thanks,

Christophe
From 382440f145811eeb3e85d0e57d9b8aa5418d1e80 Mon Sep 17 00:00:00 2001
From: Yvan Roux 
Date: Mon, 25 Apr 2016 11:09:52 +0200
Subject: [PATCH 2/3] Keep trailing newline in remote execution output.

	* lib/rsh.exp (rsh_exec): Don't remove trailing newline.
	* lib/ssh.exp (rsh_exec): Likewise.

Change-Id: I2368c18729c4bff9ee87d9163b1c8f4b0ad7f4d8
---
 lib/rsh.exp | 3 ---
 lib/ssh.exp | 3 ---
 2 files changed, 6 deletions(-)

diff --git a/lib/rsh.exp b/lib/rsh.exp
index 5b583c6..43f5430 100644
--- a/lib/rsh.exp
+++ b/lib/rsh.exp
@@ -283,8 +283,5 @@ proc rsh_exec { boardname program pargs inp outp } {
 	return [list -1 "Couldn't parse $RSH output, $output."]
 }
 regsub "XYZ(\[0-9\]*)ZYX\n?" $output "" output
-# Delete one trailing \n because that is what `exec' will do and we want
-# to behave identical to it.
-regsub "\n$" $output "" output
 return [list [expr {$status != 0}] $output]
 }
diff --git a/lib/ssh.exp b/lib/ssh.exp
index 0cf0f8d..a72f794 100644
--- a/lib/ssh.exp
+++ b/lib/ssh.exp
@@ -194,9 +194,6 @@ proc ssh_exec { boardname program pargs inp outp } {
 	return [list -1 "Couldn't parse $SSH output, $output."]
 }
 regsub "XYZ(\[0-9\]*)ZYX\n?" $output "" output
-# Delete one trailing \n because that is what `exec' will do and we want
-# to behave identical to it.
-regsub "\n$" $output "" output
 return [list [expr {$status != 0}] $output]
 }
 
-- 
2.7.4

From 1e5110d99ac8bac61e97bbdb4bb78ca72adb7e4e Mon Sep 17 00:00:00 2001
From: Maxim Kuvyrkov 
Date: Tue, 28 Jun 2016 09:40:01 +0100
Subject: [PATCH 1/3] Support using QEMU in local/remote testing using default
 "unix" board

If the board file defines "exec_shell", prepend it before the local or
remote command.

Change-Id: Ib3ff96126c4c96e4e7f8898609d0fce6faf803ef
---
 config/unix.exp | 13 +
 1 file changed, 13 insertions(+)

diff --git a/config/unix.exp b/config/unix.exp
index 2e38454..dc3f781 100644
--- a/config/unix.exp
+++ b/config/unix.exp
@@ -78,6 +78,11 @@ proc unix_load { dest prog args } {
 	verbose -log "Setting LD_LIBRARY_PATH to $ld_library_path:$orig_ld_library_path" 2
 	verbose -log "Execution timeout is: $test_timeout" 2
 
+	# Prepend shell name (e.g., qemu emulator) to the command.
+	if {[board_info $dest exists exec_shell]} {
+	set command "[board_info $dest exec_shell] $command"
+	}
+
 	set id [remote_spawn $dest $command "readonly"]
 	if { $id < 0 } {
 	set output "remote_spawn failed"
@@ -119,6 +124,14 @@ proc unix_load { dest prog args } {
 		return [list "unresolved" ""]
 	}
 	}
+
+	# Prepend shell name (e.g., qemu emulator) to the command.
+	if {[board_info $dest exists exec_shell]} {
+	set remotecmd "[board_info $dest exec_shell] $remotefile"
+	} else {
+	set remotecmd "$remotefile"
+	}
+
 	set status [remote_exec $dest $remotefile $parg $inp]
 	remote_file $dest delete $remotefile.o $remotefile
 	if { [lindex $status 0] < 0 } {
-- 
2.7.4

From b6a3e52aec69146e930d85b84a81b1e059f2ffe5 Mon Sep 17 00:00:00 2001
From: Christophe Lyon 
Date: Fri, 28 Sep 2018 08:26:02 +
Subject: [PATCH 3/3] 2018-09-28  Christophe Lyon  

	* lib/ssh.exp (ssh_exec): Redirect stderr to stdout on the remote
	machine, to avoid race conditions.

Change-Id: Ie0613a85fa990484fda41b13738025edf7477a62
---
 lib/ssh.exp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/ssh.exp b/lib/ssh.exp
index a72f794..3c7b840 100644
--- a/lib/ssh.exp
+++ b/lib/ssh.exp
@@ -171,7 +171,7 @@ proc ssh_exec { boardname program pargs inp outp } {
 
 # We use && here, as otherwise the echo always works, which makes it look
 # like execution succeeded when in reality it failed.
-set ret [local_exec "$SSH $ssh_useropts $ssh_user$hostname sh -c '$program $pargs && echo XYZ\\\${?}ZYX \\; rm -f $program'" $inp $outp $tim

Re: dejagnu version update? [CORRECTION: not a regression in DejaGnu; GDB testsuite bug]

[Maciej W. Rozycki via Gcc]

[cc-ing Joel as the originator, and ]

On Tue, 9 Jun 2020, Jacob Bachmeyer wrote:

> >> I ran a quick bisection and the culprit turned out to be:
> >>
> >> ba60272a5ac6f6a7012acca03f596a6ed003f044 is the first bad commit
> >> commit ba60272a5ac6f6a7012acca03f596a6ed003f044
> >> Author: Jacob Bachmeyer 
> >> Date:   Mon May 25 08:40:46 2020 -0600
> >>
> >>  Establish a default C compiler by evaluating [find_gcc] if no 
> >> other compiler is given.
> >>
> >>  So this regression has to be fixed before any new release is made.
> >
> > I will look into this.  So far, I have confirmed that the problem does 
> > occur and that setting the "compiler" board_info key in 
> > baseboards/unix.exp seems to avoid it.  It looks like the default is 
> > not being selected in all cases where it should be used.  I still need 
> > to find the exact problem to write a regression test to isolate this 
> > bug and make it stay squashed.
> 
> After further efforts, and a few hours wasted trying to figure out why 
> additional tracing code added to default_target_compile was not 
> producing output, I eventually decided to just make 
> default_target_compile throw a Tcl error -- and I did not get a Tcl 
> error when running the tests...
> 
> That is "very interesting" and a quick grep -R reveals the culprit:  the 
> GDB testsuite is overriding default_target_compile in 
> gdb/testsuite/lib/future.exp.  Comments indicate that that file was 
> intended to temporarily bundle certain features with the GDB testsuite 
> that had not yet been merged into upstream DejaGnu -- in 2004.  Now 
> DejaGnu core is continuing to develop, leaving the old code copied into 
> the GDB testsuite broken, and making this NOTOURBUG.

 Well, as the name suggests (regrettably there's no adequate documentation 
there) this procedure is there to be overridden.  The way it's done in GDB 
might perhaps be non-standard, as the standard way AFAICS would be by 
providing a `gdb_compile' handler, but I think this is tangential, and the 
chosen solution is there possibly because DejaGnu had no `${tool}_compile' 
knob back then (I haven't checked).  That does not really matter though, 
as the net effect would be the same.

> In short, this is not a regression in DejaGnu; this is code duplicated 
> into the GDB testsuite that was slated for removal from that location 
> years ago and needs to be removed from the GDB testsuite, or at least 
> made conditional on running under a version of DejaGnu old enough to 
> require it, if such versions are still supported for running the GDB 
> testsuite.  If that code has added features not present in upstream 
> DejaGnu over the years, now is the time to get those patches in.

 Well, it clearly is a functional regression as the interface has changed, 
even if not a formal one, and I would consider it a release stopper.

 As it happens there are about 2 users of DejaGnu there, which means any 
fatal regression would have been easily caught in the course of change 
verification (and running binutils/GDB and GCC test suites natively is 
about as easy as it can be: `configure && make && make check'), and indeed 
should have, and then sorted with the respective communities if indeed the 
interface change is unavoidable, with a transition period so that the 
users can prepare changes to their frameworks, including backports to 
various release branches if applicable, before the old interface is 
removed from DejaGnu.  My suggestion would be to revert the change, get 
the details sorted with GDB people and only reapply it when all parties 
are ready. 

 Anyway, I have completed the verification I have volunteered to do and 
therefore I'm done with my part.  Please sort it between the communities.  
I have other stuff to do I have committed to.

  Maciej

Re: dejagnu version update? [CORRECTION: not a regression in DejaGnu; GDB testsuite bug]

[Jacob Bachmeyer via Gcc]

Jacob Bachmeyer wrote:

Maciej W. Rozycki wrote:

[...]

I ran a quick bisection and the culprit turned out to be:

ba60272a5ac6f6a7012acca03f596a6ed003f044 is the first bad commit
commit ba60272a5ac6f6a7012acca03f596a6ed003f044
Author: Jacob Bachmeyer 
Date:   Mon May 25 08:40:46 2020 -0600

 Establish a default C compiler by evaluating [find_gcc] if no 
other compiler is given.


 So this regression has to be fixed before any new release is made.


I will look into this.  So far, I have confirmed that the problem does 
occur and that setting the "compiler" board_info key in 
baseboards/unix.exp seems to avoid it.  It looks like the default is 
not being selected in all cases where it should be used.  I still need 
to find the exact problem to write a regression test to isolate this 
bug and make it stay squashed.


After further efforts, and a few hours wasted trying to figure out why 
additional tracing code added to default_target_compile was not 
producing output, I eventually decided to just make 
default_target_compile throw a Tcl error -- and I did not get a Tcl 
error when running the tests...


That is "very interesting" and a quick grep -R reveals the culprit:  the 
GDB testsuite is overriding default_target_compile in 
gdb/testsuite/lib/future.exp.  Comments indicate that that file was 
intended to temporarily bundle certain features with the GDB testsuite 
that had not yet been merged into upstream DejaGnu -- in 2004.  Now 
DejaGnu core is continuing to develop, leaving the old code copied into 
the GDB testsuite broken, and making this NOTOURBUG.


In short, this is not a regression in DejaGnu; this is code duplicated 
into the GDB testsuite that was slated for removal from that location 
years ago and needs to be removed from the GDB testsuite, or at least 
made conditional on running under a version of DejaGnu old enough to 
require it, if such versions are still supported for running the GDB 
testsuite.  If that code has added features not present in upstream 
DejaGnu over the years, now is the time to get those patches in.



-- Jacob

Re: dejagnu version update?

[Jacob Bachmeyer via Gcc]

Maciej W. Rozycki wrote:

On Tue, 26 May 2020, Rob Savoye wrote:
  
 I'll run some RISC-V remote GCC/GDB testing and compare results for 
DejaGnu 1.6/1.6.1 vs trunk.  It will take several days though, as it takes 
many hours to go through these testsuite runs.
  

  That'd be great. I'd rather push out a stable release, than have to
fix bugs right after it gets released.



 I have completed GCC and GDB testing now with the `riscv64-linux-gnu' 
target and the `x86_64-linux-gnu' host.


 GDB results obtained with real hardware are looking good, with the usual 
fluctuation due to intermittent failures caused by races in test cases:


[...]

 Similarly GCC test results taken with QEMU in the user emulation mode 
show a couple of intermittent discrepancies (not present on a rerun) 
within the libgo testsuite only:


[...]

 However native `x86_64-linux-gnu' GDB testing does not work at all; all 
it gets is:


get_compiler_info: default_target_compile: No compiler to compile with
get_compiler_info: compiler_info not provided
get_compiler_info: got unexpected diagnostics
get_compiler_info: unknown
gdb compile failed, default_target_compile: No compiler to compile with

Conversely all things being equal DejaGnu 1.6 finds native `/usr/bin/gcc' 
just fine:


get_compiler_info: set compiler_info "unknown"
get_compiler_info: set compiler_info [join {gcc 9 2 1} -]
get_compiler_info: gcc-9-2-1

and in the verbose mode also:

Checking /home/macro/bin for gcc
Checking /home/macro/bin for gcc
Checking /usr/local/bin for gcc
Checking /usr/bin for gcc
Choosing /usr/bin/gcc

I ran a quick bisection and the culprit turned out to be:

ba60272a5ac6f6a7012acca03f596a6ed003f044 is the first bad commit
commit ba60272a5ac6f6a7012acca03f596a6ed003f044
Author: Jacob Bachmeyer 
Date:   Mon May 25 08:40:46 2020 -0600

 Establish a default C compiler by evaluating [find_gcc] if no other 
compiler is given.

 So this regression has to be fixed before any new release is made.
  


I will look into this.  So far, I have confirmed that the problem does 
occur and that setting the "compiler" board_info key in 
baseboards/unix.exp seems to avoid it.  It looks like the default is not 
being selected in all cases where it should be used.  I still need to 
find the exact problem to write a regression test to isolate this bug 
and make it stay squashed.  Please submit a bug report to 
 for this issue.



Side note to Rob:  should I base the fix for this on the 
"new-api-for-1.6.3" branch or should we have a merge commit for that 
later?  (Or should I go ahead and merge that branch now?)


-- Jacob

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

On Tue, 26 May 2020, Rob Savoye wrote:

> >  I'll run some RISC-V remote GCC/GDB testing and compare results for 
> > DejaGnu 1.6/1.6.1 vs trunk.  It will take several days though, as it takes 
> > many hours to go through these testsuite runs.
> 
>   That'd be great. I'd rather push out a stable release, than have to
> fix bugs right after it gets released.

 I have completed GCC and GDB testing now with the `riscv64-linux-gnu' 
target and the `x86_64-linux-gnu' host.

 GDB results obtained with real hardware are looking good, with the usual 
fluctuation due to intermittent failures caused by races in test cases:

@@ -63343,8 +63344,8 @@

=== gdb Summary ===

-# of expected passes   59902
-# of unexpected failures   778
+# of expected passes   59900
+# of unexpected failures   781
 # of unexpected successes  2
 # of expected failures 48
 # of unknown successes 5

 Similarly GCC test results taken with QEMU in the user emulation mode 
show a couple of intermittent discrepancies (not present on a rerun) 
within the libgo testsuite only:

@@ -912,12 +912,12 @@ Schedule of variations:

 Running target qemu-user-lp64d
 Running .../libgo/testsuite/libgo.testmain/testmain.exp ...
-FAIL: database/sql
+PASS: database/sql

=== libgo Summary ===

-# of unexpected failures   1
-Test run by macro on Thu Jun  4 04:29:42 2020
+# of expected passes   1
+Test run by macro on Wed Jun  3 01:38:10 2020
 Target is riscv64-unknown-linux-gnu
 Host   is riscv64-unknown-linux-gnu
 Build  is x86_64-pc-linux-gnu

and:

@@ -2239,12 +2239,12 @@ Schedule of variations:

 Running target qemu-user-lp64d
 Running .../libgo/testsuite/libgo.testmain/testmain.exp ...
-PASS: net/http/pprof
+FAIL: net/http/pprof

=== libgo Summary ===

-# of expected passes   1
-Test run by macro on Thu Jun  4 02:42:17 2020
+# of unexpected failures   1
+Test run by macro on Tue Jun  2 23:54:18 2020
 Target is riscv64-unknown-linux-gnu
 Host   is riscv64-unknown-linux-gnu
 Build  is x86_64-pc-linux-gnu

(the testsuite is run in a peculiar manner in the remote case, hence the 
individual per-test summaries) and are otherwise identical.

 However native `x86_64-linux-gnu' GDB testing does not work at all; all 
it gets is:

get_compiler_info: default_target_compile: No compiler to compile with
get_compiler_info: compiler_info not provided
get_compiler_info: got unexpected diagnostics
get_compiler_info: unknown
gdb compile failed, default_target_compile: No compiler to compile with

Conversely all things being equal DejaGnu 1.6 finds native `/usr/bin/gcc' 
just fine:

get_compiler_info: set compiler_info "unknown"
get_compiler_info: set compiler_info [join {gcc 9 2 1} -]
get_compiler_info: gcc-9-2-1

and in the verbose mode also:

Checking /home/macro/bin for gcc
Checking /home/macro/bin for gcc
Checking /usr/local/bin for gcc
Checking /usr/bin for gcc
Choosing /usr/bin/gcc

I ran a quick bisection and the culprit turned out to be:

ba60272a5ac6f6a7012acca03f596a6ed003f044 is the first bad commit
commit ba60272a5ac6f6a7012acca03f596a6ed003f044
Author: Jacob Bachmeyer 
Date:   Mon May 25 08:40:46 2020 -0600

 Establish a default C compiler by evaluating [find_gcc] if no other 
compiler is given.

 So this regression has to be fixed before any new release is made.

 HTH,

  Maciej

Re: dejagnu version update?

[Rob Savoye]

On 5/26/20 7:20 PM, Maciej W. Rozycki wrote:

>  I'll run some RISC-V remote GCC/GDB testing and compare results for 
> DejaGnu 1.6/1.6.1 vs trunk.  It will take several days though, as it takes 
> many hours to go through these testsuite runs.

  That'd be great. I'd rather push out a stable release, than have to
fix bugs right after it gets released.

- rob -

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

On Tue, 26 May 2020, Rob Savoye wrote:

>   I processed the patch backlog for DejaGnu, and have gone through the
> bug list. It'd be nice if somebody could try master with a more complex
> environment, etc... if I'm going to push out a release. For cross
> testing all I have is a PI and QEMU.

 I'll run some RISC-V remote GCC/GDB testing and compare results for 
DejaGnu 1.6/1.6.1 vs trunk.  It will take several days though, as it takes 
many hours to go through these testsuite runs.

  Maciej

Re: dejagnu version update?

[Rob Savoye]

  I processed the patch backlog for DejaGnu, and have gone through the
bug list. It'd be nice if somebody could try master with a more complex
environment, etc... if I'm going to push out a release. For cross
testing all I have is a PI and QEMU.

- rob -

Re: dejagnu version update?

[Rob Savoye]

On 5/17/20 1:43 PM, Maciej W. Rozycki wrote:

> patch service before.  It doesn't appear linked to our mailing list either 
> and instead you need to go through the hoops of a web interface (and open 
> an account first) to submit a change.

  From what I remember, it was decided the GNU toolchain (minus DejaGnu)
that the savannah infrastructure was insufficient. Some of the others
here probably remember better. GNU projects are different when it's not
part of the toolchain. My Gnash project uses savannah heavily. But you
are right, it forces you into a webbie world, and email is mostly for
notifications.

>  That's precisely what patchworks is for, which has been used to various 
> extent for the GNU C library, GCC and GDB already.  All of which projects 
> are of similar vintage to DejaGnu and I reckon rather important for the 
> GNU project.  Given that our main patch submission channel is e-mail, 
> what's the point in using a system that does not accept one?

  So maybe the discussion point is if we want to consider DejaGnu part
of the toolchain, and use the same infrastructure as the other tools. I have
no problem with that. DejaGnu doesn't change much, and there were only 2
of us working on it, so we just never thought about it.

- rob -

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

On Sat, 16 May 2020, Rob Savoye wrote:

> >  Overall perhaps a patch management system might be good having to make 
> > chasing patches easier, such as patchwork, and we already use Git, so we 
> 
>  As an old GNU project, we're required to use what the FSF prefers,
> which is on savannah. https://savannah.gnu.org/patch/?group=dejagnu,

 Hmm, as a youngster who's been around for twenty-something years only (my 
first patch was for glibc, back in 1998) I haven't even heard of this 
patch service before.  It doesn't appear linked to our mailing list either 
and instead you need to go through the hoops of a web interface (and open 
an account first) to submit a change.

> Our
> bug tracker is there their too. We've used that for a long time. Yes,
> patches in email are harder to track.

 That's precisely what patchworks is for, which has been used to various 
extent for the GNU C library, GCC and GDB already.  All of which projects 
are of similar vintage to DejaGnu and I reckon rather important for the 
GNU project.  Given that our main patch submission channel is e-mail, 
what's the point in using a system that does not accept one?

  Maciej

Re: dejagnu version update?

[Andrew Pinski via Gcc]

On Sat, May 16, 2020 at 9:02 PM Rob Savoye  wrote:
>
> On 5/16/20 5:45 PM, Maciej W. Rozycki wrote:
>
> >  Overall perhaps a patch management system might be good having to make
> > chasing patches easier, such as patchwork, and we already use Git, so we
>
>  As an old GNU project, we're required to use what the FSF prefers,
> which is on savannah. https://savannah.gnu.org/patch/?group=dejagnu, Our
> bug tracker is there their too. We've used that for a long time. Yes,
> patches in email are harder to track.
>
> > fresh patchwork?  The patch traffic is surely much lower with DejaGnu than
> > it is with glibc, and there would be no data to migrate (but we might want
> > to feed a couple of months' back worth of mailing list traffic).
>
>   I'm now building up the infrastructure to properly test patches, but
> it's not enough to do the next release. All I have these days is my
> laptop and a PI B3+. I'd need access to more hardware as some of the
> patches effect cross testing, or get others to test the release candidates.

You should be able to use the gcc compilefarm too for this purpose
(https://gcc.gnu.org/wiki/CompileFarm).

Thanks,
Andrew

>
>   Much of the problems with cross testing are often obscure timing
> problems. It's amazing how sometimes a minor unrelated change changes
> the timing and things break... To do a release properly requires
> duplicating that level of infrastructure for at least several targets
> and several toolchain release, and built on more than one GNU/Linux distro.
>
>  It'll take most of the week to really get a good base setup with
> baseline test results, but some of the patches like the DejaGnu
> testsuite ones will go in first since they don't effect the toolchain.
>
>   Jacob already added 9 patches to our site. I'm still building cross
> compilers since some of his patches effect cross testing. I did add ADA
> to my builds, which isn't a normal build default, since I thought some
> of the patches for ADA.
>
> - rob -
> ---
> https://www.senecass.com

Re: dejagnu version update?

[Rob Savoye]

On 5/16/20 5:45 PM, Maciej W. Rozycki wrote:

>  Overall perhaps a patch management system might be good having to make 
> chasing patches easier, such as patchwork, and we already use Git, so we 

 As an old GNU project, we're required to use what the FSF prefers,
which is on savannah. https://savannah.gnu.org/patch/?group=dejagnu, Our
bug tracker is there their too. We've used that for a long time. Yes,
patches in email are harder to track.

> fresh patchwork?  The patch traffic is surely much lower with DejaGnu than 
> it is with glibc, and there would be no data to migrate (but we might want 
> to feed a couple of months' back worth of mailing list traffic).

  I'm now building up the infrastructure to properly test patches, but
it's not enough to do the next release. All I have these days is my
laptop and a PI B3+. I'd need access to more hardware as some of the
patches effect cross testing, or get others to test the release candidates.

  Much of the problems with cross testing are often obscure timing
problems. It's amazing how sometimes a minor unrelated change changes
the timing and things break... To do a release properly requires
duplicating that level of infrastructure for at least several targets
and several toolchain release, and built on more than one GNU/Linux distro.

 It'll take most of the week to really get a good base setup with
baseline test results, but some of the patches like the DejaGnu
testsuite ones will go in first since they don't effect the toolchain.

  Jacob already added 9 patches to our site. I'm still building cross
compilers since some of his patches effect cross testing. I did add ADA
to my builds, which isn't a normal build default, since I thought some
of the patches for ADA.

- rob -
---
https://www.senecass.com

Re: dejagnu version update?

[Siddhesh Poyarekar]

On 17/05/20 05:15, Maciej W. Rozycki wrote:
>  Siddhesh, would you care to tell us how much effort it would be to set up 
> fresh patchwork?  The patch traffic is surely much lower with DejaGnu than 
> it is with glibc, and there would be no data to migrate (but we might want 
> to feed a couple of months' back worth of mailing list traffic).
> 

Not much on my end, I only need to create a project on sourceware.
Dejagnu admins will have to add the patchwork email address to their
mailing list from the back end and then you'd have to point me or Carlos
to the email archive to seed the project.

That and nominate a maintainer or two for the project on patchwork to
carry out regular tasks.

Siddhesh

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

On Thu, 14 May 2020, Rob Savoye wrote:

>   Right now working through patches is probably more important. :-)
> There's zero patches on the DejaGnu savannah site, so I'd ask anybody to
> submit them so I don't have to dig them out of email archives.

 I have reposted the single patch I have had outstanding.  Please review.  
I have a couple of new ones down the line.

 Overall perhaps a patch management system might be good having to make 
chasing patches easier, such as patchwork, and we already use Git, so we 
are set for using that tool.  Siddhesh has recently installed version 2.0 
for glibc and migrated all the old patchwork data, and might be able to 
give us some input.

 Siddhesh, would you care to tell us how much effort it would be to set up 
fresh patchwork?  The patch traffic is surely much lower with DejaGnu than 
it is with glibc, and there would be no data to migrate (but we might want 
to feed a couple of months' back worth of mailing list traffic).

 Just a suggestion.  See:  to get a 
feel.

  Maciej

Re: dejagnu version update?

[Rob Savoye]

On 5/15/20 6:22 PM, Mike Stump wrote:

> Anyway, love to have software that can move code wholesale.  Love to move the 
> testsuite into a new language.

  All it needs is funding. :-) What GDB needs is expect, not Tcl. Most
of the GDB testsuite is just expect pattern matching from the shell.
That's the entire reason I choose Tcl as it already had expect support.
Expect was necessary functionality for GDB testing. For GCC &  Binutils,
Expect is only used for remote testing support.

  As it's possible to embed Tcl in other programs, the idea was to use
an embedded Tcl interpreter when needed during a transition period. It's
mostly just the framework itself that would need to be refactored into
Python. There is also a large amount of code in gcc/testsuite that
should probably be in core DejaGnu too. That would be a large component
in analyzing existing code to write a true design doc. The best part is
now we have large toolchain testsuites to use to test DejaGnu changes.

 A one point we thought DejaGnu would be used for other projects, but I
think it's obviously that these days it's  only used for GNU toolchain
testing.

  I'm making progress on setting up a development environment to test
patches. I use my ABE tool to build toolchains, had to fix some bugs
(and add PI support) first.

- rob -
---
https://www.senecass.com

Re: dejagnu version update?

[Mike Stump via Gcc]

On May 14, 2020, at 11:11 AM, Tom Tromey  wrote:
> 
>> "Rob" == Rob Savoye  writes:
> 
> Rob>   Not that team, the folks I talked to thought I was crazy for wanting
> Rob> to refactor it. :-)
> 
> I don't think refactoring dejagnu is crazy, but I think it's pretty hard
> to imagine rewriting the gdb test suite in Python.  It's 260 KLOC.

So, TCL is subject to being easy to parse, and if you can reliable move each 
feature to a new system with a re-engineering style system that is complete 
enough to handle converting code from TCL to python, for example; one merely 
needs to complete the work for a few of the odd corner cases one might use.  At 
some point, I do think as an industry, we do need tools to migrate code from 
system to system, updating the language used.  C++ may well fall outside of the 
possibility for the next 30-90 years, but TCL, lisp and python might not be so 
unreasonable in a shorter timeframe.  I one saw someone convert TCL into lisp I 
think it was, which I thought was neat.

One day, would be nice if language implementors and designers implemented 
conversions into and out of their language from _the_ re-engineering toolkit as 
they did their language.  10 or 30 years after they decide, oh, no more support 
for you, you're dead, you can then migrate to the next new wiz bang language.

Yes, I say this all, even knowing that people can't even do the python 2.7 -> 
3.x conversion program yet.

Anyway, love to have software that can move code wholesale.  Love to move the 
testsuite into a new language.

Re: dejagnu version update?

[Jacob Bachmeyer via Gcc]

Rob Savoye wrote:

On 5/14/20 10:08 AM, David Edelsohn wrote:
  

Have you approached the Linux Foundation Core Infrastructure
Initiative for funding for both DejaGNU maintenance (patch backlog)
and refactoring DejaGNU in Python efforts?



  Not that team, the folks I talked to thought I was crazy for wanting
to refactor it. :-) That's been the usual answer from anyone. I even
talked about this at GNU Tools Cauldron once. Seriously though, it'd be
great to analyze the current code base, write an actual design document,
clean internal APIs, and build something we can use for another 30
years.
This is very close to the volunteer work I have been doing on DejaGNU:  
just documenting the existing API would be a major step forwards, with 
follow-up plans to slowly move DejaGNU to more modern Tcl.  Using modern 
Tcl features, like namespaces (introduced in Tcl 8.0) and slave 
interpreters (introduced in Tcl 7.6) would enable significant clean up 
and possibly even simultaneous support for multiple testsuite API 
versions, allowing even backwards-incompatible changes by preserving 
support for the old API and requiring the new API to be requested.



 I'd start by writing a solid expect module for Python, and then
embedding Tcl in Python as a comparability layer. I understand it'd be a
huge project, which is why I haven't done this as a volunteer.
  

Amusingly, I believe both of those may already be in CPAN for Perl 5.  :-)

-- Jacob

Re: dejagnu version update?

[Rob Savoye]

On 5/14/20 5:34 PM, Maciej W. Rozycki wrote:

> And then current development appears ongoing, ferociously indeed, with the 
> last check in literally today (barring my time zone), as indicated here: 
> .

  It's obvious I haven't been paying attention, so much for my
retirement... :-)  That's awesome actually, and it does look active.

>  Other than that what would be the technical advantage from rewriting 
> DejaGnu in Python (/me asking as a Python ignoramus)?

  The main thought was more towards an actual design and clean APIs, and
assuming Tcl/Expect was unmaintained, needed to use something that'll be
around for a few more decades. Assuming Tcl/Expect are maintained
forever, that's a bit of a moot point. Everybody has always complained
about using Tcl in DejaGnu. Python is just much more commonly used in
the current century.

  Right now working through patches is probably more important. :-)
There's zero patches on the DejaGnu savannah site, so I'd ask anybody to
submit them so I don't have to dig them out of email archives.

- rob -

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

On Thu, 14 May 2020, Rob Savoye wrote:

>   Personally, I tried to find funding to refactor DejaGnu in Python,
> since Tcl is unmaintained too, but nobody was interested.

 Thank you for your contribution to DejaGnu over the years and for your 
input on this occasion.

 However it does not appear to me to be right that Tcl is not maintained, 
as a stable 8.6.10 release has been made as recently as half a year ago. 
And then current development appears ongoing, ferociously indeed, with the 
last check in literally today (barring my time zone), as indicated here: 
.

 Other than that what would be the technical advantage from rewriting 
DejaGnu in Python (/me asking as a Python ignoramus)?

  Maciej

Re: dejagnu version update?

[Tom Tromey]

> "Rob" == Rob Savoye  writes:

Rob>   Not that team, the folks I talked to thought I was crazy for wanting
Rob> to refactor it. :-)

I don't think refactoring dejagnu is crazy, but I think it's pretty hard
to imagine rewriting the gdb test suite in Python.  It's 260 KLOC.

Tom

Re: dejagnu version update?

[Rob Savoye]

On 5/14/20 10:08 AM, David Edelsohn wrote:

> Have you approached the Linux Foundation Core Infrastructure
> Initiative for funding for both DejaGNU maintenance (patch backlog)
> and refactoring DejaGNU in Python efforts?

  Not that team, the folks I talked to thought I was crazy for wanting
to refactor it. :-) That's been the usual answer from anyone. I even
talked about this at GNU Tools Cauldron once. Seriously though, it'd be
great to analyze the current code base, write an actual design document,
clean internal APIs, and build something we can use for another 30
years. I'd start by writing a solid expect module for Python, and then
embedding Tcl in Python as a comparability layer. I understand it'd be a
huge project, which is why I haven't done this as a volunteer.

  I think there has been a bit of a leave it alone so it stays stable
attitude... Bugs in the test framework effect our ability to work on the
toolchain efficiently, but other than the handful of people here, nobody
cares. Forgetting the refactoring daydream, testing patches and doing
releases still needs to be done, so I think we need a long-term solution
and fresh energy.

- rob -
---
https://www.senecass.com

Re: dejagnu version update?

[David Edelsohn via Gcc]

On Thu, May 14, 2020 at 12:00 PM Rob Savoye  wrote:
>
> On 5/14/20 8:08 AM, Rainer Orth wrote:
>
> >> stops responding for whatever reason.  I have come up with a solution
> >> (that I'd be happy to upstream, except that DejaGNU maintenance seems to
> >> have been dead for like a year now), which I have also confirmed to be
> >> required with current DejaGNU Git master so it must be a different one,
> >> and I would like to know how it might be related to the bug you mention.
>
>   I feel I need to bring up the issue that DejaGnu is 30 years old, and
> it's two maintainers are either trying to pay bills, or trying to
> retire, or both... This problem will effect more projects in the future,
> not just DejaGnu. I'd love to see if anyone would like to become a
> co-maintainer, who preferably will be actively working for a few decades
> still. I think most people on these lists make their income from working
> on the toolchain, but some of us are still volunteers... and getting
> older every day...
>
>   There is a patch backlog neither of us have even looked at, sorry. I'm
> willing to put some time into this, but I think you all realize the time
> involved to adequately test this. I'm not sure I have enough disk space. :-)
>
>   Personally, I tried to find funding to refactor DejaGnu in Python,
> since Tcl is unmaintained too, but nobody was interested.

I greatly appreciate all of the work that you have invested in the
infrastructure and your continued assistance.

Have you approached the Linux Foundation Core Infrastructure
Initiative for funding for both DejaGNU maintenance (patch backlog)
and refactoring DejaGNU in Python efforts?

Thanks, David

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

Hi Rainer,

> >  Versions 1.6 and 1.6.1 seem ubiquitous and coincidentally earlier this 
> > very week I have been chasing a phenomenon with Expect's `wait' semantics 
> > causing a reliable hang in remote testing if `ssh' to the target board 
> > stops responding for whatever reason.  I have come up with a solution 
> > (that I'd be happy to upstream, except that DejaGNU maintenance seems to 
> > have been dead for like a year now), which I have also confirmed to be 
> > required with current DejaGNU Git master so it must be a different one, 
> > and I would like to know how it might be related to the bug you mention.
> 
> I believe it's
> 
> commit b4e61f85ae26d215e8ad5d6e9fcda6c0745096a1
> Author: Richard Biener 
> Date:   Fri Jul 6 21:35:29 2018 +1000
> 
> * lib/remote.exp (close_wait_program): Use separate kill command
> for each pid.
> 
> Richard pointed me at the 1.6.2 release when I mentioned the issue
> somewhere on a gcc list, and it's his patch, so it's likely to be the
> one.

 Thanks; I have seen it and even backported it to my test environment.  
It does not affect my scenario at all however as the kill commands get 
killed just as Expect's `wait' succeeds and then the subsequent TCL 
`close' invocation made on the pipeline in the caller hangs on wait(2) 
indefinitely.  So it's all the same area, but different modes of failure.  
I'll wrap up on my patches then and post them soon.

> It went into DejaGnu immediately after the 1.6.1. release ;-(

 Well, 1.6.2 has been out for a while now so I guess distros might well 
upgrade.  I think it's one of those packages there is not need with to 
wait for code to settle, as it's for core developers' use.  OTOH it's not 
a big deal for the intended users to check out and install the top of 
trunk version anyway.

  Maciej

Re: dejagnu version update?

[Rob Savoye]

On 5/14/20 8:08 AM, Rainer Orth wrote:

>> stops responding for whatever reason.  I have come up with a solution 
>> (that I'd be happy to upstream, except that DejaGNU maintenance seems to 
>> have been dead for like a year now), which I have also confirmed to be 
>> required with current DejaGNU Git master so it must be a different one, 
>> and I would like to know how it might be related to the bug you mention.

  I feel I need to bring up the issue that DejaGnu is 30 years old, and
it's two maintainers are either trying to pay bills, or trying to
retire, or both... This problem will effect more projects in the future,
not just DejaGnu. I'd love to see if anyone would like to become a
co-maintainer, who preferably will be actively working for a few decades
still. I think most people on these lists make their income from working
on the toolchain, but some of us are still volunteers... and getting
older every day...

  There is a patch backlog neither of us have even looked at, sorry. I'm
willing to put some time into this, but I think you all realize the time
involved to adequately test this. I'm not sure I have enough disk space. :-)

  Personally, I tried to find funding to refactor DejaGnu in Python,
since Tcl is unmaintained too, but nobody was interested.

- rob -
---
https://www.senecass.com

Re: dejagnu version update?

[Rainer Orth]

Hi Maciej,

> On Wed, 13 May 2020, Rainer Orth wrote:
>
>> > I'm in favour of requiring 1.5.3 or later, so 1.6 would be OK for me.
>> 
>> If we go beyond 1.5.x, we need to go all the way up to 1.6.2: 1.6 and
>> 1.6.1 have an ugly bug that can miss timeouts, causing tests to hang
>> indefinitely until one manually kills them.
>
>  Would you mind sharing a reference such as a DejaGNU Git commit ID of the 
> fix for the bug you mean?
>
>  Versions 1.6 and 1.6.1 seem ubiquitous and coincidentally earlier this 
> very week I have been chasing a phenomenon with Expect's `wait' semantics 
> causing a reliable hang in remote testing if `ssh' to the target board 
> stops responding for whatever reason.  I have come up with a solution 
> (that I'd be happy to upstream, except that DejaGNU maintenance seems to 
> have been dead for like a year now), which I have also confirmed to be 
> required with current DejaGNU Git master so it must be a different one, 
> and I would like to know how it might be related to the bug you mention.

I believe it's

commit b4e61f85ae26d215e8ad5d6e9fcda6c0745096a1
Author: Richard Biener 
Date:   Fri Jul 6 21:35:29 2018 +1000

* lib/remote.exp (close_wait_program): Use separate kill command
for each pid.

Richard pointed me at the 1.6.2 release when I mentioned the issue
somewhere on a gcc list, and it's his patch, so it's likely to be the
one.

It went into DejaGnu immediately after the 1.6.1. release ;-(

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: dejagnu version update?

[Jonathan Wakely via Gcc]

On Thu, 14 May 2020 at 07:45, Christophe Lyon wrote:
>
> On Wed, 13 May 2020 at 19:44, Jonathan Wakely via Gcc  wrote:
> >
> > On Wed, 13 May 2020 at 18:19, Mike Stump via Gcc  wrote:
> > >
> > > I've changed the subject to match the 2015, 2017 and 2018 email threads.
> > >
> > > On May 13, 2020, at 3:26 AM, Thomas Schwinge  
> > > wrote:
> > > >
> > > > Comparing DejaGnu/GCC testsuite '*.sum' files between two systems ("old"
> > > > vs. "new") that ought to return identical results, I found that they
> > > > didn't:
> > >
> > > > I have not found any evidence in DejaGnu master branch that this not
> > > > working would've been a "recent" DejaGnu regression (and then fixed for
> > > > DejaGnu 1.6) -- so do we have to assume that this never worked as
> > > > intended back then?
> > >
> > > Likely not.
> > >
> > > > Per our "Prerequisites for GCC" installation documentation, we currently
> > > > require DejaGnu 1.4.4.  Advancing that to 1.6 is probably out of
> > > > question, given that it has "just" been released (four years ago).
> > >
> > > :-)  A user that wants full coverage should use 1.6, apparently.
> >
> > As documented at
> > https://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html#test.run.permutations
> > anything older than 1.5.3 causes problems for libstdc++ (and probably
> > the rest of GCC) because the options in --target_board get placed
> > after the options in dg-options. If the test depends on the options in
> > dg-options to work properly it might fail. For example, a test that
> > has { dg-options "-O2" } and fails without optimisation would FAIL if
> > you use --target_board=unix/-O0 with dejagnu 1.5.
> >
> I think that was commit:
> http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commitdiff;h=5256bd82343000c76bc0e48139003f90b6184347
> which for sure was a major change (though I don't see it documented in
> dejagnu/NEWS file)


Yes, that's the one.

Re: dejagnu version update?

[Christophe Lyon via Gcc]

On Wed, 13 May 2020 at 19:44, Jonathan Wakely via Gcc  wrote:
>
> On Wed, 13 May 2020 at 18:19, Mike Stump via Gcc  wrote:
> >
> > I've changed the subject to match the 2015, 2017 and 2018 email threads.
> >
> > On May 13, 2020, at 3:26 AM, Thomas Schwinge  
> > wrote:
> > >
> > > Comparing DejaGnu/GCC testsuite '*.sum' files between two systems ("old"
> > > vs. "new") that ought to return identical results, I found that they
> > > didn't:
> >
> > > I have not found any evidence in DejaGnu master branch that this not
> > > working would've been a "recent" DejaGnu regression (and then fixed for
> > > DejaGnu 1.6) -- so do we have to assume that this never worked as
> > > intended back then?
> >
> > Likely not.
> >
> > > Per our "Prerequisites for GCC" installation documentation, we currently
> > > require DejaGnu 1.4.4.  Advancing that to 1.6 is probably out of
> > > question, given that it has "just" been released (four years ago).
> >
> > :-)  A user that wants full coverage should use 1.6, apparently.
>
> As documented at
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html#test.run.permutations
> anything older than 1.5.3 causes problems for libstdc++ (and probably
> the rest of GCC) because the options in --target_board get placed
> after the options in dg-options. If the test depends on the options in
> dg-options to work properly it might fail. For example, a test that
> has { dg-options "-O2" } and fails without optimisation would FAIL if
> you use --target_board=unix/-O0 with dejagnu 1.5.
>
I think that was commit:
http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commitdiff;h=5256bd82343000c76bc0e48139003f90b6184347
which for sure was a major change (though I don't see it documented in
dejagnu/NEWS file)

>
> > > As the failure mode with old DejaGnu is "benign" (only causes missing
> > > execution testing), we could simply move on, and accept non-reproducible
> > > results between different DejaGnu versions?  Kind of lame...  ;-|
> >
> > An ugly wart to be sure.
> >
> > So, now that ubuntu 20.04 is out and RHEL 8 is out, and they both contain 
> > 6, and SLES has 6 and since we've been sitting at 1.4.4 for so long, anyone 
> > want to not update dejagnu to require 1.6?
>
> There are still lots of older systems in use for GCC dev, like all the
> POWER servers in the compile farm (but I've put a recent dejagnu in
> /opt/cfarm on some of them).
>
> > I had previously approved the update to 1.5.3, but no one really wanted it 
> > as no one updated the requirement.  Let's have the 1.6 discussion.  I'm not 
> > only inclined to up to 1.6, but to actually edit it in this time.
>
> Would the tests actually refuse to run with an older version?
>
> > Anyone strongly against?  Why?
>
> I'm in favour of requiring 1.5.3 or later, so 1.6 would be OK for me.

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

On Wed, 13 May 2020, Rainer Orth wrote:

> > I'm in favour of requiring 1.5.3 or later, so 1.6 would be OK for me.
> 
> If we go beyond 1.5.x, we need to go all the way up to 1.6.2: 1.6 and
> 1.6.1 have an ugly bug that can miss timeouts, causing tests to hang
> indefinitely until one manually kills them.

 Would you mind sharing a reference such as a DejaGNU Git commit ID of the 
fix for the bug you mean?

 Versions 1.6 and 1.6.1 seem ubiquitous and coincidentally earlier this 
very week I have been chasing a phenomenon with Expect's `wait' semantics 
causing a reliable hang in remote testing if `ssh' to the target board 
stops responding for whatever reason.  I have come up with a solution 
(that I'd be happy to upstream, except that DejaGNU maintenance seems to 
have been dead for like a year now), which I have also confirmed to be 
required with current DejaGNU Git master so it must be a different one, 
and I would like to know how it might be related to the bug you mention.

  Maciej

Re: dejagnu version update?

[Rainer Orth]

Jonathan Wakely via Gcc  writes:

>> I had previously approved the update to 1.5.3, but no one really wanted
>> it as no one updated the requirement.  Let's have the 1.6 discussion.
>> I'm not only inclined to up to 1.6, but to actually edit it in this time.
>
> Would the tests actually refuse to run with an older version?
>
>> Anyone strongly against?  Why?
>
> I'm in favour of requiring 1.5.3 or later, so 1.6 would be OK for me.

If we go beyond 1.5.x, we need to go all the way up to 1.6.2: 1.6 and
1.6.1 have an ugly bug that can miss timeouts, causing tests to hang
indefinitely until one manually kills them.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: dejagnu version update?

[Rob Savoye]

On 5/13/20 10:51 AM, Mike Stump wrote:

> So, now that ubuntu 20.04 is out and RHEL 8 is out, and they both
> contain 6, and SLES has 6 and since we've been sitting at 1.4.4 for
> so long, anyone want to not update dejagnu to require 1.6?

  We do still find and fix bugs occasionally. :-) And 1.4.4 was released
16 years ago... Linaro has been using the most recent release for years,
so I think it's a safe upgrade.

- rob -
---
https://www.senecass.com

Re: dejagnu version update?

[Jonathan Wakely via Gcc]

On Wed, 13 May 2020 at 18:19, Mike Stump via Gcc  wrote:
>
> I've changed the subject to match the 2015, 2017 and 2018 email threads.
>
> On May 13, 2020, at 3:26 AM, Thomas Schwinge  wrote:
> >
> > Comparing DejaGnu/GCC testsuite '*.sum' files between two systems ("old"
> > vs. "new") that ought to return identical results, I found that they
> > didn't:
>
> > I have not found any evidence in DejaGnu master branch that this not
> > working would've been a "recent" DejaGnu regression (and then fixed for
> > DejaGnu 1.6) -- so do we have to assume that this never worked as
> > intended back then?
>
> Likely not.
>
> > Per our "Prerequisites for GCC" installation documentation, we currently
> > require DejaGnu 1.4.4.  Advancing that to 1.6 is probably out of
> > question, given that it has "just" been released (four years ago).
>
> :-)  A user that wants full coverage should use 1.6, apparently.

As documented at
https://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html#test.run.permutations
anything older than 1.5.3 causes problems for libstdc++ (and probably
the rest of GCC) because the options in --target_board get placed
after the options in dg-options. If the test depends on the options in
dg-options to work properly it might fail. For example, a test that
has { dg-options "-O2" } and fails without optimisation would FAIL if
you use --target_board=unix/-O0 with dejagnu 1.5.


> > As the failure mode with old DejaGnu is "benign" (only causes missing
> > execution testing), we could simply move on, and accept non-reproducible
> > results between different DejaGnu versions?  Kind of lame...  ;-|
>
> An ugly wart to be sure.
>
> So, now that ubuntu 20.04 is out and RHEL 8 is out, and they both contain 6, 
> and SLES has 6 and since we've been sitting at 1.4.4 for so long, anyone want 
> to not update dejagnu to require 1.6?

There are still lots of older systems in use for GCC dev, like all the
POWER servers in the compile farm (but I've put a recent dejagnu in
/opt/cfarm on some of them).

> I had previously approved the update to 1.5.3, but no one really wanted it as 
> no one updated the requirement.  Let's have the 1.6 discussion.  I'm not only 
> inclined to up to 1.6, but to actually edit it in this time.

Would the tests actually refuse to run with an older version?

> Anyone strongly against?  Why?

I'm in favour of requiring 1.5.3 or later, so 1.6 would be OK for me.

dejagnu version update?

[Mike Stump via Gcc]

I've changed the subject to match the 2015, 2017 and 2018 email threads.

On May 13, 2020, at 3:26 AM, Thomas Schwinge  wrote:
> 
> Comparing DejaGnu/GCC testsuite '*.sum' files between two systems ("old"
> vs. "new") that ought to return identical results, I found that they
> didn't:

> I have not found any evidence in DejaGnu master branch that this not
> working would've been a "recent" DejaGnu regression (and then fixed for
> DejaGnu 1.6) -- so do we have to assume that this never worked as
> intended back then?

Likely not.

> Per our "Prerequisites for GCC" installation documentation, we currently
> require DejaGnu 1.4.4.  Advancing that to 1.6 is probably out of
> question, given that it has "just" been released (four years ago).

:-)  A user that wants full coverage should use 1.6, apparently.

> As the failure mode with old DejaGnu is "benign" (only causes missing
> execution testing), we could simply move on, and accept non-reproducible
> results between different DejaGnu versions?  Kind of lame...  ;-|

An ugly wart to be sure.

So, now that ubuntu 20.04 is out and RHEL 8 is out, and they both contain 6, 
and SLES has 6 and since we've been sitting at 1.4.4 for so long, anyone want 
to not update dejagnu to require 1.6?

I had previously approved the update to 1.5.3, but no one really wanted it as 
no one updated the requirement.  Let's have the 1.6 discussion.  I'm not only 
inclined to up to 1.6, but to actually edit it in this time.

Anyone strongly against?  Why?

Re: dejagnu version update?

[Segher Boessenkool]

On Wed, Aug 08, 2018 at 01:17:49PM +0200, Bernhard Reutner-Fischer wrote:
> On 7 August 2018 18:34:30 CEST, Segher Boessenkool 
>  wrote:
> >On Mon, Aug 06, 2018 at 08:25:49AM -0700, Mike Stump wrote:
> >> Since g++ already requires 1.5.3, it make no sense to bump to
> >anything older that 1.5.3, so let's bump to 1.5.3.  Those packaging
> >systems and OSes that wanted to update by now, have had their chance to
> >update.  Those that punt until we bump the requirement, well, they will
> >now have to bump.  :-)
> >
> >"g++ requires it"?  In what way?  I haven't seen any issues with older
> >dejagnu versions.
> 
> I think 
> http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5256bd82343000c76bc0e48139003f90b6184347

Ugh.

If there is a conflict between the test-specific options and the testsuite
run options, sometimes you should pick one, sometimes the other, and often
skipping the test is best.  Older dejagnu picked the run options, and now
newer dejagnu picks the test-specific options, so now we cannot rely on
*either* behaviour.  At least for many years to come: we share most
testcases with older GCC versions, which do not require dejagnu 1.5.3!

What a mess.


Segher

Re: dejagnu version update?

[Michael Matz]

Hi,

On Wed, 8 Aug 2018, Bernhard Reutner-Fischer wrote:

> How come?
> 
> If one wants to develop on a distro that is notoriously outdated then 
> you have to obtain the missing pieces yourself.

It's not about developing on an "notoriously outdated" distro, but about 
_testing_ on it.  There are very good reasons to test the quality of a 
compiler also on older distros.

> I wouldn't call three years "aggressive".

But even independend from the above I would.


Ciao,
Michael.

Re: dejagnu version update?

[Richard Earnshaw (lists)]

On 08/08/18 12:17, Bernhard Reutner-Fischer wrote:
> On 7 August 2018 18:34:30 CEST, Segher Boessenkool 
>  wrote:
>> On Mon, Aug 06, 2018 at 08:25:49AM -0700, Mike Stump wrote:
>>> Since g++ already requires 1.5.3, it make no sense to bump to
>> anything older that 1.5.3, so let's bump to 1.5.3.  Those packaging
>> systems and OSes that wanted to update by now, have had their chance to
>> update.  Those that punt until we bump the requirement, well, they will
>> now have to bump.  :-)
>>
>> "g++ requires it"?  In what way?  I haven't seen any issues with older
>> dejagnu versions.
> 
> I think 
> http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5256bd82343000c76bc0e48139003f90b6184347
> 
>>
>>> Ok to update to 1.5.3.
>>
>> 1.5.3 is only three years old, and not all distros carry it.  This is
>> rather aggressive...
> 
> How come?
> If one wants to develop on a distro that is notoriously outdated then you 
> have to obtain the missing pieces yourself. I wouldn't call three years 
> "aggressive".
> 

I would.

IT departments don't upgrade every machine each time a new distribution
comes out.  They expect to install one version (plus the security
updates, of course) on that machine for its lifetime.  Assuming new
distros are released every couple of years (quite aggressive) and that
IT groups also start installing the new version immediately it is
released on those new machines (extremely aggressive), you've got a 5
year life-cycle for software if you work on the basis that a machine is
expected to last three years.

So in practice, I think 6 years is more like that timeframe that needs
to be considered for these things and even that is quite aggressive.
Some machines have to run older versions of the OS simply because other
software running on them *has* to use an older OS release.

R.

Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On 7 August 2018 18:34:30 CEST, Segher Boessenkool  
wrote:
>On Mon, Aug 06, 2018 at 08:25:49AM -0700, Mike Stump wrote:
>> Since g++ already requires 1.5.3, it make no sense to bump to
>anything older that 1.5.3, so let's bump to 1.5.3.  Those packaging
>systems and OSes that wanted to update by now, have had their chance to
>update.  Those that punt until we bump the requirement, well, they will
>now have to bump.  :-)
>
>"g++ requires it"?  In what way?  I haven't seen any issues with older
>dejagnu versions.

I think 
http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5256bd82343000c76bc0e48139003f90b6184347

>
>> Ok to update to 1.5.3.
>
>1.5.3 is only three years old, and not all distros carry it.  This is
>rather aggressive...

How come?
If one wants to develop on a distro that is notoriously outdated then you have 
to obtain the missing pieces yourself. I wouldn't call three years "aggressive".

Re: dejagnu version update?

[Segher Boessenkool]

On Mon, Aug 06, 2018 at 08:25:49AM -0700, Mike Stump wrote:
> Since g++ already requires 1.5.3, it make no sense to bump to anything older 
> that 1.5.3, so let's bump to 1.5.3.  Those packaging systems and OSes that 
> wanted to update by now, have had their chance to update.  Those that punt 
> until we bump the requirement, well, they will now have to bump.  :-)

"g++ requires it"?  In what way?  I haven't seen any issues with older
dejagnu versions.

> Ok to update to 1.5.3.

1.5.3 is only three years old, and not all distros carry it.  This is
rather aggressive...


Segher

Re: dejagnu version update?

[Mike Stump]

On Aug 4, 2018, at 9:32 AM, Bernhard Reutner-Fischer  
wrote:
> On Tue, 16 May 2017 at 21:08, Mike Stump  wrote:
>> 
>> On May 16, 2017, at 5:16 AM, Jonathan Wakely  wrote:
>>> The change I care about in 1.5.3
>> 
>> So, we haven't talked much about the version people want most.  If we 
>> update, might as well get something that more people care about.  1.5.3 is 
>> in ubuntu LTS 16.04 and Fedora 24, so it's been around awhile.  SUSU is said 
>> to be using 1.6, in the post 1.4.4 systems.  People stated they want 1.5.2 
>> and 1.5.3, so, I'm inclined to say, let's shoot for 1.5.3 when we do update.
>> 
>> As for the machines in the FSF compile farm, nah, tail wagging the dog.  I'd 
>> rather just update the requirement, and the owners or users of those 
>> machines can install a new dejagnu, if they are using one that is too old 
>> and they want to support testing gcc.
> 
> So.. let me ping that, again, now that another year has passed :)

Putting on my random engineer hat, does Centos 7 have a patch in it?  My system 
says 1.5.1.

Since g++ already requires 1.5.3, it make no sense to bump to anything older 
that 1.5.3, so let's bump to 1.5.3.  Those packaging systems and OSes that 
wanted to update by now, have had their chance to update.  Those that punt 
until we bump the requirement, well, they will now have to bump.  :-)

Ok to update to 1.5.3.

I'll pre-approve the patches to simplify and remove work arounds from the 
testsuite that cater to older versions.

If an RM wants to push the approval to sometime later (post a release branch 
creation point for example), let's give them a few days to request deferral.  I 
don't want to impact any next release in a way an RM doesn't want.  RM approval 
for back ports, I think we don't want to back port to a previous release, but 
I'm happy to defer to RM; if they want to do it.

Re: dejagnu version update?

[Jonathan Wakely]

On Sat, 4 Aug 2018 at 17:32, Bernhard Reutner-Fischer wrote:
> debian-stable (i think 9 ATM), Ubuntu LTS ship versions recent enough
> to contain both fixes. Commercial distros seem to ship fixed versions,
> too.

The CentOS 7.4.1708 version on gcc112 doesn't seem to be fixed.

Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On Tue, 16 May 2017 at 21:08, Mike Stump  wrote:
>
> On May 16, 2017, at 5:16 AM, Jonathan Wakely  wrote:
> > The change I care about in 1.5.3
>
> So, we haven't talked much about the version people want most.  If we update, 
> might as well get something that more people care about.  1.5.3 is in ubuntu 
> LTS 16.04 and Fedora 24, so it's been around awhile.  SUSU is said to be 
> using 1.6, in the post 1.4.4 systems.  People stated they want 1.5.2 and 
> 1.5.3, so, I'm inclined to say, let's shoot for 1.5.3 when we do update.
>
> As for the machines in the FSF compile farm, nah, tail wagging the dog.  I'd 
> rather just update the requirement, and the owners or users of those machines 
> can install a new dejagnu, if they are using one that is too old and they 
> want to support testing gcc.

So.. let me ping that, again, now that another year has passed :)

PS: Recap: https://gcc.gnu.org/ml/fortran/2012-03/msg00094.html was
later applied as
http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5481f29161477520c691d525653323b82fa47ad7
and was part of the dejagnu-1.5.2 release from 2015. Jonathan requires
1.5.3 for libstdc++ testing.
The libdirs fix would allow us to remove the 150 occurrences of the
load_gcc_lib hack, refer to the patch to the fortran list back then.
AFAIR this is still not fixed: +# BUG: gcc-dg calls
gcc-set-multilib-library-path but does not load gcc-defs!

debian-stable (i think 9 ATM), Ubuntu LTS ship versions recent enough
to contain both fixes. Commercial distros seem to ship fixed versions,
too.

thanks,

Re: dejagnu version update?

[David Edelsohn]

On Wed, Sep 6, 2017 at 8:48 PM, Jonathan Wakely  wrote:
> On 25 August 2017 at 14:55, David Edelsohn wrote:
>> On Fri, Aug 25, 2017 at 9:50 AM, Rainer Orth
>>  wrote:
>>> Hi H.J.,
>>>
 On Fri, Aug 25, 2017 at 6:32 AM, David Edelsohn  wrote:
> On Fri, Aug 25, 2017 at 9:24 AM, H.J. Lu  wrote:
>> On Fri, Aug 25, 2017 at 6:01 AM, David Edelsohn  
>> wrote:
>>> FYI, DejaGNU 1.6.1 is not compatible with the GCC Testsuite.  The GCC
>>> Testsuite uses "unsetenv" in multiple instances and that feature has
>>> been removed from DejaGNU.  The testsuite is going to experience
>>> DejaGNU errors when Fedora or OpenSUSE upgrades to a more recent
>>> DejaGNU in the 1.6 series.
>>>
>>
>> I am running Fedora 26 with dejagnu-1.6-2.fc26.  What should I
>> look for?
>
> ERROR: (DejaGnu) proc "unsetenv GCC_EXEC_PREFIX" does not exist.
> The error code is NONE
> The info on the error is:
> invalid command name "unsetenv"
> while executing
> "::tcl_unknown unsetenv GCC_EXEC_PREFIX"
> ("uplevel" body line 1)
> invoked from within
> "uplevel 1 ::tcl_unknown $args"
>

 I checked my log.  I didn't see them.  Which log file do they appear in?
>>>
>>> unsetenv was only removed after DejaGnu 1.6 was released.  The change is
>>> in the git repo; so far there exists no post-1.6 release.
>>
>> That is why I wrote 1.6.1.  I didn't know if 1.6-2 was from snapshot after 
>> 1.6.
>
> The -2 is just because the Fedora package got rebuilt, H.J.'s version
> is 1.6, and looking at the Fedora package it's unmodified from the
> upstream 1.6 release. So Fedora doesn't have the change yet, even in
> rawhide.

I reported the impact on the DejaGnu bugs mailing list.  Ben reverted
the change.

dejagnu-git now provides the unsetenv proc.

- David

Re: dejagnu version update?

[Jonathan Wakely]

On 25 August 2017 at 14:55, David Edelsohn wrote:
> On Fri, Aug 25, 2017 at 9:50 AM, Rainer Orth
>  wrote:
>> Hi H.J.,
>>
>>> On Fri, Aug 25, 2017 at 6:32 AM, David Edelsohn  wrote:
 On Fri, Aug 25, 2017 at 9:24 AM, H.J. Lu  wrote:
> On Fri, Aug 25, 2017 at 6:01 AM, David Edelsohn  wrote:
>> FYI, DejaGNU 1.6.1 is not compatible with the GCC Testsuite.  The GCC
>> Testsuite uses "unsetenv" in multiple instances and that feature has
>> been removed from DejaGNU.  The testsuite is going to experience
>> DejaGNU errors when Fedora or OpenSUSE upgrades to a more recent
>> DejaGNU in the 1.6 series.
>>
>
> I am running Fedora 26 with dejagnu-1.6-2.fc26.  What should I
> look for?

 ERROR: (DejaGnu) proc "unsetenv GCC_EXEC_PREFIX" does not exist.
 The error code is NONE
 The info on the error is:
 invalid command name "unsetenv"
 while executing
 "::tcl_unknown unsetenv GCC_EXEC_PREFIX"
 ("uplevel" body line 1)
 invoked from within
 "uplevel 1 ::tcl_unknown $args"

>>>
>>> I checked my log.  I didn't see them.  Which log file do they appear in?
>>
>> unsetenv was only removed after DejaGnu 1.6 was released.  The change is
>> in the git repo; so far there exists no post-1.6 release.
>
> That is why I wrote 1.6.1.  I didn't know if 1.6-2 was from snapshot after 
> 1.6.

The -2 is just because the Fedora package got rebuilt, H.J.'s version
is 1.6, and looking at the Fedora package it's unmodified from the
upstream 1.6 release. So Fedora doesn't have the change yet, even in
rawhide.

Re: dejagnu version update?

[Winfried Magerl]

Hi,

On Fri, Aug 25, 2017 at 09:55:29AM -0400, David Edelsohn wrote:
> On Fri, Aug 25, 2017 at 9:50 AM, Rainer Orth
>  wrote:
> > Hi H.J.,
> >
> >> On Fri, Aug 25, 2017 at 6:32 AM, David Edelsohn  wrote:
> >>> On Fri, Aug 25, 2017 at 9:24 AM, H.J. Lu  wrote:
>  On Fri, Aug 25, 2017 at 6:01 AM, David Edelsohn  
>  wrote:
> > FYI, DejaGNU 1.6.1 is not compatible with the GCC Testsuite.  The GCC
> > Testsuite uses "unsetenv" in multiple instances and that feature has
> > been removed from DejaGNU.  The testsuite is going to experience
> > DejaGNU errors when Fedora or OpenSUSE upgrades to a more recent
> > DejaGNU in the 1.6 series.
> >
> 
>  I am running Fedora 26 with dejagnu-1.6-2.fc26.  What should I
>  look for?
> >>>
> >>> ERROR: (DejaGnu) proc "unsetenv GCC_EXEC_PREFIX" does not exist.
> >>> The error code is NONE
> >>> The info on the error is:
> >>> invalid command name "unsetenv"
> >>> while executing
> >>> "::tcl_unknown unsetenv GCC_EXEC_PREFIX"
> >>> ("uplevel" body line 1)
> >>> invoked from within
> >>> "uplevel 1 ::tcl_unknown $args"
> >>>
> >>
> >> I checked my log.  I didn't see them.  Which log file do they appear in?
> >
> > unsetenv was only removed after DejaGnu 1.6 was released.  The change is
> > in the git repo; so far there exists no post-1.6 release.
> 
> That is why I wrote 1.6.1.  I didn't know if 1.6-2 was from snapshot after 
> 1.6.
> 
> Future releases of DejaGNU will elicit errors from the GCC Testsuite
> as currently written.  My message is a warning about future
> incompatibility.

from the current git-branch:

 +Changes since 1.6:
 +
 +1. The user-visible utility procedure `unsetenv' has been removed.  If
 +   a testsuite uses any of these procedures, a copy of the procedure
 +   should be made and placed in the lib directory of the testsuite.
 +

gcc is not the only testsuite which breaks. From a quick look on
some of my local source-packages:

 Python-2.7.13
 Python-3.6.2
 libffi-3.2.1
 gcc-7.2.0

Maybe reporting this to the dejagnu-developers might be the better
approach:

author   Ben Elliston  2016-04-24 20:46:53 +1000
committer Ben Elliston  2016-04-24 20:46:53 +1000
commit   c7185dfb66b0b278709d869ba020eec8348796ef (patch)

regards

winfried

Re: dejagnu version update?

[David Edelsohn]

On Fri, Aug 25, 2017 at 9:50 AM, Rainer Orth
 wrote:
> Hi H.J.,
>
>> On Fri, Aug 25, 2017 at 6:32 AM, David Edelsohn  wrote:
>>> On Fri, Aug 25, 2017 at 9:24 AM, H.J. Lu  wrote:
 On Fri, Aug 25, 2017 at 6:01 AM, David Edelsohn  wrote:
> FYI, DejaGNU 1.6.1 is not compatible with the GCC Testsuite.  The GCC
> Testsuite uses "unsetenv" in multiple instances and that feature has
> been removed from DejaGNU.  The testsuite is going to experience
> DejaGNU errors when Fedora or OpenSUSE upgrades to a more recent
> DejaGNU in the 1.6 series.
>

 I am running Fedora 26 with dejagnu-1.6-2.fc26.  What should I
 look for?
>>>
>>> ERROR: (DejaGnu) proc "unsetenv GCC_EXEC_PREFIX" does not exist.
>>> The error code is NONE
>>> The info on the error is:
>>> invalid command name "unsetenv"
>>> while executing
>>> "::tcl_unknown unsetenv GCC_EXEC_PREFIX"
>>> ("uplevel" body line 1)
>>> invoked from within
>>> "uplevel 1 ::tcl_unknown $args"
>>>
>>
>> I checked my log.  I didn't see them.  Which log file do they appear in?
>
> unsetenv was only removed after DejaGnu 1.6 was released.  The change is
> in the git repo; so far there exists no post-1.6 release.

That is why I wrote 1.6.1.  I didn't know if 1.6-2 was from snapshot after 1.6.

Future releases of DejaGNU will elicit errors from the GCC Testsuite
as currently written.  My message is a warning about future
incompatibility.

Thanks, David

Re: dejagnu version update?

[Rainer Orth]

Hi H.J.,

> On Fri, Aug 25, 2017 at 6:32 AM, David Edelsohn  wrote:
>> On Fri, Aug 25, 2017 at 9:24 AM, H.J. Lu  wrote:
>>> On Fri, Aug 25, 2017 at 6:01 AM, David Edelsohn  wrote:
 FYI, DejaGNU 1.6.1 is not compatible with the GCC Testsuite.  The GCC
 Testsuite uses "unsetenv" in multiple instances and that feature has
 been removed from DejaGNU.  The testsuite is going to experience
 DejaGNU errors when Fedora or OpenSUSE upgrades to a more recent
 DejaGNU in the 1.6 series.

>>>
>>> I am running Fedora 26 with dejagnu-1.6-2.fc26.  What should I
>>> look for?
>>
>> ERROR: (DejaGnu) proc "unsetenv GCC_EXEC_PREFIX" does not exist.
>> The error code is NONE
>> The info on the error is:
>> invalid command name "unsetenv"
>> while executing
>> "::tcl_unknown unsetenv GCC_EXEC_PREFIX"
>> ("uplevel" body line 1)
>> invoked from within
>> "uplevel 1 ::tcl_unknown $args"
>>
>
> I checked my log.  I didn't see them.  Which log file do they appear in?

unsetenv was only removed after DejaGnu 1.6 was released.  The change is
in the git repo; so far there exists no post-1.6 release.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: dejagnu version update?

[David Edelsohn]

On Fri, Aug 25, 2017 at 9:43 AM, H.J. Lu  wrote:
> On Fri, Aug 25, 2017 at 6:32 AM, David Edelsohn  wrote:
>> On Fri, Aug 25, 2017 at 9:24 AM, H.J. Lu  wrote:
>>> On Fri, Aug 25, 2017 at 6:01 AM, David Edelsohn  wrote:
 FYI, DejaGNU 1.6.1 is not compatible with the GCC Testsuite.  The GCC
 Testsuite uses "unsetenv" in multiple instances and that feature has
 been removed from DejaGNU.  The testsuite is going to experience
 DejaGNU errors when Fedora or OpenSUSE upgrades to a more recent
 DejaGNU in the 1.6 series.

>>>
>>> I am running Fedora 26 with dejagnu-1.6-2.fc26.  What should I
>>> look for?
>>
>> ERROR: (DejaGnu) proc "unsetenv GCC_EXEC_PREFIX" does not exist.
>> The error code is NONE
>> The info on the error is:
>> invalid command name "unsetenv"
>> while executing
>> "::tcl_unknown unsetenv GCC_EXEC_PREFIX"
>> ("uplevel" body line 1)
>> invoked from within
>> "uplevel 1 ::tcl_unknown $args"
>>
>
> I checked my log.  I didn't see them.  Which log file do they appear in?

All log files.  I don't know what is different about the invocation of
DejaGNU directives used by testcases on x86 that avoids the problem in
your runs.

One can see references to unsetenv in GCC Testsuite and those are not
valid for DejaGNU 1.6.1+.

- David

Re: dejagnu version update?

[H.J. Lu]

On Fri, Aug 25, 2017 at 6:32 AM, David Edelsohn  wrote:
> On Fri, Aug 25, 2017 at 9:24 AM, H.J. Lu  wrote:
>> On Fri, Aug 25, 2017 at 6:01 AM, David Edelsohn  wrote:
>>> FYI, DejaGNU 1.6.1 is not compatible with the GCC Testsuite.  The GCC
>>> Testsuite uses "unsetenv" in multiple instances and that feature has
>>> been removed from DejaGNU.  The testsuite is going to experience
>>> DejaGNU errors when Fedora or OpenSUSE upgrades to a more recent
>>> DejaGNU in the 1.6 series.
>>>
>>
>> I am running Fedora 26 with dejagnu-1.6-2.fc26.  What should I
>> look for?
>
> ERROR: (DejaGnu) proc "unsetenv GCC_EXEC_PREFIX" does not exist.
> The error code is NONE
> The info on the error is:
> invalid command name "unsetenv"
> while executing
> "::tcl_unknown unsetenv GCC_EXEC_PREFIX"
> ("uplevel" body line 1)
> invoked from within
> "uplevel 1 ::tcl_unknown $args"
>

I checked my log.  I didn't see them.  Which log file do they appear in?


-- 
H.J.

Re: dejagnu version update?

[David Edelsohn]

On Fri, Aug 25, 2017 at 9:24 AM, H.J. Lu  wrote:
> On Fri, Aug 25, 2017 at 6:01 AM, David Edelsohn  wrote:
>> FYI, DejaGNU 1.6.1 is not compatible with the GCC Testsuite.  The GCC
>> Testsuite uses "unsetenv" in multiple instances and that feature has
>> been removed from DejaGNU.  The testsuite is going to experience
>> DejaGNU errors when Fedora or OpenSUSE upgrades to a more recent
>> DejaGNU in the 1.6 series.
>>
>
> I am running Fedora 26 with dejagnu-1.6-2.fc26.  What should I
> look for?

ERROR: (DejaGnu) proc "unsetenv GCC_EXEC_PREFIX" does not exist.
The error code is NONE
The info on the error is:
invalid command name "unsetenv"
while executing
"::tcl_unknown unsetenv GCC_EXEC_PREFIX"
("uplevel" body line 1)
invoked from within
"uplevel 1 ::tcl_unknown $args"

- David

Re: dejagnu version update?

[H.J. Lu]

On Fri, Aug 25, 2017 at 6:01 AM, David Edelsohn  wrote:
> FYI, DejaGNU 1.6.1 is not compatible with the GCC Testsuite.  The GCC
> Testsuite uses "unsetenv" in multiple instances and that feature has
> been removed from DejaGNU.  The testsuite is going to experience
> DejaGNU errors when Fedora or OpenSUSE upgrades to a more recent
> DejaGNU in the 1.6 series.
>

I am running Fedora 26 with dejagnu-1.6-2.fc26.  What should I
look for?


-- 
H.J.

Re: dejagnu version update?

[David Edelsohn]

FYI, DejaGNU 1.6.1 is not compatible with the GCC Testsuite.  The GCC
Testsuite uses "unsetenv" in multiple instances and that feature has
been removed from DejaGNU.  The testsuite is going to experience
DejaGNU errors when Fedora or OpenSUSE upgrades to a more recent
DejaGNU in the 1.6 series.

- David

Re: dejagnu version update?

[Mike Stump]

On May 16, 2017, at 5:16 AM, Jonathan Wakely  wrote:
> The change I care about in 1.5.3

So, we haven't talked much about the version people want most.  If we update, 
might as well get something that more people care about.  1.5.3 is in ubuntu 
LTS 16.04 and Fedora 24, so it's been around awhile.  SUSU is said to be using 
1.6, in the post 1.4.4 systems.  People stated they want 1.5.2 and 1.5.3, so, 
I'm inclined to say, let's shoot for 1.5.3 when we do update.

As for the machines in the FSF compile farm, nah, tail wagging the dog.  I'd 
rather just update the requirement, and the owners or users of those machines 
can install a new dejagnu, if they are using one that is too old and they want 
to support testing gcc.

Re: dejagnu version update?

[Matthias Klose]

On 16.05.2017 05:35, Bernhard Reutner-Fischer wrote:
> On 16 May 2017 at 14:16, Jonathan Wakely  wrote:
>> On 16 May 2017 at 13:13, Bernhard Reutner-Fischer wrote:
>>> 1.5.0 wouldn't buy us anything as the "libdirs" handling is only in 1.5.2 
>>> and later.
>>
>> Ah I missed that in the earlier discussion.
>>
>> The change I care about in 1.5.3 is
>> http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5256bd82343000c76bc0e48139003f90b6184347
> 
> the libdirs handling is
> http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5481f29161477520c691d525653323b82fa47ad7
> and applies cleanly to everything 1.5.x-ish. Didn't try if it applies to 
> 1.4.4.

this patch is part of dejagnu in Ubuntu 14.04 LTS.

Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On 16 May 2017 at 14:16, Jonathan Wakely  wrote:
> On 16 May 2017 at 13:13, Bernhard Reutner-Fischer wrote:
>> 1.5.0 wouldn't buy us anything as the "libdirs" handling is only in 1.5.2 
>> and later.
>
> Ah I missed that in the earlier discussion.
>
> The change I care about in 1.5.3 is
> http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5256bd82343000c76bc0e48139003f90b6184347

the libdirs handling is
http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5481f29161477520c691d525653323b82fa47ad7
and applies cleanly to everything 1.5.x-ish. Didn't try if it applies to 1.4.4.

thanks,

Re: dejagnu version update?

[Jonathan Wakely]

On 16 May 2017 at 13:13, Bernhard Reutner-Fischer wrote:
> 1.5.0 wouldn't buy us anything as the "libdirs" handling is only in 1.5.2 and 
> later.

Ah I missed that in the earlier discussion.

The change I care about in 1.5.3 is
http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5256bd82343000c76bc0e48139003f90b6184347

Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On 16 May 2017 11:54:18 CEST, Jonathan Wakely  wrote:
>On 13 May 2017 at 11:38, Jakub Jelinek wrote:
>> On Sat, May 13, 2017 at 12:24:12PM +0200, Bernhard Reutner-Fischer
>wrote:
>>> I guess neither redhat
>>> (https://access.redhat.com/downloads/content/dejagnu/ redirects to a
>>> login page but there seem to be 1.5.1 packages) nor SuSE did update
>dejagnu in the meantime.
>>
>> Fedora has dejagnu-1.6 in Fedora 25 and later, dejagnu-1.5.3 in
>Fedora 24, older
>> Fedora versions are EOL.  RHEL 7 has dejagnu-1.5.1, RHEL 6 as well as
>RHEL 5 has
>> dejagnu-1.4.4, older RHEL versions are EOL.
>
>FWIW 1.5.3 has a fix which I rely on for libstdc++ testing, but since
>newer versions are trivial to install by hand I'll be OK if we only
>bump the minimum to 1.5.0

1.5.0 wouldn't buy us anything as the "libdirs" handling is only in 1.5.2 and 
later.

thanks

Re: dejagnu version update?

[Jonathan Wakely]

On 13 May 2017 at 11:38, Jakub Jelinek wrote:
> On Sat, May 13, 2017 at 12:24:12PM +0200, Bernhard Reutner-Fischer wrote:
>> I guess neither redhat
>> (https://access.redhat.com/downloads/content/dejagnu/ redirects to a
>> login page but there seem to be 1.5.1 packages) nor SuSE did update dejagnu 
>> in the meantime.
>
> Fedora has dejagnu-1.6 in Fedora 25 and later, dejagnu-1.5.3 in Fedora 24, 
> older
> Fedora versions are EOL.  RHEL 7 has dejagnu-1.5.1, RHEL 6 as well as RHEL 5 
> has
> dejagnu-1.4.4, older RHEL versions are EOL.

FWIW 1.5.3 has a fix which I rely on for libstdc++ testing, but since
newer versions are trivial to install by hand I'll be OK if we only
bump the minimum to 1.5.0

Re: dejagnu version update?

[Andreas Schwab]

On Mai 15 2017, Mike Stump  wrote:

> That said, a little surprising that SLE is lagging everyone else so
> hard.

DejaGnu doesn't exactly have frequent releases.  Missing just one
release can easily put you more than 5 years behind.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: dejagnu version update?

[Mike Stump]

On May 15, 2017, at 1:06 AM, Richard Biener  wrote:
> 
> Both SLE-11 and SLE-12 use dejagnu 1.4.4, so does openSUSE Leap 42.[12].
> Tumbleweed uses 1.6 so new SLE will inherit that.  But I still do all
> of my testing on systems with just dejagnu 1.4.4.

So dejagnu is independent of most things and downloads and installs in seconds, 
upgrading it shouldn't pose a problem for anyone that can build gcc.

That said, a little surprising that SLE is lagging everyone else so hard.  
Looking at the 42.2 EOL plans, and that would put switching degagnu versions at 
around 13 months from now, if we waited.

So, how much would you mind, for trunk to require a newer a dejagnu?  If just a 
little, I'm inclined to not wait and support updating now.  If please god no, 
then I don't see the harm in waiting 13 months.  Leap 42.3 is out in 3 months, 
so the sooner update time would be just 3 months.  Could you jump to Leap 42.3 
at that time?

Re: dejagnu version update?

[Pedro Alves]

On 05/15/2017 04:54 PM, Martin Jambor wrote:
> Hi,
> 
> On Wed, Sep 16, 2015 at 01:25:18PM -0400, Trevor Saunders wrote:
>> On Wed, Sep 16, 2015 at 10:36:47AM -0600, Jeff Law wrote:
>>>
> 
> ...
> 
>>> I'd rather just move to 1.5 and get on with things.  If some systems don't
>>> have a new enough version, I'm comfortable telling developers on those
>>> platforms that they need to update.  It's not like every *user* needs
>>> dejagnu, it's just for the testing side of things.
>>
>> yeah, it seems like a poor idea to slow down progress we make for all
>> users to benefit a few people who want to develope on rather old
>> machines.
>>

The relying on system dejagnu on old distributions has been a sure
recipe for people avoiding fixing / improving dejagnu.  I mean,
why bother, if your fix will only be generally available in 10 years
when older distros are finally phased out?

> Could we at least make sure that machines in the FSF compile farm have
> a new enough dejagnu before move to requiring at least 1.5?
> 
> I understand that may be a tall order, given that some machines
> (e.g. gcc117) do not have dejagnu at all and this was reported some
> time ago :-(
> 

Maybe download_prerequisites could be taught to handle downloading
and setting up dejagnu [1], making it mostly a non-issue?

[1] Last time I needed to do it, it was mostly plain old
configure/make/make install IIRC, assuming new-enough tcl/expect.
Building a newer tcl/expect would be a bit more work of course.

Thanks,
Pedro Alves

Re: dejagnu version update?

[Martin Jambor]

Hi,

On Wed, Sep 16, 2015 at 01:25:18PM -0400, Trevor Saunders wrote:
> On Wed, Sep 16, 2015 at 10:36:47AM -0600, Jeff Law wrote:
> >

...

> > I'd rather just move to 1.5 and get on with things.  If some systems don't
> > have a new enough version, I'm comfortable telling developers on those
> > platforms that they need to update.  It's not like every *user* needs
> > dejagnu, it's just for the testing side of things.
> 
> yeah, it seems like a poor idea to slow down progress we make for all
> users to benefit a few people who want to develope on rather old
> machines.
> 

Could we at least make sure that machines in the FSF compile farm have
a new enough dejagnu before move to requiring at least 1.5?

I understand that may be a tall order, given that some machines
(e.g. gcc117) do not have dejagnu at all and this was reported some
time ago :-(

Martin

Re: dejagnu version update?

[Richard Biener]

On Mon, May 15, 2017 at 12:09 AM, NightStrike  wrote:
> On Sat, May 13, 2017 at 4:39 PM, Jeff Law  wrote:
>> On 05/13/2017 04:38 AM, Jakub Jelinek wrote:
>>>
>>> On Sat, May 13, 2017 at 12:24:12PM +0200, Bernhard Reutner-Fischer wrote:

 I guess neither redhat
 (https://access.redhat.com/downloads/content/dejagnu/ redirects to a
 login page but there seem to be 1.5.1 packages) nor SuSE did update
 dejagnu in the meantime.
>>>
>>>
>>> Fedora has dejagnu-1.6 in Fedora 25 and later, dejagnu-1.5.3 in Fedora 24,
>>> older
>>> Fedora versions are EOL.  RHEL 7 has dejagnu-1.5.1, RHEL 6 as well as RHEL
>>> 5 has
>>> dejagnu-1.4.4, older RHEL versions are EOL.
>>
>> RHEL-5 is old enough that IMHO it ought not figure into this discussion.
>> RHEL-6 is probably close to if not past that same point as well.
>
> FWIW, I still run the testsuite on RHEL 6.

Both SLE-11 and SLE-12 use dejagnu 1.4.4, so does openSUSE Leap 42.[12].
Tumbleweed uses 1.6 so new SLE will inherit that.  But I still do all
of my testing
on systems with just dejagnu 1.4.4.

Richard.

Re: dejagnu version update?

[NightStrike]

On Sat, May 13, 2017 at 4:39 PM, Jeff Law  wrote:
> On 05/13/2017 04:38 AM, Jakub Jelinek wrote:
>>
>> On Sat, May 13, 2017 at 12:24:12PM +0200, Bernhard Reutner-Fischer wrote:
>>>
>>> I guess neither redhat
>>> (https://access.redhat.com/downloads/content/dejagnu/ redirects to a
>>> login page but there seem to be 1.5.1 packages) nor SuSE did update
>>> dejagnu in the meantime.
>>
>>
>> Fedora has dejagnu-1.6 in Fedora 25 and later, dejagnu-1.5.3 in Fedora 24,
>> older
>> Fedora versions are EOL.  RHEL 7 has dejagnu-1.5.1, RHEL 6 as well as RHEL
>> 5 has
>> dejagnu-1.4.4, older RHEL versions are EOL.
>
> RHEL-5 is old enough that IMHO it ought not figure into this discussion.
> RHEL-6 is probably close to if not past that same point as well.

FWIW, I still run the testsuite on RHEL 6.

Re: dejagnu version update?

[Jeff Law]

On 05/13/2017 04:38 AM, Jakub Jelinek wrote:

On Sat, May 13, 2017 at 12:24:12PM +0200, Bernhard Reutner-Fischer wrote:

I guess neither redhat
(https://access.redhat.com/downloads/content/dejagnu/ redirects to a
login page but there seem to be 1.5.1 packages) nor SuSE did update dejagnu in 
the meantime.


Fedora has dejagnu-1.6 in Fedora 25 and later, dejagnu-1.5.3 in Fedora 24, older
Fedora versions are EOL.  RHEL 7 has dejagnu-1.5.1, RHEL 6 as well as RHEL 5 has
dejagnu-1.4.4, older RHEL versions are EOL.
RHEL-5 is old enough that IMHO it ought not figure into this discussion. 
 RHEL-6 is probably close to if not past that same point as well.


Jeff

Re: dejagnu version update?

[Jakub Jelinek]

On Sat, May 13, 2017 at 12:24:12PM +0200, Bernhard Reutner-Fischer wrote:
> I guess neither redhat
> (https://access.redhat.com/downloads/content/dejagnu/ redirects to a
> login page but there seem to be 1.5.1 packages) nor SuSE did update dejagnu 
> in the meantime.

Fedora has dejagnu-1.6 in Fedora 25 and later, dejagnu-1.5.3 in Fedora 24, older
Fedora versions are EOL.  RHEL 7 has dejagnu-1.5.1, RHEL 6 as well as RHEL 5 has
dejagnu-1.4.4, older RHEL versions are EOL.

Jakub

Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On Tue, Sep 15, 2015 at 10:50:12PM +0200, Bernhard Reutner-Fischer wrote:
> On September 15, 2015 10:05:27 PM GMT+02:00, Jeff Law  wrote:
> >On 09/15/2015 01:21 PM, David Malcolm wrote:
> >> On Tue, 2015-09-15 at 10:39 -0700, Mike Stump wrote:
> >>> On Sep 14, 2015, at 3:37 PM, Jeff Law  wrote:
> > Maybe GCC-6 can bump the required
> > dejagnu version to allow for getting rid of all these superfluous
> > load_gcc_lib? *blink* :)
>  I'd support that as a direction.
> 
>  Certainly dropping the 2001 version from our website in favor of
> >1.5
> >>> (which is what I'm using anyway) would be a step forward.
> >>>
> >>> So, even ubuntu LTS is 1.5 now.  No harm in upgrading the website to
> >>> 1.5.  I don’t know of any reason to not update and just require 1.5
> >at
> >>> this point.  I’m not a fan of feature chasing dejagnu, but an update
> >>> every 2-4 years isn’t unreasonable.
> >>
> >> FWIW, I believe RHEL 6 is at dejagnu-1.4.4   I don't know whether or
> >not
> >> that's an issue here.
> >I'd consider it a non-issue.  Folks that want to do GCC development on 
> >RHEL 6 are probably few and far between and can probably update dejagnu
> >
> >if need be ;-)
> >
> >If ubuntu, fedora, debian current releases were stuck at 1.4, then it'd
> >
> >be a bigger issue.
> 
> Debian sid has 1.5.3 fwiw, so I assume Debian 9 will have that too. Not sure 
> if we can get it into Debian 8, I'm not intimately familiar with the policy. 
> If OTOH GCC-6 requires it then that's probably a strong argument to let it 
> bubble down to Debian 8 if need be.

So Debian 9 will have dejagnu-1.6.

(Ubuntu 16.10 allegedly has 1.6 too)

I guess neither redhat
(https://access.redhat.com/downloads/content/dejagnu/ redirects to a
login page but there seem to be 1.5.1 packages) nor SuSE did update dejagnu in 
the meantime.

Someone should poke gentoo to bump their dejagnu-1.5 to current -1.6

Re: dejagnu version update?

[Richard Earnshaw]

On 16/09/15 17:36, Jeff Law wrote:
> On 09/16/2015 10:25 AM, Ramana Radhakrishnan wrote:
>>
>>
>> On 16/09/15 17:14, Mike Stump wrote:
>>> On Sep 16, 2015, at 12:29 AM, Andreas Schwab 
>>> wrote:
 Mike Stump  writes:

> The software presently works with 1.4.4 and there aren’t any
> changes that require anything newer.

 SLES 12 has 1.4.4.
>>>
>>> Would be nice to cover them as well, but their update schedule, 3-4
>>> years, means that their next update is 2018.  They didn’t update to
>>> a 3 year old stable release of dejagnu for their last OS, meaning
>>> they are on a > 7 year update cycle.  I love embedded and really
>>> long term support cycles (20 years), but, don’t think we should
>>> cater to the 20 year cycle just yet.  :-)  Since 7 is substantially
>>> longer than 2, I don’t think we should worry about it.  If they had
>>> updated at the time, they would have had 3 years of engineering and
>>> testing before the release and _had_ 1.5.
>>>
>>
>> Sorry about the obvious (possibly dumb) question.
>>
>> Can't we just import a copy of dejagnu each year and install it as
>> part of the source tree ? I can't imagine installing dejagnu is
>> adding a huge amount of time to build and regression test time ?
>> Advantage is that everyone is guaranteed to be on the same version. I
>> fully expect resistance due to specific issues with specific versions
>> of tcl and expect, but if folks aren't aware of this .
> That should work -- certainly that's the way we used to do things at
> Cygnus.  Some of that code may have bitrotted as single tree builds have
> fallen out-of-favor through the years.
> 
> As to whether or  not its a good idea.  I'm torn -- I don't like copying
> code from other repos because of the long term maintenance concerns.
> 
> I'd rather just move to 1.5 and get on with things.  If some systems
> don't have a new enough version, I'm comfortable telling developers on
> those platforms that they need to update.  It's not like every *user*
> needs dejagnu, it's just for the testing side of things.
> 
> 
> jeff

I don't see it as a major issue to have your own private build of
dejagnu rather than the system supplied one.  The only local change you
need is to add it to the front of your path before testing.

Dejagnu does not heavily depend on system libraries, it is not built
directly into GCC is pretty independent on the version of expect that
you have on your machine (likely the system version will serve fine).
So why don't we just migrate to the latest and greatest version as our
standard and be done with these old versions that are lying around?

R.

Re: dejagnu version update?

[Segher Boessenkool]

On Wed, Sep 16, 2015 at 01:39:42PM -0400, David Malcolm wrote:
> AIUI, we specifically need >= 1.5.3 (or a version with a backport) to
> get support for multiple load_lib paths mentioned by Bernhard, which is
> what motivated this thread (on gcc-patches, before it spread to the gcc
> list):

We also need it to avoid the "-jN check loses most results in the summary"
problem; or it seems we need to avoid 1.5.2 only for that, if I read the
log correctly.


Segher

Re: dejagnu version update?

[Mike Stump]

On Sep 16, 2015, at 12:02 PM, Bernhard Reutner-Fischer  
wrote:
> Where Joseph said he'd wait some more.. I had thought I asked longer ago than 
> that, time flies if one has fun.
> 
> I'd just require 1.5.3 just to avoid the time needed by folks to workaround 
> those silly ordering gotchas and load cascades that propagate through the 
> tree. Admittedly not my call but a pity IMHO.

If maintanence is a burden for those that usually maintain these things, we can 
by fiat just bump up to 1.5.3. It isn’t the end of the world if we do.  It just 
seems the cost isn’t that high to me, however I’m happy to defer to the people 
in the trench.  Since 1.5 isn’t going to ease what appears to be the main 
issue, I think status quo or 1.5.3 make the most sense.  So, let’s phrase it 
this way, if you work in the trench and are impacted, do you want to see the 
bump to 1.5.3 now to ease the burden?

Re: dejagnu version update?

[Ramana Radhakrishnan]

On Wed, Sep 16, 2015 at 11:27 PM, Mike Stump  wrote:
> On Sep 16, 2015, at 9:25 AM, Ramana Radhakrishnan 
>  wrote:
>>
>> Sorry about the obvious (possibly dumb) question.
>
>> Can't we just import a copy of dejagnu each year and install it as part of 
>> the source tree?
>
> TL;DR: No.

[snip]

Thanks for the refresher on dll hell ;)  My original inspiration for
thinking about the import just as I was leaving for the day was the
whole raft of target libraries we now build with gcc that are imported
 (for convenience, coupling with compiler features etc. etc. ), why
not do the same with what is essentially required for any developer ?
I also see that the coupling for dejagnu is probably best left to
packaging systems - however we have a situations where developers face
version skew for dejagnu with the systems they are forced to develop
and test on. The question was really whether we as a community thought
that this cost with dejagnu was worth it and for someone to ask that
obvious question.

I am happy to settle for dealing with dejagnu the same way as other
prerequisites like gmp, mpfr / mpc i.e. put out a hard error when
testing if the right version of dejagnu is not found. For bonus points
update download_prerequisites to get the right version in the source
tree for people using older distributions and not being in a position
to upgrade their packages.

regards
Ramana

Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On September 16, 2015 7:39:42 PM GMT+02:00, David Malcolm  
wrote:
>On Wed, 2015-09-16 at 10:36 -0600, Jeff Law wrote:
>> On 09/16/2015 10:25 AM, Ramana Radhakrishnan wrote:
>> >
>> >
>> > On 16/09/15 17:14, Mike Stump wrote:
>> >> On Sep 16, 2015, at 12:29 AM, Andreas Schwab 
>> >> wrote:
>> >>> Mike Stump  writes:
>> >>>
>>  The software presently works with 1.4.4 and there aren’t any
>>  changes that require anything newer.
>> >>>
>> >>> SLES 12 has 1.4.4.
>> >>
>> >> Would be nice to cover them as well, but their update schedule,
>3-4
>> >> years, means that their next update is 2018.  They didn’t update
>to
>> >> a 3 year old stable release of dejagnu for their last OS, meaning
>> >> they are on a > 7 year update cycle.  I love embedded and really
>> >> long term support cycles (20 years), but, don’t think we should
>> >> cater to the 20 year cycle just yet.  :-)  Since 7 is
>substantially
>> >> longer than 2, I don’t think we should worry about it.  If they
>had
>> >> updated at the time, they would have had 3 years of engineering
>and
>> >> testing before the release and _had_ 1.5.
>> >>
>> >
>> > Sorry about the obvious (possibly dumb) question.
>> >
>> > Can't we just import a copy of dejagnu each year and install it as
>> > part of the source tree ? I can't imagine installing dejagnu is
>> > adding a huge amount of time to build and regression test time ?
>> > Advantage is that everyone is guaranteed to be on the same version.
>I
>> > fully expect resistance due to specific issues with specific
>versions
>> > of tcl and expect, but if folks aren't aware of this .
>> That should work -- certainly that's the way we used to do things at 
>> Cygnus.  Some of that code may have bitrotted as single tree builds
>have 
>> fallen out-of-favor through the years.
>> 
>> As to whether or  not its a good idea.  I'm torn -- I don't like
>copying 
>> code from other repos because of the long term maintenance concerns.
>> 
>> I'd rather just move to 1.5 and get on with things. 
>
>AIUI, we specifically need >= 1.5.3 (or a version with a backport) to
>get support for multiple load_lib paths mentioned by Bernhard, which is
>what motivated this thread (on gcc-patches, before it spread to the gcc
>list):
> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01196.html
> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00983.html

And
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01395.html

Where Joseph said he'd wait some more.. I had thought I asked longer ago than 
that, time flies if one has fun.

I'd just require 1.5.3 just to avoid the time needed by folks to workaround 
those silly ordering gotchas and load cascades that propagate through the tree. 
Admittedly not my call but a pity IMHO.

Thanks,

Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On September 16, 2015 7:57:03 PM GMT+02:00, Mike Stump  
wrote:
>On Sep 16, 2015, at 9:25 AM, Ramana Radhakrishnan
> wrote:
>> 
>> Sorry about the obvious (possibly dumb) question.
>
>> Can't we just import a copy of dejagnu each year and install it as
>part of the source tree?
>
>TL;DR: No.
>
>We could, and indeed, some people do engineering that way.  We instead
>depend upon package managers, software updates and backwards
>compatibility to manage the issue.  This is generally speaking, a
>better way to do software. In the olden days, back before shared
>libraries, X11 was the straw that broke the camels back. 

[Well some thus later had KGI, GGI and fresco (the interviews thing), but 
that's another story for sure ;) ]

Either way. Importing doesn't make sense at all.

Establishing and maintaining duplicated gcc_load_lib cascades don't either IMO. 
If folks feel maintaining them is less hazzle than forcing a new dejagnu then 
fine with me (although we do require pretty recent libs anyway and developers 
will usually likewise use rather recent binutils et al for obvious reasons).

Re: dejagnu version update?

[Mike Stump]

On Sep 16, 2015, at 9:25 AM, Ramana Radhakrishnan 
 wrote:
> 
> Sorry about the obvious (possibly dumb) question.

> Can't we just import a copy of dejagnu each year and install it as part of 
> the source tree?

TL;DR: No.

We could, and indeed, some people do engineering that way.  We instead depend 
upon package managers, software updates and backwards compatibility to manage 
the issue.  This is generally speaking, a better way to do software. In the 
olden days, back before shared libraries, X11 was the straw that broke the 
camels back.  Without shared libraries, everyone replicated large portions of 
the X11 system inside each binary causing a massive bloat just in terms of disk 
space.  This cost was also reflected in distribution size.  As multiple 
binaries were run, each program would replicate all the code and read only data 
of the X11 window system causing larger than optimal usage of ram.  The problem 
was so fundamental and so compelling to fix that dllhell[1] was born.  It was 
the price we paid, for the solution to the original problem.  Now, the good 
news is that dllhell is trivial to avoid and engineer around so that it doesn’t 
exist.  People that can program their way out of a paper bag can do it without 
even thinking about it.  So, where we are today, it is a non-issue as it is a 
solved problem.  Since it is solved, we don’t need to do things like unshare 
programs, libraries, kernels or executables anymore.  Indeed, it is so 
completely and fundamentally solved that we can now use the desire to unshare 
as an indicator that someone in the food chain doesn’t have a clue what they 
are doing.  Windows is notorious for instances where people have not yet 
attained the right skill set yet.  In our case, since we can contribute 
anything we want, to any package we want, because we are open source, we can 
avoid, fix and do the good engineering required to avoid dllhell.  This makes 
it so that fundamentally, we never have to unshare, by design.  This is but one 
benefit of open source.

One day, we will advance and configure && make will automatically fetch and 
install the required components that we need for a build, using the single 
command that on every system, resolves dependancies and installs dependent 
software.  We aren’t there yet, but, that is were we need to go.  Once we get 
that, we should depend on it and use it, and never look back, then discussions 
like this never ever take place again, because the first person that wanted 
1.5.3 would just put it in, update the 1.4.4 string to 1.5.3 and Bob’s your 
uncle.  No discussion, no asking, no worries.  That’s the path forward.

The current problem is that everyone wants to solve the dependency problem with 
their own tool and that tool is different on every system.  The entire software 
ecosystem would be better off if all these people contributed what they need to 
the design of a replacement and we all moved to one system.

1 - https://en.wikipedia.org/wiki/DLL_Hell

Re: dejagnu version update?

[David Malcolm]

On Wed, 2015-09-16 at 10:36 -0600, Jeff Law wrote:
> On 09/16/2015 10:25 AM, Ramana Radhakrishnan wrote:
> >
> >
> > On 16/09/15 17:14, Mike Stump wrote:
> >> On Sep 16, 2015, at 12:29 AM, Andreas Schwab 
> >> wrote:
> >>> Mike Stump  writes:
> >>>
>  The software presently works with 1.4.4 and there aren’t any
>  changes that require anything newer.
> >>>
> >>> SLES 12 has 1.4.4.
> >>
> >> Would be nice to cover them as well, but their update schedule, 3-4
> >> years, means that their next update is 2018.  They didn’t update to
> >> a 3 year old stable release of dejagnu for their last OS, meaning
> >> they are on a > 7 year update cycle.  I love embedded and really
> >> long term support cycles (20 years), but, don’t think we should
> >> cater to the 20 year cycle just yet.  :-)  Since 7 is substantially
> >> longer than 2, I don’t think we should worry about it.  If they had
> >> updated at the time, they would have had 3 years of engineering and
> >> testing before the release and _had_ 1.5.
> >>
> >
> > Sorry about the obvious (possibly dumb) question.
> >
> > Can't we just import a copy of dejagnu each year and install it as
> > part of the source tree ? I can't imagine installing dejagnu is
> > adding a huge amount of time to build and regression test time ?
> > Advantage is that everyone is guaranteed to be on the same version. I
> > fully expect resistance due to specific issues with specific versions
> > of tcl and expect, but if folks aren't aware of this .
> That should work -- certainly that's the way we used to do things at 
> Cygnus.  Some of that code may have bitrotted as single tree builds have 
> fallen out-of-favor through the years.
> 
> As to whether or  not its a good idea.  I'm torn -- I don't like copying 
> code from other repos because of the long term maintenance concerns.
> 
> I'd rather just move to 1.5 and get on with things. 

AIUI, we specifically need >= 1.5.3 (or a version with a backport) to
get support for multiple load_lib paths mentioned by Bernhard, which is
what motivated this thread (on gcc-patches, before it spread to the gcc
list):
 https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01196.html
 https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00983.html

> If some systems 
> don't have a new enough version, I'm comfortable telling developers on 
> those platforms that they need to update.  It's not like every *user* 
> needs dejagnu, it's just for the testing side of things.
> 
> 
> jeff

Re: dejagnu version update?

[Trevor Saunders]

On Wed, Sep 16, 2015 at 10:36:47AM -0600, Jeff Law wrote:
> On 09/16/2015 10:25 AM, Ramana Radhakrishnan wrote:
> >
> >
> >On 16/09/15 17:14, Mike Stump wrote:
> >>On Sep 16, 2015, at 12:29 AM, Andreas Schwab 
> >>wrote:
> >>>Mike Stump  writes:
> >>>
> The software presently works with 1.4.4 and there aren’t any
> changes that require anything newer.
> >>>
> >>>SLES 12 has 1.4.4.
> >>
> >>Would be nice to cover them as well, but their update schedule, 3-4
> >>years, means that their next update is 2018.  They didn’t update to
> >>a 3 year old stable release of dejagnu for their last OS, meaning
> >>they are on a > 7 year update cycle.  I love embedded and really
> >>long term support cycles (20 years), but, don’t think we should
> >>cater to the 20 year cycle just yet.  :-)  Since 7 is substantially
> >>longer than 2, I don’t think we should worry about it.  If they had
> >>updated at the time, they would have had 3 years of engineering and
> >>testing before the release and _had_ 1.5.
> >>
> >
> >Sorry about the obvious (possibly dumb) question.
> >
> >Can't we just import a copy of dejagnu each year and install it as
> >part of the source tree ? I can't imagine installing dejagnu is
> >adding a huge amount of time to build and regression test time ?
> >Advantage is that everyone is guaranteed to be on the same version. I
> >fully expect resistance due to specific issues with specific versions
> >of tcl and expect, but if folks aren't aware of this .
> That should work -- certainly that's the way we used to do things at Cygnus.
> Some of that code may have bitrotted as single tree builds have fallen
> out-of-favor through the years.
> 
> As to whether or  not its a good idea.  I'm torn -- I don't like copying
> code from other repos because of the long term maintenance concerns.

yeah, there's definitely history showing sharing code by coppying is not
a great idea e.g. top level files getting out of sync.  I'm hopefully
git submodules will make this better soon, but the UI isn't really great
yet.

> I'd rather just move to 1.5 and get on with things.  If some systems don't
> have a new enough version, I'm comfortable telling developers on those
> platforms that they need to update.  It's not like every *user* needs
> dejagnu, it's just for the testing side of things.

yeah, it seems like a poor idea to slow down progress we make for all
users to benefit a few people who want to develope on rather old
machines.

Trev

> 
> 
> jeff

Re: dejagnu version update?

[Jeff Law]

On 09/16/2015 10:25 AM, Ramana Radhakrishnan wrote:



On 16/09/15 17:14, Mike Stump wrote:

On Sep 16, 2015, at 12:29 AM, Andreas Schwab 
wrote:

Mike Stump  writes:


The software presently works with 1.4.4 and there aren’t any
changes that require anything newer.


SLES 12 has 1.4.4.


Would be nice to cover them as well, but their update schedule, 3-4
years, means that their next update is 2018.  They didn’t update to
a 3 year old stable release of dejagnu for their last OS, meaning
they are on a > 7 year update cycle.  I love embedded and really
long term support cycles (20 years), but, don’t think we should
cater to the 20 year cycle just yet.  :-)  Since 7 is substantially
longer than 2, I don’t think we should worry about it.  If they had
updated at the time, they would have had 3 years of engineering and
testing before the release and _had_ 1.5.



Sorry about the obvious (possibly dumb) question.

Can't we just import a copy of dejagnu each year and install it as
part of the source tree ? I can't imagine installing dejagnu is
adding a huge amount of time to build and regression test time ?
Advantage is that everyone is guaranteed to be on the same version. I
fully expect resistance due to specific issues with specific versions
of tcl and expect, but if folks aren't aware of this .
That should work -- certainly that's the way we used to do things at 
Cygnus.  Some of that code may have bitrotted as single tree builds have 
fallen out-of-favor through the years.


As to whether or  not its a good idea.  I'm torn -- I don't like copying 
code from other repos because of the long term maintenance concerns.


I'd rather just move to 1.5 and get on with things.  If some systems 
don't have a new enough version, I'm comfortable telling developers on 
those platforms that they need to update.  It's not like every *user* 
needs dejagnu, it's just for the testing side of things.



jeff

Re: dejagnu version update?

[Ramana Radhakrishnan]

On 16/09/15 17:14, Mike Stump wrote:
> On Sep 16, 2015, at 12:29 AM, Andreas Schwab  wrote:
>> Mike Stump  writes:
>>
>>> The software presently works with 1.4.4 and there aren’t any changes
>>> that require anything newer.
>>
>> SLES 12 has 1.4.4.
> 
> Would be nice to cover them as well, but their update schedule, 3-4 years, 
> means that their next update is 2018.  They didn’t update to a 3 year old 
> stable release of dejagnu for their last OS, meaning they are on a > 7 year 
> update cycle.  I love embedded and really long term support cycles (20 
> years), but, don’t think we should cater to the 20 year cycle just yet.  :-)  
> Since 7 is substantially longer than 2, I don’t think we should worry about 
> it.  If they had updated at the time, they would have had 3 years of 
> engineering and testing before the release and _had_ 1.5.
> 

Sorry about the obvious (possibly dumb) question. 

Can't we just import a copy of dejagnu each year and install it as part of the 
source tree ? I can't imagine installing dejagnu is adding a huge amount of 
time to build and regression test time ? Advantage is that everyone is 
guaranteed to be on the same version. I fully expect resistance due to specific 
issues with specific versions of tcl and expect, but if folks aren't aware of 
this .

regards
Ramana

Re: dejagnu version update?

[Mike Stump]

On Sep 16, 2015, at 12:29 AM, Andreas Schwab  wrote:
> Mike Stump  writes:
> 
>> The software presently works with 1.4.4 and there aren’t any changes
>> that require anything newer.
> 
> SLES 12 has 1.4.4.

Would be nice to cover them as well, but their update schedule, 3-4 years, 
means that their next update is 2018.  They didn’t update to a 3 year old 
stable release of dejagnu for their last OS, meaning they are on a > 7 year 
update cycle.  I love embedded and really long term support cycles (20 years), 
but, don’t think we should cater to the 20 year cycle just yet.  :-)  Since 7 
is substantially longer than 2, I don’t think we should worry about it.  If 
they had updated at the time, they would have had 3 years of engineering and 
testing before the release and _had_ 1.5.

Re: dejagnu version update?

[Andreas Schwab]

Mike Stump  writes:

> The software presently works with 1.4.4 and there aren’t any changes
> that require anything newer.

SLES 12 has 1.4.4.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: dejagnu version update?

[Mike Stump]

On Sep 15, 2015, at 1:04 PM, Jeff Law  wrote:
> Given we haven't updated the dejagnu reqs since ~2001, I think stepping 
> forward would be appropriate and I'd support moving all the way to 1.5.3 with 
> the expectation that we'll be on a cadence of no faster than 2 years going 
> forward.

So, I actually picked 1.5, not at random, but because RHEL 7 has 1.5.1 and 
because ubuntu LTS has 1.5.  The point was for people to get the software for 
free via their normal update mechanisms.  We could go beyond 1.5 if we had a 
compelling need.  I just don’t see the need.  The software presently works with 
1.4.4 and there aren’t any changes that require anything newer.  If the ubuntu 
people and the RHEL people can push 1.5.3 into their update chains, that would 
remove these two reasons to hold back at 1.5.  MacPorts has 1.5.3 already, not 
sure about brew.

If someone wanted to do something major, I’m fine with on demand dejagnu 
release and a bump of gcc and even the release branch to match it.

I don’t have a strong desire to not update past 1.5, if people really would 
like to.  Just a general, would be nice not to have to.

Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On September 15, 2015 10:05:27 PM GMT+02:00, Jeff Law  wrote:
>On 09/15/2015 01:21 PM, David Malcolm wrote:
>> On Tue, 2015-09-15 at 10:39 -0700, Mike Stump wrote:
>>> On Sep 14, 2015, at 3:37 PM, Jeff Law  wrote:
> Maybe GCC-6 can bump the required
> dejagnu version to allow for getting rid of all these superfluous
> load_gcc_lib? *blink* :)
 I'd support that as a direction.

 Certainly dropping the 2001 version from our website in favor of
>1.5
>>> (which is what I'm using anyway) would be a step forward.
>>>
>>> So, even ubuntu LTS is 1.5 now.  No harm in upgrading the website to
>>> 1.5.  I don’t know of any reason to not update and just require 1.5
>at
>>> this point.  I’m not a fan of feature chasing dejagnu, but an update
>>> every 2-4 years isn’t unreasonable.
>>
>> FWIW, I believe RHEL 6 is at dejagnu-1.4.4   I don't know whether or
>not
>> that's an issue here.
>I'd consider it a non-issue.  Folks that want to do GCC development on 
>RHEL 6 are probably few and far between and can probably update dejagnu
>
>if need be ;-)
>
>If ubuntu, fedora, debian current releases were stuck at 1.4, then it'd
>
>be a bigger issue.

Debian sid has 1.5.3 fwiw, so I assume Debian 9 will have that too. Not sure if 
we can get it into Debian 8, I'm not intimately familiar with the policy. If 
OTOH GCC-6 requires it then that's probably a strong argument to let it bubble 
down to Debian 8 if need be.
Widespread other buildsystems should pose no problem, dunno about the big 
non-debian distros in this respect.

Thanks,

Re: dejagnu version update?

[Jeff Law]

On 09/15/2015 01:21 PM, David Malcolm wrote:

On Tue, 2015-09-15 at 10:39 -0700, Mike Stump wrote:

On Sep 14, 2015, at 3:37 PM, Jeff Law  wrote:

Maybe GCC-6 can bump the required
dejagnu version to allow for getting rid of all these superfluous
load_gcc_lib? *blink* :)

I'd support that as a direction.

Certainly dropping the 2001 version from our website in favor of 1.5

(which is what I'm using anyway) would be a step forward.

So, even ubuntu LTS is 1.5 now.  No harm in upgrading the website to
1.5.  I don’t know of any reason to not update and just require 1.5 at
this point.  I’m not a fan of feature chasing dejagnu, but an update
every 2-4 years isn’t unreasonable.


FWIW, I believe RHEL 6 is at dejagnu-1.4.4   I don't know whether or not
that's an issue here.
I'd consider it a non-issue.  Folks that want to do GCC development on 
RHEL 6 are probably few and far between and can probably update dejagnu 
if need be ;-)


If ubuntu, fedora, debian current releases were stuck at 1.4, then it'd 
be a bigger issue.


jeff

Re: dejagnu version update?

[Jeff Law]

On 09/15/2015 01:23 PM, Bernhard Reutner-Fischer wrote:

On September 15, 2015 7:39:39 PM GMT+02:00, Mike Stump
 wrote:

On Sep 14, 2015, at 3:37 PM, Jeff Law  wrote:

Maybe GCC-6 can bump the required dejagnu version to allow for
getting rid of all these superfluous load_gcc_lib? *blink* :)

I'd support that as a direction.

Certainly dropping the 2001 version from our website in favor of
1.5

(which is what I'm using anyway) would be a step forward.

So, even ubuntu LTS is 1.5 now.  No harm in upgrading the website
to 1.5.  I don’t know of any reason to not update and just require
1.5 at this point.  I’m not a fan of feature chasing dejagnu, but
an update every 2-4 years isn’t unreasonable.

So, let’s do it this way…  Any serious and compelling reason to
not update to 1.5?  If none, let’s update to 1.5 in another week or
two, if no serious and compelling reasons not to.

My general plan is, slow cycle updates on dejagnu, maybe every 2
years. LTS style releases should have the version in it before the
requirement is updated.  I take this approach as I think this
should be the maximal change rate of things like make, gcc, g++,
ld, if possible.


Yea, although this means that 1.5.3 (a Version with the libdirs
tweak) being just 5 months old will have to wait another bump, I
fear. For my part going to plain 1.5 is useless WRT the load_lib
situation. I see no value in conditionalizing simplified libdir
handling on a lucky user with recentish stuff so i'm just waiting
another 2 or 4 years for this very minor cleanup.
Given we haven't updated the dejagnu reqs since ~2001, I think stepping 
forward would be appropriate and I'd support moving all the way to 1.5.3 
with the expectation that we'll be on a cadence of no faster than 2 
years going forward.


jeff

Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On September 15, 2015 7:39:39 PM GMT+02:00, Mike Stump  
wrote:
>On Sep 14, 2015, at 3:37 PM, Jeff Law  wrote:
>>> Maybe GCC-6 can bump the required
>>> dejagnu version to allow for getting rid of all these superfluous
>>> load_gcc_lib? *blink* :)
>> I'd support that as a direction.
>> 
>> Certainly dropping the 2001 version from our website in favor of 1.5
>(which is what I'm using anyway) would be a step forward.
>
>So, even ubuntu LTS is 1.5 now.  No harm in upgrading the website to
>1.5.  I don’t know of any reason to not update and just require 1.5 at
>this point.  I’m not a fan of feature chasing dejagnu, but an update
>every 2-4 years isn’t unreasonable.
>
>So, let’s do it this way…  Any serious and compelling reason to not
>update to 1.5?  If none, let’s update to 1.5 in another week or two, if
>no serious and compelling reasons not to.
>
>My general plan is, slow cycle updates on dejagnu, maybe every 2 years.
>LTS style releases should have the version in it before the requirement
>is updated.  I take this approach as I think this should be the maximal
>change rate of things like make, gcc, g++, ld, if possible.

Yea, although this means that 1.5.3 (a Version with the libdirs tweak) being 
just 5 months old will have to wait another bump, I fear. For my part going to 
plain 1.5 is useless WRT the load_lib situation. I see no value in 
conditionalizing simplified libdir handling on a lucky user with recentish 
stuff so i'm just waiting another 2 or 4 years for this very minor cleanup.

Cheers,

Re: dejagnu version update?

[David Malcolm]

On Tue, 2015-09-15 at 10:39 -0700, Mike Stump wrote:
> On Sep 14, 2015, at 3:37 PM, Jeff Law  wrote:
> >> Maybe GCC-6 can bump the required
> >> dejagnu version to allow for getting rid of all these superfluous
> >> load_gcc_lib? *blink* :)
> > I'd support that as a direction.
> > 
> > Certainly dropping the 2001 version from our website in favor of 1.5
> (which is what I'm using anyway) would be a step forward.
> 
> So, even ubuntu LTS is 1.5 now.  No harm in upgrading the website to
> 1.5.  I don’t know of any reason to not update and just require 1.5 at
> this point.  I’m not a fan of feature chasing dejagnu, but an update
> every 2-4 years isn’t unreasonable.

FWIW, I believe RHEL 6 is at dejagnu-1.4.4   I don't know whether or not
that's an issue here.

> So, let’s do it this way…  Any serious and compelling reason to not
> update to 1.5?  If none, let’s update to 1.5 in another week or two,
> if no serious and compelling reasons not to.
> 
> My general plan is, slow cycle updates on dejagnu, maybe every 2
> years.  LTS style releases should have the version in it before the
> requirement is updated.  I take this approach as I think this should
> be the maximal change rate of things like make, gcc, g++, ld, if
> possible.

dejagnu version update?

[Mike Stump]

On Sep 14, 2015, at 3:37 PM, Jeff Law  wrote:
>> Maybe GCC-6 can bump the required
>> dejagnu version to allow for getting rid of all these superfluous
>> load_gcc_lib? *blink* :)
> I'd support that as a direction.
> 
> Certainly dropping the 2001 version from our website in favor of 1.5 (which 
> is what I'm using anyway) would be a step forward.

So, even ubuntu LTS is 1.5 now.  No harm in upgrading the website to 1.5.  I 
don’t know of any reason to not update and just require 1.5 at this point.  I’m 
not a fan of feature chasing dejagnu, but an update every 2-4 years isn’t 
unreasonable.

So, let’s do it this way…  Any serious and compelling reason to not update to 
1.5?  If none, let’s update to 1.5 in another week or two, if no serious and 
compelling reasons not to.

My general plan is, slow cycle updates on dejagnu, maybe every 2 years.  LTS 
style releases should have the version in it before the requirement is updated. 
 I take this approach as I think this should be the maximal change rate of 
things like make, gcc, g++, ld, if possible.