GNU logs - #44462, boring messages

Message sent to bug-dejagnu@HIDDEN:

Subject: bug#44462: Problem with get_multilibs on macOS
Resent-From: Fred Wright <fw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-dejagnu@HIDDEN
Resent-Date: Thu, 05 Nov 2020 04:42:02 +0000
Resent-Message-ID: <handler.44462.B.16045512817768 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 44462 <at> debbugs.gnu.org
Date: Wed, 4 Nov 2020 19:18:30 -0800 (PST)
From: Fred Wright <fw@HIDDEN>
Message-ID: <alpine.OSX.2.23.453.2011041849110.8469@HIDDEN>
User-Agent: Alpine 2.23 (OSX 453 2020-06-18)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Received-SPF: none client-ip=64.142.111.80; envelope-from=fw@HIDDEN;
 helo=c.mail.sonic.net
X-Spam_score_int: -25
X-Spam_score: -2.6
X-Spam_bar: --
X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7,
 SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -2.3 (--)
X-Mailman-Approved-At: Wed, 04 Nov 2020 23:41:16 -0500
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

While investigating some issues in the libffi tests, I came across some 
cases where errors are caused by DejaGnu's get_multilibs function.  For 
some unclear reason, this only seems to get invoked for C++ tests, but 
when it is, there can be a problem, because under some circumstances it 
invokes the compiler with the -dumpspecs option, which is a gcc-only 
option that clang chokes on.  Even when it's using gcc, it bloats the 
logfile with the verbose -dumpspecs output, in order to determine 
something of highly questionable value.

I traced the results of get_multilibs (as used by the libffi tests) in 
many macOS versions, and even the "successful" cases seem to have 
questionably useful results:

 	10.4:		/usr/.
 	10.5:		/usr/.
 	10.6 (x86_64):	/usr/x86_64
 	10.6 (i386):	/usr/.
 	10.7:		/usr/llvm-gcc-4.2/bin/../x86_64
 	10.8:		./x86_64
 	10.9:		./x86_64
 	10.10:		(fails)
 	10.11:		(fails)
 	10.12:		(fails)
 	10.13:		(fails)
 	10.14:		./.
 	10.15:		./.

The "/usr/." result returned on 10.4, 10.5, and 32-bit 10.6 is the same as 
what I see on Ubuntu 14.04, CentOS 7, and Fedora 25, though it's not clear 
to me what it's supposed to represent.

Also note that when I build and test a 32-bit version of libffi on 10.9, 
the get_multilibs result is still "./x86_64".

Since get_multilibs already has code to return an empty string in the 
"remote" case (where it assumes this function won't work), I just added 
code to unix.exp to set multitop to "" for all "darwin" targets, thereby 
short-circuiting almost all og get_multilibs.  That certainly fixes the 
problem with the libffi tests, and doesn't change any non-Mac behavior, 
though I don't know if that's the ideal fix.  The whole get_mutilibs 
function looks pretty ugly anyway, and it's generally recognized that 
relying on -dumpspecs is a bad idea.

I primarily tested my patch against the 1.6.2 release, since the current 
master won't install from a non-git directory, and also has multiple 
failures in its own tests (even on Linux).  The patch is nearly identical 
between the 1.6.2 and master cases, anyway.

I can send the current patch, either as a bare email or as an attachment. 
AFAIK, Savannah doesn't have the pull request / merge request concept.

Fred Wright

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Fred Wright <fw@HIDDEN>
Subject: bug#44462: Acknowledgement (Problem with get_multilibs on macOS)
Message-ID: <handler.44462.B.16045512817768.ack <at> debbugs.gnu.org>
References: <alpine.OSX.2.23.453.2011041849110.8469@HIDDEN>
X-Gnu-PR-Message: ack 44462
X-Gnu-PR-Package: dejagnu
Reply-To: 44462 <at> debbugs.gnu.org
Date: Thu, 05 Nov 2020 04:42:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-dejagnu@HIDDEN

If you wish to submit further information on this problem, please
send it to 44462 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
44462: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D44462
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-dejagnu@HIDDEN:

Subject: bug#44462: Problem with get_multilibs on macOS
Resent-From: Jacob Bachmeyer <jcb62281@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-dejagnu@HIDDEN
Resent-Date: Fri, 06 Nov 2020 03:23:01 +0000
Resent-Message-ID: <handler.44462.B44462.160463294927243 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Fred Wright <fw@HIDDEN>
Cc: 44462 <at> debbugs.gnu.org
Reply-To: jcb62281@HIDDEN
Message-ID: <5FA4C16B.1040300@HIDDEN>
Date: Thu, 05 Nov 2020 21:22:19 -0600
From: Jacob Bachmeyer <jcb62281@HIDDEN>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17
 Mnenhy/0.7.6.0
MIME-Version: 1.0
References: <alpine.OSX.2.23.453.2011041849110.8469@HIDDEN>
In-Reply-To: <alpine.OSX.2.23.453.2011041849110.8469@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Fred Wright wrote:
> While investigating some issues in the libffi tests, I came across 
> some cases where errors are caused by DejaGnu's get_multilibs function.

First, thank you for reporting this issue.  Mac OS X is beyond the set 
of systems where we can run direct tests, so our awareness of problems 
with DejaGnu on Mac OS X depends on bug reports from users.

> For some unclear reason, this only seems to get invoked for C++ tests, 
> but when it is, there can be a problem, because under some 
> circumstances it invokes the compiler with the -dumpspecs option, 
> which is a gcc-only option that clang chokes on.

The irregular usage with only C++ tests seems very odd to me, and I will 
look further into this as time permits.  This may be a bug in the libffi 
testsuite or a bug in DejaGnu.

> Even when it's using gcc, it bloats the logfile with the verbose 
> -dumpspecs output, in order to determine something of highly 
> questionable value.

That value may be less questionable for some targets, or for tests that 
need to be run across each multilib target a GCC instance supports.

> I traced the results of get_multilibs (as used by the libffi tests) in 
> many macOS versions, and even the "successful" cases seem to have 
> questionably useful results:
>
> [...]
>
> The "/usr/." result returned on 10.4, 10.5, and 32-bit 10.6 is the 
> same as what I see on Ubuntu 14.04, CentOS 7, and Fedora 25, though 
> it's not clear to me what it's supposed to represent.

I have a suspicion that this feature is designed to support testing with 
an "experimental" compiler build that is not installed on the system and 
may be useless with system compilers generally, or with Apple's 
compilers specifically, if Apple does not use multilib.

> Also note that when I build and test a 32-bit version of libffi on 
> 10.9, the get_multilibs result is still "./x86_64".

As I do not have access to Mac OS X, I cannot directly explain or verify 
this, but I will look into get_multilibs, in part to document it in a 
future release.

> Since get_multilibs already has code to return an empty string in the 
> "remote" case (where it assumes this function won't work), I just 
> added code to unix.exp to set multitop to "" for all "darwin" targets, 
> thereby short-circuiting almost all og get_multilibs.  That certainly 
> fixes the problem with the libffi tests, and doesn't change any 
> non-Mac behavior, though I don't know if that's the ideal fix.  The 
> whole get_mutilibs function looks pretty ugly anyway, and it's 
> generally recognized that relying on -dumpspecs is a bad idea.

It is most certainly not ideal.  A better solution is probably to add a 
test to get_multilibs to return an empty string if the compiler is not 
GCC.  Of course, if another compiler pretends to be GCC enough to pass 
that check, but does not actually implement -dumpspecs, that is not our bug.

This issue on Mac OS X will probably be a known bug in 1.6.3 and fixed 
in 1.6.4.

> I primarily tested my patch against the 1.6.2 release, since the 
> current master won't install from a non-git directory, and also has 
> multiple failures in its own tests (even on Linux).  The patch is 
> nearly identical between the 1.6.2 and master cases, anyway.

Are we looking at the same current master?  I have commit 
3d62df24deedfb3c7c3e396a31b8ce431138eb49 here and all of the tests pass.

****These other problems are potential release blockers for 1.6.3.****
Can you file another bug report with the test failures and more 
information about these issues?

> I can send the current patch, either as a bare email or as an 
> attachment. AFAIK, Savannah doesn't have the pull request / merge 
> request concept.

This will need to be fixed in libgloss.exp, not unix.exp.  I am putting 
my foot down on fixing bugs in DejaGnu's own tree directly instead of 
hacking around them like that.

-- Jacob

Message sent to bug-dejagnu@HIDDEN:

Subject: bug#44462: Problem with get_multilibs on macOS
Resent-From: Fred Wright <fw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-dejagnu@HIDDEN
Resent-Date: Mon, 09 Nov 2020 00:08:01 +0000
Resent-Message-ID: <handler.44462.B44462.160488046530365 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Jacob Bachmeyer <jcb62281@HIDDEN>
Cc: 44462 <at> debbugs.gnu.org
Date: Sun, 8 Nov 2020 16:07:35 -0800 (PST)
From: Fred Wright <fw@HIDDEN>
In-Reply-To: <5FA4C16B.1040300@HIDDEN>
Message-ID: <alpine.OSX.2.23.453.2011081528320.89665@HIDDEN>
References: <alpine.OSX.2.23.453.2011041849110.8469@HIDDEN>
 <5FA4C16B.1040300@HIDDEN>
User-Agent: Alpine 2.23 (OSX 453 2020-06-18)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

On Thu, 5 Nov 2020, Jacob Bachmeyer wrote:
> Fred Wright wrote:
>> While investigating some issues in the libffi tests, I came across some 
>> cases where errors are caused by DejaGnu's get_multilibs function.
>
> First, thank you for reporting this issue.  Mac OS X is beyond the set of 
> systems where we can run direct tests, so our awareness of problems with 
> DejaGnu on Mac OS X depends on bug reports from users.
>
>> For some unclear reason, this only seems to get invoked for C++ tests, but 
>> when it is, there can be a problem, because under some circumstances it 
>> invokes the compiler with the -dumpspecs option, which is a gcc-only option 
>> that clang chokes on.
>
> The irregular usage with only C++ tests seems very odd to me, and I will look 
> further into this as time permits.  This may be a bug in the libffi testsuite 
> or a bug in DejaGnu.
>
>> Even when it's using gcc, it bloats the logfile with the verbose -dumpspecs 
>> output, in order to determine something of highly questionable value.
>
> That value may be less questionable for some targets, or for tests that need 
> to be run across each multilib target a GCC instance supports.

Even in the useful multilib cases, making that behavior unconditional 
seems like a bad idea, since the client code may have its own iteration 
across architectures, and doing both would either not work or explode the 
multi-architecture handling from O(N) to O(N^2).

>> I traced the results of get_multilibs (as used by the libffi tests) in many 
>> macOS versions, and even the "successful" cases seem to have questionably 
>> useful results:
>> 
>> [...]
>> 
>> The "/usr/." result returned on 10.4, 10.5, and 32-bit 10.6 is the same as 
>> what I see on Ubuntu 14.04, CentOS 7, and Fedora 25, though it's not clear 
>> to me what it's supposed to represent.
>
> I have a suspicion that this feature is designed to support testing with an 
> "experimental" compiler build that is not installed on the system and may be 
> useless with system compilers generally, or with Apple's compilers 
> specifically, if Apple does not use multilib.

Apple supports the concept of multi-architecture binaries, but not in the 
same way that multilib does it (AFAIK).  Macs can have "universal" 
binaries, which are archives combining multiple per-architecture slices. 
This is applicable to object files, shared libraries, and executables.  If
the build setup allows it, it can be as simple as including multiple 
architecture options in the compile command.  E.g.:

 	cc -arch x86_64 -arch i386 -o hello hello.c

Under the hood, the compiler driver runs a separate compile/assemble for 
each architecture, and then combines the object files.  The linker 
supports universal binaries directly.

With this arrangement, architecture-related conditionals in the source 
code work just fine, but what *doesn't* work is having 
architecture-related parameters in a configure script, which is 
unfortunately not as uncommon as it ought to be.

>> Also note that when I build and test a 32-bit version of libffi on 10.9, 
>> the get_multilibs result is still "./x86_64".
>
> As I do not have access to Mac OS X, I cannot directly explain or verify 
> this, but I will look into get_multilibs, in part to document it in a future 
> release.
>
>> Since get_multilibs already has code to return an empty string in the 
>> "remote" case (where it assumes this function won't work), I just added 
>> code to unix.exp to set multitop to "" for all "darwin" targets, thereby 
>> short-circuiting almost all og get_multilibs.  That certainly fixes the 
>> problem with the libffi tests, and doesn't change any non-Mac behavior, 
>> though I don't know if that's the ideal fix.  The whole get_mutilibs 
>> function looks pretty ugly anyway, and it's generally recognized that 
>> relying on -dumpspecs is a bad idea.
>
> It is most certainly not ideal.  A better solution is probably to add a test 
> to get_multilibs to return an empty string if the compiler is not GCC.  Of 
> course, if another compiler pretends to be GCC enough to pass that check, but 
> does not actually implement -dumpspecs, that is not our bug.

Limiting it to gcc would avoid actual failures, but wouldn't avoid 
bloating the logfile with the humongous -dumpspecs output in the many 
cases where the multilibs action isn't even wanted.

The meaning of "pretends to be gcc" isn't well-defined.  It's not uncommon 
to have a compiler named "gcc" which is really clang, largely because 
there are so many projects that think that all compilers of interest are 
named "gcc".  And of course, clang tries to be highly gcc-compatible, to 
facilitate switching to it, but not to the extent of implementing 
-dumpspecs, which is is derived purely from gcc's internal implementation 
details, and was never intended to be used in this fashion.

The libffi test suite comes up with a "compiler_vendor" variable which 
seems to be able to distinguish clang from gcc, though I haven't looked at 
the details.

Fixing get_multilibs properly would probably mean making it both highly 
platform-specific and optional.

> This issue on Mac OS X will probably be a known bug in 1.6.3 and fixed in 
> 1.6.4.
>
>> I primarily tested my patch against the 1.6.2 release, since the current 
>> master won't install from a non-git directory, and also has multiple 
>> failures in its own tests (even on Linux).  The patch is nearly identical 
>> between the 1.6.2 and master cases, anyway.
>
> Are we looking at the same current master?  I have commit 
> 3d62df24deedfb3c7c3e396a31b8ce431138eb49 here and all of the tests pass.
>
> ****These other problems are potential release blockers for 1.6.3.****
> Can you file another bug report with the test failures and more information 
> about these issues?

I looked into this more closely and it's probably related to the non-git 
issue.  When running from a non-git directory, the configure script 
reports a "fatal" error, but then goes on to complete with a zero exit 
status and a more or less buildable setup, so you have to be paying close 
attention to the output to notice.

If this is a typical hack to provide git-based extra information in 
between-release version strings, it should have a fallback for the non-git 
case.  Consider the case of pushing all the git-tracked files to a test 
system with git ls-files and rsync.

>> I can send the current patch, either as a bare email or as an attachment. 
>> AFAIK, Savannah doesn't have the pull request / merge request concept.
>
> This will need to be fixed in libgloss.exp, not unix.exp.  I am putting my 
> foot down on fixing bugs in DejaGnu's own tree directly instead of hacking 
> around them like that.

Well, OK, but there seem to be other similar hacks in unix.exp, and if the 
idea is that get_multilibs is completely useless on the Mac (which appears 
to be the case with the current implemenation, anyway), then disabling it 
in the target-related code doesn't seem unreasonable.

Fred Wright

Message sent to bug-dejagnu@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#44462: Problem with get_multilibs on macOS
Resent-From: Jacob Bachmeyer <jcb62281@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-dejagnu@HIDDEN
Resent-Date: Mon, 09 Nov 2020 03:11:01 +0000
Resent-Message-ID: <handler.44462.B44462.160489142914086 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 44462
X-GNU-PR-Package: dejagnu
X-GNU-PR-Keywords: 
To: Fred Wright <fw@HIDDEN>
Cc: 44462 <at> debbugs.gnu.org
Reply-To: jcb62281@HIDDEN
Received: via spool by 44462-submit <at> debbugs.gnu.org id=B44462.160489142914086
          (code B ref 44462); Mon, 09 Nov 2020 03:11:01 +0000
Received: (at 44462) by debbugs.gnu.org; 9 Nov 2020 03:10:29 +0000
Received: from localhost ([127.0.0.1]:33276 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kbxZd-0003f6-4S
	for submit <at> debbugs.gnu.org; Sun, 08 Nov 2020 22:10:29 -0500
Received: from mail-oi1-f182.google.com ([209.85.167.182]:34267)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <jcb62281@HIDDEN>) id 1kbxZa-0003er-2q
 for 44462 <at> debbugs.gnu.org; Sun, 08 Nov 2020 22:10:27 -0500
Received: by mail-oi1-f182.google.com with SMTP id w188so3262298oib.1
 for <44462 <at> debbugs.gnu.org>; Sun, 08 Nov 2020 19:10:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject
 :references:in-reply-to:content-transfer-encoding;
 bh=BY6Tnprq1NTjl/9cnO/xWTBR41aqYIrlujf6vVrVdzw=;
 b=jgjSLJnSJLxJSfX1OyxVnW6fbe74v3vdBj5DQc11NNqDGtYkhcFTG+0+Fh4DU52dJ1
 Un2OAW8QtuI1y/11F7faOj1+aGYy0vrkfLWEjN4tRipM66conzckcDWPHhrbxeDfTFMd
 g6WcTzkaXsWJK9CrGF8o/H2G0LOvamA13Z7vcdUwbs7uGLutfz1hkp9MQHwXrPGKFmIf
 ocvc1FHmtuCRfazJ59YEsSy3H1Eh7YUtI1x1i5L59Ti15sL6eOpecfyEln+PLF1Zqcll
 5wlTQwYo1sFnQXQvdzaytJUFaTFiaxEDdCluvqbBr+Fr4P/YaSNY4v88hwYPY01HsfvJ
 /l7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:message-id:date:from:reply-to:user-agent
 :mime-version:to:cc:subject:references:in-reply-to
 :content-transfer-encoding;
 bh=BY6Tnprq1NTjl/9cnO/xWTBR41aqYIrlujf6vVrVdzw=;
 b=TZYeSG4YLm11DQ7qvIiBGPrBy7RJzMro+opxct6REAI3Zf1iqbaZxI1Zm2JyczXwIA
 tSkpvJ41/9bo1aS10vUSAUYGPz+LXp/22S5atGFzIKKw659F8UrqkL67geUuVAIlHsQI
 L4JL76V7doAS+RDYCDN8H4UAZgXxX90FEJuPkpqomap6cdi7WeroyxfCB6UHfZHxjWHg
 i7DLrbcRnLn4CmjuwwL/jG8ztoSg6rkfJBn/XdB/Py101Q34Ds4o1uervSTQbGgc4cc3
 86dlKWcHvvG1sQGxE4vEyUNHcpw/HXMAY5NmhymXrUacIyb1UA9z+KSYfiD3hkeYk7ag
 0qSg==
X-Gm-Message-State: AOAM531tUsvROS7i/PTwyPL9NR6AmlNnWNY+f+cgZUrGcHBoTSePZfed
 c/TRz6+XmeOKOWx1KeL8esQ=
X-Google-Smtp-Source: ABdhPJyDNwKpBbFfnG+3k2TmB6of6lSfdAL8w89q9VYxhZw8D7YnmOfGviz7p7IpThM419OwdFS4uA==
X-Received: by 2002:aca:d886:: with SMTP id p128mr7977130oig.16.1604891420302; 
 Sun, 08 Nov 2020 19:10:20 -0800 (PST)
Received: from [192.168.2.42] (adsl-70-133-144-11.dsl.ablntx.sbcglobal.net.
 [70.133.144.11])
 by smtp.gmail.com with ESMTPSA id q10sm2102055oih.56.2020.11.08.19.10.18
 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
 Sun, 08 Nov 2020 19:10:19 -0800 (PST)
Message-ID: <5FA8B319.6020708@HIDDEN>
Date: Sun, 08 Nov 2020 21:10:17 -0600
From: Jacob Bachmeyer <jcb62281@HIDDEN>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17
 Mnenhy/0.7.6.0
MIME-Version: 1.0
References: <alpine.OSX.2.23.453.2011041849110.8469@HIDDEN>
 <5FA4C16B.1040300@HIDDEN>
 <alpine.OSX.2.23.453.2011081528320.89665@HIDDEN>
In-Reply-To: <alpine.OSX.2.23.453.2011081528320.89665@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.5 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

Fred Wright wrote:
> On Thu, 5 Nov 2020, Jacob Bachmeyer wrote:
>> Fred Wright wrote:
>>
>>> Even when it's using gcc, it bloats the logfile with the verbose 
>>> -dumpspecs output, in order to determine something of highly 
>>> questionable value.
>>
>> That value may be less questionable for some targets, or for tests 
>> that need to be run across each multilib target a GCC instance supports.
>
> Even in the useful multilib cases, making that behavior unconditional 
> seems like a bad idea, since the client code may have its own 
> iteration across architectures, and doing both would either not work 
> or explode the multi-architecture handling from O(N) to O(N^2).

The get_multilibs procedure does not perform iterations itself.  I am 
not yet certain what exactly it is supposed to do, since it seems to do 
a large amount of work to set the "multitop" board_info key.  Whatever 
it does, it is clearly specific to GCC, but does not even check if the 
selected compiler even looks like GCC.

>>> I traced the results of get_multilibs (as used by the libffi tests) 
>>> in many macOS versions, and even the "successful" cases seem to have 
>>> questionably useful results:
>>>
>>> [...]
>>>
>>> The "/usr/." result returned on 10.4, 10.5, and 32-bit 10.6 is the 
>>> same as what I see on Ubuntu 14.04, CentOS 7, and Fedora 25, though 
>>> it's not clear to me what it's supposed to represent.
>>
>> I have a suspicion that this feature is designed to support testing 
>> with an "experimental" compiler build that is not installed on the 
>> system and may be useless with system compilers generally, or with 
>> Apple's compilers specifically, if Apple does not use multilib.
>
> Apple supports the concept of multi-architecture binaries, but not in 
> the same way that multilib does it (AFAIK).  Macs can have "universal" 
> binaries, which are archives combining multiple per-architecture 
> slices. This is applicable to object files, shared libraries, and 
> executables.  If
> the build setup allows it, it can be as simple as including multiple 
> architecture options in the compile command.  E.g.:
>
>     cc -arch x86_64 -arch i386 -o hello hello.c
>
> Under the hood, the compiler driver runs a separate compile/assemble 
> for each architecture, and then combines the object files.  The linker 
> supports universal binaries directly.
>
> With this arrangement, architecture-related conditionals in the source 
> code work just fine, but what *doesn't* work is having 
> architecture-related parameters in a configure script, which is 
> unfortunately not as uncommon as it ought to be.

No, Autoconf pushes programs to respond to features instead of using 
known architectures.  This approach has been very successful:  as I 
understand, most programs using Autoconf needed no changes at all to 
port to RISC-V even if they were written long before RISC-V existed.  
Many programs, if they had previously been ported to any 64-bit 
architecture, needed no changes at all for x86_64.  Autoconf has 
achieved something architecture #ifdefs cannot do:  provide automatic 
portability to a new architecture that did not exist when the program 
was written.  I consider Autoconf's approach here completely vindicated.

You could submit a patch to Autoconf to add support for multi-arch 
config.h files, where configure would run tests for each of a list of 
architectures and use arch #ifdefs in config.h to select the configure 
results for each compile.

>>> Since get_multilibs already has code to return an empty string in 
>>> the "remote" case (where it assumes this function won't work), I 
>>> just added code to unix.exp to set multitop to "" for all "darwin" 
>>> targets, thereby short-circuiting almost all og get_multilibs.  That 
>>> certainly fixes the problem with the libffi tests, and doesn't 
>>> change any non-Mac behavior, though I don't know if that's the ideal 
>>> fix.  The whole get_mutilibs function looks pretty ugly anyway, and 
>>> it's generally recognized that relying on -dumpspecs is a bad idea.
>>
>> It is most certainly not ideal.  A better solution is probably to add 
>> a test to get_multilibs to return an empty string if the compiler is 
>> not GCC.  Of course, if another compiler pretends to be GCC enough to 
>> pass that check, but does not actually implement -dumpspecs, that is 
>> not our bug.
>
> Limiting it to gcc would avoid actual failures, but wouldn't avoid 
> bloating the logfile with the humongous -dumpspecs output in the many 
> cases where the multilibs action isn't even wanted.
>
> The meaning of "pretends to be gcc" isn't well-defined.  It's not 
> uncommon to have a compiler named "gcc" which is really clang, largely 
> because there are so many projects that think that all compilers of 
> interest are named "gcc".  And of course, clang tries to be highly 
> gcc-compatible, to facilitate switching to it, but not to the extent 
> of implementing -dumpspecs, which is is derived purely from gcc's 
> internal implementation details, and was never intended to be used in 
> this fashion.

Autoconf has always allowed setting CC to select a compiler.  Apple 
*could* have shipped Clang as "llcc" or similar or even simply the 
traditional "cc" for a system compiler, but they chose to ship it as 
"gcc" instead.  Not that the current version of get_multilibs even 
bothers to check that the compiler has "gcc" in its name...

> The libffi test suite comes up with a "compiler_vendor" variable which 
> seems to be able to distinguish clang from gcc, though I haven't 
> looked at the details.
>
> Fixing get_multilibs properly would probably mean making it both 
> highly platform-specific and optional.

The get_multilibs procedure is *not* platform-specific; it is 
GCC-specific.  I am still unsure how exactly it is used.

>> This issue on Mac OS X will probably be a known bug in 1.6.3 and 
>> fixed in 1.6.4.
>>
>>> I primarily tested my patch against the 1.6.2 release, since the 
>>> current master won't install from a non-git directory, and also has 
>>> multiple failures in its own tests (even on Linux).  The patch is 
>>> nearly identical between the 1.6.2 and master cases, anyway.
>>
>> Are we looking at the same current master?  I have commit 
>> 3d62df24deedfb3c7c3e396a31b8ce431138eb49 here and all of the tests pass.
>>
>> ****These other problems are potential release blockers for 1.6.3.****
>> Can you file another bug report with the test failures and more 
>> information about these issues?
>
> I looked into this more closely and it's probably related to the 
> non-git issue.  When running from a non-git directory, the configure 
> script reports a "fatal" error, but then goes on to complete with a 
> zero exit status and a more or less buildable setup, so you have to be 
> paying close attention to the output to notice.
>
> If this is a typical hack to provide git-based extra information in 
> between-release version strings, it should have a fallback for the 
> non-git case.  Consider the case of pushing all the git-tracked files 
> to a test system with git ls-files and rsync.

Please file another bug report for this issue.  This is separate from 
get_multilibs mishandling non-GCC compilers.

>>> I can send the current patch, either as a bare email or as an 
>>> attachment. AFAIK, Savannah doesn't have the pull request / merge 
>>> request concept.
>>
>> This will need to be fixed in libgloss.exp, not unix.exp.  I am 
>> putting my foot down on fixing bugs in DejaGnu's own tree directly 
>> instead of hacking around them like that.
>
> Well, OK, but there seem to be other similar hacks in unix.exp, and if 
> the idea is that get_multilibs is completely useless on the Mac (which 
> appears to be the case with the current implemenation, anyway), then 
> disabling it in the target-related code doesn't seem unreasonable.

It is not completely useless even on MacOS X -- a user could install GCC 
and expect a testsuite to use it, particularly in the case of a 
cross-compiler for embedded development.


-- Jacob

Message sent to bug-dejagnu@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#44462: Problem with get_multilibs on macOS
Resent-From: Fred Wright <fw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-dejagnu@HIDDEN
Resent-Date: Tue, 10 Nov 2020 02:45:02 +0000
Resent-Message-ID: <handler.44462.B44462.16049762718159 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 44462
X-GNU-PR-Package: dejagnu
X-GNU-PR-Keywords: 
To: Jacob Bachmeyer <jcb62281@HIDDEN>
Cc: 44462 <at> debbugs.gnu.org
Received: via spool by 44462-submit <at> debbugs.gnu.org id=B44462.16049762718159
          (code B ref 44462); Tue, 10 Nov 2020 02:45:02 +0000
Received: (at 44462) by debbugs.gnu.org; 10 Nov 2020 02:44:31 +0000
Received: from localhost ([127.0.0.1]:36027 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kcJe3-00027X-8z
	for submit <at> debbugs.gnu.org; Mon, 09 Nov 2020 21:44:31 -0500
Received: from d.mail.sonic.net ([64.142.111.50]:57214)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <fw@HIDDEN>) id 1kcJe1-00027N-G7
 for 44462 <at> debbugs.gnu.org; Mon, 09 Nov 2020 21:44:30 -0500
Received: from MacPro.local (c-76-102-182-162.hsd1.ca.comcast.net
 [76.102.182.162]) (authenticated bits=0)
 by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id 0AA2iQv3029619
 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT);
 Mon, 9 Nov 2020 18:44:27 -0800
Date: Mon, 9 Nov 2020 18:44:26 -0800 (PST)
From: Fred Wright <fw@HIDDEN>
X-X-Sender: fw@HIDDEN
In-Reply-To: <5FA8B319.6020708@HIDDEN>
Message-ID: <alpine.OSX.2.23.453.2011091827250.2903@HIDDEN>
References: <alpine.OSX.2.23.453.2011041849110.8469@HIDDEN>
 <5FA4C16B.1040300@HIDDEN>
 <alpine.OSX.2.23.453.2011081528320.89665@HIDDEN>
 <5FA8B319.6020708@HIDDEN>
User-Agent: Alpine 2.23 (OSX 453 2020-06-18)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
X-Sonic-CAuth: UmFuZG9tSVZv1qV3M9ed+HWt08+pEq8BRY7bW3iVzIrDqmRqlUFQyS+5scad9MirIFcPOV9VIIF49bkV9oyDrc2AldeTVpl1
X-Sonic-ID: C;ULUspv4i6xGF3LSffAb4WQ== M;UC1Gpv4i6xGF3LSffAb4WQ==
X-Spam-Flag: No
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)


On Sun, 8 Nov 2020, Jacob Bachmeyer wrote:
> Fred Wright wrote:
>> On Thu, 5 Nov 2020, Jacob Bachmeyer wrote:
>>> Fred Wright wrote:
>>> 
>>>> Even when it's using gcc, it bloats the logfile with the verbose 
>>>> -dumpspecs output, in order to determine something of highly questionable 
>>>> value.
>>> 
>>> That value may be less questionable for some targets, or for tests that 
>>> need to be run across each multilib target a GCC instance supports.
>> 
>> Even in the useful multilib cases, making that behavior unconditional seems 
>> like a bad idea, since the client code may have its own iteration across 
>> architectures, and doing both would either not work or explode the 
>> multi-architecture handling from O(N) to O(N^2).
>
> The get_multilibs procedure does not perform iterations itself.  I am not yet 
> certain what exactly it is supposed to do, since it seems to do a large 
> amount of work to set the "multitop" board_info key.  Whatever it does, it is 
> clearly specific to GCC, but does not even check if the selected compiler 
> even looks like GCC.
>
>>>> I traced the results of get_multilibs (as used by the libffi tests) in 
>>>> many macOS versions, and even the "successful" cases seem to have 
>>>> questionably useful results:
>>>> 
>>>> [...]
>>>> 
>>>> The "/usr/." result returned on 10.4, 10.5, and 32-bit 10.6 is the same 
>>>> as what I see on Ubuntu 14.04, CentOS 7, and Fedora 25, though it's not 
>>>> clear to me what it's supposed to represent.
>>> 
>>> I have a suspicion that this feature is designed to support testing with 
>>> an "experimental" compiler build that is not installed on the system and 
>>> may be useless with system compilers generally, or with Apple's compilers 
>>> specifically, if Apple does not use multilib.
>> 
>> Apple supports the concept of multi-architecture binaries, but not in the 
>> same way that multilib does it (AFAIK).  Macs can have "universal" 
>> binaries, which are archives combining multiple per-architecture slices. 
>> This is applicable to object files, shared libraries, and executables.  If
>> the build setup allows it, it can be as simple as including multiple 
>> architecture options in the compile command.  E.g.:
>>
>>     cc -arch x86_64 -arch i386 -o hello hello.c
>> 
>> Under the hood, the compiler driver runs a separate compile/assemble for 
>> each architecture, and then combines the object files.  The linker supports 
>> universal binaries directly.
>> 
>> With this arrangement, architecture-related conditionals in the source code 
>> work just fine, but what *doesn't* work is having architecture-related 
>> parameters in a configure script, which is unfortunately not as uncommon as 
>> it ought to be.
>
> No, Autoconf pushes programs to respond to features instead of using known 
> architectures.  This approach has been very successful:  as I understand, 
> most programs using Autoconf needed no changes at all to port to RISC-V even 
> if they were written long before RISC-V existed.  Many programs, if they had 
> previously been ported to any 64-bit architecture, needed no changes at all 
> for x86_64.  Autoconf has achieved something architecture #ifdefs cannot do: 
> provide automatic portability to a new architecture that did not exist when 
> the program was written.  I consider Autoconf's approach here completely 
> vindicated.

I'm not talking about checking for specific architectures; this is about 
checking architecture-related *properties*.  For example, a configure 
check for sizeof(long) is incompatible with multi-architecture builds, 
while using LONG_BIT works just fine.  But there are build procedures that 
do things like the former, for no good reason.

> You could submit a patch to Autoconf to add support for multi-arch config.h 
> files, where configure would run tests for each of a list of architectures 
> and use arch #ifdefs in config.h to select the configure results for each 
> compile.

I don't plan to mess with Autoconf if I can possibly avoid it. :-)

>>>> Since get_multilibs already has code to return an empty string in the 
>>>> "remote" case (where it assumes this function won't work), I just added 
>>>> code to unix.exp to set multitop to "" for all "darwin" targets, thereby 
>>>> short-circuiting almost all og get_multilibs.  That certainly fixes the 
>>>> problem with the libffi tests, and doesn't change any non-Mac behavior, 
>>>> though I don't know if that's the ideal fix.  The whole get_mutilibs 
>>>> function looks pretty ugly anyway, and it's generally recognized that 
>>>> relying on -dumpspecs is a bad idea.
>>> 
>>> It is most certainly not ideal.  A better solution is probably to add a 
>>> test to get_multilibs to return an empty string if the compiler is not 
>>> GCC.  Of course, if another compiler pretends to be GCC enough to pass 
>>> that check, but does not actually implement -dumpspecs, that is not our 
>>> bug.
>> 
>> Limiting it to gcc would avoid actual failures, but wouldn't avoid bloating 
>> the logfile with the humongous -dumpspecs output in the many cases where 
>> the multilibs action isn't even wanted.
>> 
>> The meaning of "pretends to be gcc" isn't well-defined.  It's not uncommon 
>> to have a compiler named "gcc" which is really clang, largely because there 
>> are so many projects that think that all compilers of interest are named 
>> "gcc".  And of course, clang tries to be highly gcc-compatible, to 
>> facilitate switching to it, but not to the extent of implementing 
>> -dumpspecs, which is is derived purely from gcc's internal implementation 
>> details, and was never intended to be used in this fashion.
>
> Autoconf has always allowed setting CC to select a compiler.  Apple *could* 
> have shipped Clang as "llcc" or similar or even simply the traditional "cc" 
> for a system compiler, but they chose to ship it as "gcc" instead.  Not that 
> the current version of get_multilibs even bothers to check that the compiler 
> has "gcc" in its name...
>
>> The libffi test suite comes up with a "compiler_vendor" variable which 
>> seems to be able to distinguish clang from gcc, though I haven't looked at 
>> the details.
>> 
>> Fixing get_multilibs properly would probably mean making it both highly 
>> platform-specific and optional.
>
> The get_multilibs procedure is *not* platform-specific; it is GCC-specific. 
> I am still unsure how exactly it is used.

Since it seems to involve file paths, it may be specific to combinations 
of GCC and platforms.

But since neither of us seems to know very much about what get_multilibs 
is trying to do, it's hard to discuss it intelligently. :-)

>>> This issue on Mac OS X will probably be a known bug in 1.6.3 and fixed in 
>>> 1.6.4.
>>> 
>>>> I primarily tested my patch against the 1.6.2 release, since the current 
>>>> master won't install from a non-git directory, and also has multiple 
>>>> failures in its own tests (even on Linux).  The patch is nearly identical 
>>>> between the 1.6.2 and master cases, anyway.
>>> 
>>> Are we looking at the same current master?  I have commit 
>>> 3d62df24deedfb3c7c3e396a31b8ce431138eb49 here and all of the tests pass.
>>> 
>>> ****These other problems are potential release blockers for 1.6.3.****
>>> Can you file another bug report with the test failures and more 
>>> information about these issues?
>> 
>> I looked into this more closely and it's probably related to the non-git 
>> issue.  When running from a non-git directory, the configure script reports 
>> a "fatal" error, but then goes on to complete with a zero exit status and a 
>> more or less buildable setup, so you have to be paying close attention to 
>> the output to notice.

Actually it now looks like the two things are unrelated; I filed two 
separate bugs.

>> If this is a typical hack to provide git-based extra information in 
>> between-release version strings, it should have a fallback for the non-git 
>> case.  Consider the case of pushing all the git-tracked files to a test 
>> system with git ls-files and rsync.
>
> Please file another bug report for this issue.  This is separate from 
> get_multilibs mishandling non-GCC compilers.
>
>>>> I can send the current patch, either as a bare email or as an attachment. 
>>>> AFAIK, Savannah doesn't have the pull request / merge request concept.
>>> 
>>> This will need to be fixed in libgloss.exp, not unix.exp.  I am putting my 
>>> foot down on fixing bugs in DejaGnu's own tree directly instead of hacking 
>>> around them like that.
>> 
>> Well, OK, but there seem to be other similar hacks in unix.exp, and if the 
>> idea is that get_multilibs is completely useless on the Mac (which appears 
>> to be the case with the current implemenation, anyway), then disabling it 
>> in the target-related code doesn't seem unreasonable.
>
> It is not completely useless even on MacOS X -- a user could install GCC and 
> expect a testsuite to use it, particularly in the case of a cross-compiler 
> for embedded development.

If it's a cross compiler, then by definition it can't run the resulting 
code on the host platform.  But since get_multilibs already excludes all 
remote cases, it wouldn't be able to run it on a separate target platform, 
either.

Besides, aren't files like baseboards/unix.exp based on the *target* 
platform, not the host?  If so, then it seems like disabling get_multilibs 
for the Mac there is exactly the right thing, at least until such time as 
get_multilibs can behave usefully for a Mac target.

Fred Wright

Message sent to bug-dejagnu@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#44462: Problem with get_multilibs on macOS
Resent-From: Jacob Bachmeyer <jcb62281@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-dejagnu@HIDDEN
Resent-Date: Tue, 10 Nov 2020 05:14:02 +0000
Resent-Message-ID: <handler.44462.B44462.160498521224461 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 44462
X-GNU-PR-Package: dejagnu
X-GNU-PR-Keywords: 
To: Fred Wright <fw@HIDDEN>
Cc: 44462 <at> debbugs.gnu.org
Reply-To: jcb62281@HIDDEN
Received: via spool by 44462-submit <at> debbugs.gnu.org id=B44462.160498521224461
          (code B ref 44462); Tue, 10 Nov 2020 05:14:02 +0000
Received: (at 44462) by debbugs.gnu.org; 10 Nov 2020 05:13:32 +0000
Received: from localhost ([127.0.0.1]:36110 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kcLyG-0006MS-AZ
	for submit <at> debbugs.gnu.org; Tue, 10 Nov 2020 00:13:32 -0500
Received: from mail-oi1-f170.google.com ([209.85.167.170]:36814)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <jcb62281@HIDDEN>) id 1kcLyD-0006MD-P0
 for 44462 <at> debbugs.gnu.org; Tue, 10 Nov 2020 00:13:30 -0500
Received: by mail-oi1-f170.google.com with SMTP id d9so12977829oib.3
 for <44462 <at> debbugs.gnu.org>; Mon, 09 Nov 2020 21:13:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject
 :references:in-reply-to:content-transfer-encoding;
 bh=JJI+tlrAH450Y7gwbpBHntPNEksoDzGdJu0v8Q+BCmk=;
 b=qmQ6k/t9UF/DdCxR5Efxctqu287si1WufxeRU4usxyDnJuHQHD1UXu7UqnMlBj8ijg
 SPL5ufWg6X7EUU8OYLS4CGkevTCiVF7wQv5/x5ql/Kx/BtIiACcfQE6Ifj0wzMqQ3Cir
 k6CJ0LBzz+92+5JXHKSrRF8PHseJWWDxjYrnfKDWh/geQERbnayJKsla6QYEP+JegWi3
 DW1v96hlBRmbFudc3SJ/NgCp9lFKIoQU36VEY22C+U1OfdmWfCGpfDmaIu3+8lzV2SMa
 NSv8QKsbNfPCizWCOJmHAGq+U6UYc9nLjfqh5JPfyT+d0izifemksQlDEWV+uH+ZGB77
 4Syg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:message-id:date:from:reply-to:user-agent
 :mime-version:to:cc:subject:references:in-reply-to
 :content-transfer-encoding;
 bh=JJI+tlrAH450Y7gwbpBHntPNEksoDzGdJu0v8Q+BCmk=;
 b=elLCD/GUZ0BTYEDm/zZhidWnyj0uGd2E08r3oRn4eyS2H+TblT/wq86I/lCWuPhd+d
 0xd4W5ROp72eJGh4L8T4zJxLr7fnnQkOD8tO2KR47IcZ5dUXiKBkuRXhLm+keCxopL/g
 1/4YQYR/jNv7fRQ/SyGs9ZAAvVHKpmf7NPlOPxeeI5b5qlq5hVPsEDmryy1zHnq12IQY
 Cr8LXN0qDhUv3Nq5nllHkrPl1xyGiEM3amKD6E8VgwxFwjrAbuh+1JgzCM5m95MUjmFd
 RwwyeOhJzo41VAWLagVqhNn1enbRCW5N+qI6q8ueFT24tIrY3lmsIrPpav2VIdW+UaiZ
 mbHQ==
X-Gm-Message-State: AOAM532WeeNZpkJcckk2sUis03baRZysP0NvvFFcVnMqAw8F4gN6TXUy
 H/5iATckp/+VBzBItL49iIlK19ysYuM=
X-Google-Smtp-Source: ABdhPJxwgXIFF3O1rafoISWg0W1kq84G+MlDP29x0tlOGi9oUg7u3I0cZrgJJjCIG/odjyweB5pzGA==
X-Received: by 2002:aca:b7d6:: with SMTP id h205mr1698440oif.80.1604985204171; 
 Mon, 09 Nov 2020 21:13:24 -0800 (PST)
Received: from [192.168.2.42] (adsl-70-133-144-11.dsl.ablntx.sbcglobal.net.
 [70.133.144.11])
 by smtp.gmail.com with ESMTPSA id d26sm2916927ooh.19.2020.11.09.21.13.22
 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
 Mon, 09 Nov 2020 21:13:23 -0800 (PST)
Message-ID: <5FAA2171.1000501@HIDDEN>
Date: Mon, 09 Nov 2020 23:13:21 -0600
From: Jacob Bachmeyer <jcb62281@HIDDEN>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17
 Mnenhy/0.7.6.0
MIME-Version: 1.0
References: <alpine.OSX.2.23.453.2011041849110.8469@HIDDEN>
 <5FA4C16B.1040300@HIDDEN>
 <alpine.OSX.2.23.453.2011081528320.89665@HIDDEN>
In-Reply-To: <alpine.OSX.2.23.453.2011081528320.89665@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.5 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

Fred Wright wrote:
> On Thu, 5 Nov 2020, Jacob Bachmeyer wrote:
>> Fred Wright wrote:
>>> I primarily tested my patch against the 1.6.2 release, since the 
>>> current master won't install from a non-git directory, and also has 
>>> multiple failures in its own tests (even on Linux).  The patch is 
>>> nearly identical between the 1.6.2 and master cases, anyway.
>>
>> Are we looking at the same current master?  I have commit 
>> 3d62df24deedfb3c7c3e396a31b8ce431138eb49 here and all of the tests pass.
>>
>> ****These other problems are potential release blockers for 1.6.3.****
>> Can you file another bug report with the test failures and more 
>> information about these issues?
>
> I looked into this more closely and it's probably related to the 
> non-git issue.  When running from a non-git directory, the configure 
> script reports a "fatal" error, but then goes on to complete with a 
> zero exit status and a more or less buildable setup, so you have to be 
> paying close attention to the output to notice.

I was able to replicate this with `git -z ls-files | cpio -0dp 
/tmp/dg-test-src` and configuring elsewhere from that directory.  The 
"fatal" error is a message Git produces when run in a directory that 
does not have an associated repository.

> If this is a typical hack to provide git-based extra information in 
> between-release version strings, it should have a fallback for the 
> non-git case.  Consider the case of pushing all the git-tracked files 
> to a test system with git ls-files and rsync.

You are correct that this was intended to add a Git branch tag upon 
installation and that it failed badly if the sources were not in a Git 
working directory.  The faulty commit has been reverted and a better 
solution is planned for release 1.6.4.  We are already at the release 
code freeze for 1.6.3, so the improved solution (as a new feature 
affecting Tcl code) will need to go into 1.6.4.

The Makefile.in and configure files have been regenerated and the new 
versions are in Git master on Savannah.  Please confirm that this 
corrects the problem you have observed with installing sources that have 
been copied out of a Git working tree.

I am also very interested in any test failures that are occurring with 
"make check" in DejaGnu at current master.


Thanks in advance,

-- Jacob

Message sent to bug-dejagnu@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#44462: Problem with get_multilibs on macOS
Resent-From: Jacob Bachmeyer <jcb62281@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-dejagnu@HIDDEN
Resent-Date: Wed, 11 Nov 2020 00:50:01 +0000
Resent-Message-ID: <handler.44462.B44462.160505574420730 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 44462
X-GNU-PR-Package: dejagnu
X-GNU-PR-Keywords: 
To: Fred Wright <fw@HIDDEN>
Cc: 44462 <at> debbugs.gnu.org
Reply-To: jcb62281@HIDDEN
Received: via spool by 44462-submit <at> debbugs.gnu.org id=B44462.160505574420730
          (code B ref 44462); Wed, 11 Nov 2020 00:50:01 +0000
Received: (at 44462) by debbugs.gnu.org; 11 Nov 2020 00:49:04 +0000
Received: from localhost ([127.0.0.1]:39539 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kceJr-0005OH-HD
	for submit <at> debbugs.gnu.org; Tue, 10 Nov 2020 19:49:04 -0500
Received: from mail-ot1-f46.google.com ([209.85.210.46]:37839)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <jcb62281@HIDDEN>) id 1kceJp-0005Nk-IU
 for 44462 <at> debbugs.gnu.org; Tue, 10 Nov 2020 19:49:02 -0500
Received: by mail-ot1-f46.google.com with SMTP id l36so595259ota.4
 for <44462 <at> debbugs.gnu.org>; Tue, 10 Nov 2020 16:49:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject
 :references:in-reply-to:content-transfer-encoding;
 bh=EciS2bIOzTHeLBniKDiYyBZJlytt8H/a2QAaf1RFj+M=;
 b=g2oSLQue7RuLFgkzDaF5mglV1pgvcoNOIwig7JGw18kDoWQvJucrj2jQNgxFMS0VGP
 vgLQfGfzdbt9pggikVahK7PfQdRAyTFCg1b0dU568k2faC2A46qnd73ygOXwKI+Gs6qR
 rHtMfcjBCL/5jTTAQkZ94WeIoIKe40gKG17MI50/zpu3p2LYmxiAbbOD32cz/GfgVB7X
 GVfk+r6h+lY11pKJN1wnylYv5HpGZkkRaRGbAu7L1nGtRSkP46Fx45unoh8NhX6kOR2W
 fE5HDrPmoxCA5x/jvc7Wj8TmBOyRfXIVzKAa5/YdOl4+JEnZ/9n8qd3c055GdX/9AVvw
 lX3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:message-id:date:from:reply-to:user-agent
 :mime-version:to:cc:subject:references:in-reply-to
 :content-transfer-encoding;
 bh=EciS2bIOzTHeLBniKDiYyBZJlytt8H/a2QAaf1RFj+M=;
 b=E1xZU/8kJ6PQa1Y+h1Pt67w2yqZe0GN+4Wglvnby5k5F8TWi4VrN3I34rKZywv4noA
 uwGjV6OoyYgmnlFUiRotvUYhZusQxoZ2OTd7v4FD4+mWWsU1Xp4Xd5jqFcLG7ifbawBo
 WqrhAMl0ZuF/6iup0eXqS3hYpFLlAXizJFw7EMl1vVvoziLOKsWzE2/gRd9hq771ikTA
 LJ1dQpkVNHTf/loR+kfH32S1ZtI84/mFwUAvjJvi4rcPp2QO5UPYh3Vy5luATF2jNsKs
 2hSHkqro0DR6+oub6jB2O5nekJ75nvUMn4GYbTf9/rexQqFWidJYpxjJLCJkZB8uhPFw
 AM4w==
X-Gm-Message-State: AOAM533ohLeVJMTtIKhL0EwrTyqMJA0qZq6o4S2HdJ0XNm29mLsW/GeT
 h2Z4+o9ACLw63EVSOnMha6A=
X-Google-Smtp-Source: ABdhPJx/TNB9RNHnnAraj7t05+Aam/tNlusN/cJ7AvQr4vMUZczfsOKhB/hWEstgkPQdQpnkbBYQyw==
X-Received: by 2002:a05:6830:108f:: with SMTP id
 y15mr11972614oto.225.1605055735887; 
 Tue, 10 Nov 2020 16:48:55 -0800 (PST)
Received: from [192.168.2.42] (adsl-70-133-144-11.dsl.ablntx.sbcglobal.net.
 [70.133.144.11])
 by smtp.gmail.com with ESMTPSA id f34sm150742otb.34.2020.11.10.16.48.54
 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
 Tue, 10 Nov 2020 16:48:55 -0800 (PST)
Message-ID: <5FAB34F6.4040306@HIDDEN>
Date: Tue, 10 Nov 2020 18:48:54 -0600
From: Jacob Bachmeyer <jcb62281@HIDDEN>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17
 Mnenhy/0.7.6.0
MIME-Version: 1.0
References: <alpine.OSX.2.23.453.2011041849110.8469@HIDDEN>
 <5FA4C16B.1040300@HIDDEN>
 <alpine.OSX.2.23.453.2011081528320.89665@HIDDEN>
 <5FA8B319.6020708@HIDDEN>
 <alpine.OSX.2.23.453.2011091827250.2903@HIDDEN>
In-Reply-To: <alpine.OSX.2.23.453.2011091827250.2903@HIDDEN>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.5 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

Fred Wright wrote:
> On Sun, 8 Nov 2020, Jacob Bachmeyer wrote:
>> Fred Wright wrote:
>>> On Thu, 5 Nov 2020, Jacob Bachmeyer wrote:
>>>> Fred Wright wrote:
>>>>
>>>>> I traced the results of get_multilibs (as used by the libffi 
>>>>> tests) in many macOS versions, and even the "successful" cases 
>>>>> seem to have questionably useful results:
>>>>>
>>>>> [...]
>>>>>
>>>>> The "/usr/." result returned on 10.4, 10.5, and 32-bit 10.6 is the 
>>>>> same as what I see on Ubuntu 14.04, CentOS 7, and Fedora 25, 
>>>>> though it's not clear to me what it's supposed to represent.
>>>>
>>>> I have a suspicion that this feature is designed to support testing 
>>>> with an "experimental" compiler build that is not installed on the 
>>>> system and may be useless with system compilers generally, or with 
>>>> Apple's compilers specifically, if Apple does not use multilib.
>>>
>>> Apple supports the concept of multi-architecture binaries, but not 
>>> in the same way that multilib does it (AFAIK).  Macs can have 
>>> "universal" binaries, which are archives combining multiple 
>>> per-architecture slices. This is applicable to object files, shared 
>>> libraries, and executables.  If
>>> the build setup allows it, it can be as simple as including multiple 
>>> architecture options in the compile command.  E.g.:
>>>
>>>     cc -arch x86_64 -arch i386 -o hello hello.c
>>>
>>> Under the hood, the compiler driver runs a separate compile/assemble 
>>> for each architecture, and then combines the object files.  The 
>>> linker supports universal binaries directly.
>>>
>>> With this arrangement, architecture-related conditionals in the 
>>> source code work just fine, but what *doesn't* work is having 
>>> architecture-related parameters in a configure script, which is 
>>> unfortunately not as uncommon as it ought to be.
>>
>> No, Autoconf pushes programs to respond to features instead of using 
>> known architectures.  This approach has been very successful:  as I 
>> understand, most programs using Autoconf needed no changes at all to 
>> port to RISC-V even if they were written long before RISC-V existed.  
>> Many programs, if they had previously been ported to any 64-bit 
>> architecture, needed no changes at all for x86_64.  Autoconf has 
>> achieved something architecture #ifdefs cannot do: provide automatic 
>> portability to a new architecture that did not exist when the program 
>> was written.  I consider Autoconf's approach here completely vindicated.
>
> I'm not talking about checking for specific architectures; this is 
> about checking architecture-related *properties*.  For example, a 
> configure check for sizeof(long) is incompatible with 
> multi-architecture builds, while using LONG_BIT works just fine.  But 
> there are build procedures that do things like the former, for no good 
> reason.

As far as I can tell, LONG_BIT as a preprocessor symbol is relatively 
new; newer than many programs that have demonstrated this level of 
Autoconf-assisted portability.  On older systems, glibc provides 
CHAR_BIT and you can find the bit-length with CHAR_BIT*sizeof(long).

>>>>> Since get_multilibs already has code to return an empty string in 
>>>>> the "remote" case (where it assumes this function won't work), I 
>>>>> just added code to unix.exp to set multitop to "" for all "darwin" 
>>>>> targets, thereby short-circuiting almost all og get_multilibs.  
>>>>> That certainly fixes the problem with the libffi tests, and 
>>>>> doesn't change any non-Mac behavior, though I don't know if that's 
>>>>> the ideal fix.  The whole get_mutilibs function looks pretty ugly 
>>>>> anyway, and it's generally recognized that relying on -dumpspecs 
>>>>> is a bad idea.
>>>>
>>>> It is most certainly not ideal.  A better solution is probably to 
>>>> add a test to get_multilibs to return an empty string if the 
>>>> compiler is not GCC.  Of course, if another compiler pretends to be 
>>>> GCC enough to pass that check, but does not actually implement 
>>>> -dumpspecs, that is not our bug.
>>>
>>> [...]
>>> The libffi test suite comes up with a "compiler_vendor" variable 
>>> which seems to be able to distinguish clang from gcc, though I 
>>> haven't looked at the details.
>>>
>>> Fixing get_multilibs properly would probably mean making it both 
>>> highly platform-specific and optional.
>>
>> The get_multilibs procedure is *not* platform-specific; it is 
>> GCC-specific. I am still unsure how exactly it is used.
>
> Since it seems to involve file paths, it may be specific to 
> combinations of GCC and platforms.
>
> But since neither of us seems to know very much about what 
> get_multilibs is trying to do, it's hard to discuss it intelligently. :-)

This is the main reason that get_multilibs failing on MacOS X will be a 
known bug in 1.6.3.

>>>> This issue on Mac OS X will probably be a known bug in 1.6.3 and 
>>>> fixed in 1.6.4.
>>>>
>>>>> I primarily tested my patch against the 1.6.2 release, since the 
>>>>> current master won't install from a non-git directory, and also 
>>>>> has multiple failures in its own tests (even on Linux).  The patch 
>>>>> is nearly identical between the 1.6.2 and master cases, anyway.
>>>>
>>>> Are we looking at the same current master?  I have commit 
>>>> 3d62df24deedfb3c7c3e396a31b8ce431138eb49 here and all of the tests 
>>>> pass.
>>>>
>>>> ****These other problems are potential release blockers for 1.6.3.****
>>>> Can you file another bug report with the test failures and more 
>>>> information about these issues?
>>>
>>> I looked into this more closely and it's probably related to the 
>>> non-git issue.  When running from a non-git directory, the configure 
>>> script reports a "fatal" error, but then goes on to complete with a 
>>> zero exit status and a more or less buildable setup, so you have to 
>>> be paying close attention to the output to notice.
>
> Actually it now looks like the two things are unrelated; I filed two 
> separate bugs.

Thank you; PR44544 should now be fixed on master; I have responded 
accordingly at that report also.  I am still looking into PR44545.

>>>>> I can send the current patch, either as a bare email or as an 
>>>>> attachment. AFAIK, Savannah doesn't have the pull request / merge 
>>>>> request concept.
>>>>
>>>> This will need to be fixed in libgloss.exp, not unix.exp.  I am 
>>>> putting my foot down on fixing bugs in DejaGnu's own tree directly 
>>>> instead of hacking around them like that.
>>>
>>> Well, OK, but there seem to be other similar hacks in unix.exp, and 
>>> if the idea is that get_multilibs is completely useless on the Mac 
>>> (which appears to be the case with the current implemenation, 
>>> anyway), then disabling it in the target-related code doesn't seem 
>>> unreasonable.
>>
>> It is not completely useless even on MacOS X -- a user could install 
>> GCC and expect a testsuite to use it, particularly in the case of a 
>> cross-compiler for embedded development.
>
> If it's a cross compiler, then by definition it can't run the 
> resulting code on the host platform.  But since get_multilibs already 
> excludes all remote cases, it wouldn't be able to run it on a separate 
> target platform, either.
>
> Besides, aren't files like baseboards/unix.exp based on the *target* 
> platform, not the host?  If so, then it seems like disabling 
> get_multilibs for the Mac there is exactly the right thing, at least 
> until such time as get_multilibs can behave usefully for a Mac target.

Untangling cross-development configurations is an ongoing project.

GCC could (in theory) be installed on any platform.  A user may build a 
native GCC for MacOS X and want to test or use it.  In short, the 
solution needs to test the actual issue -- is $compiler GCC? -- instead 
of assuming that it is or is not based on the platform.


-- Jacob

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 13 Nov 2020 00:15:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 12 19:15:47 2020
Received: from localhost ([127.0.0.1]:46100 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kdMkk-0004EH-NJ
	for submit <at> debbugs.gnu.org; Thu, 12 Nov 2020 19:15:46 -0500
Received: from mail-oi1-f175.google.com ([209.85.167.175]:36978)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <jcb62281@HIDDEN>) id 1kdMkh-0004E1-Gi
 for control <at> debbugs.gnu.org; Thu, 12 Nov 2020 19:15:45 -0500
Received: by mail-oi1-f175.google.com with SMTP id m17so8533802oie.4
 for <control <at> debbugs.gnu.org>; Thu, 12 Nov 2020 16:15:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=message-id:date:from:reply-to:user-agent:mime-version:to:subject
 :content-transfer-encoding;
 bh=fyDYiyuR8/g4JeZX7FULe+r6EXoMCVh5hijMQ7UL+MQ=;
 b=JJIt8sVc6Ka1s1be0XJ4u6U0ysovupcKOyA9EAu1td8rHEy+4HbzgTXbzL4P3b9F6P
 Y7DuOm0zFVy/qSTDTBKBqbl+46+tQlwCJWPRJuShYRsjOZ1GdaBnyNcOAOc1KT+32KTX
 kNQFo72gJX0Ps5TEvme1cXUKPLYULVJXVf1/1k3qJhg4aekHsZ0besu4u9mJwzRa3Iem
 qg7DSjg4lvfvPdR2A1OCwy2gEH3FdgTkG8d/sS7fFMi4P9viIQfOlKt0Qf00Q47ZVkFh
 l0PfaajPWtW/DOLbyK8qhU9+YHhxYYnFLmOMkUvKerDYyqcuntE3Qsto9Hz/oAB52ISX
 0cYA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:message-id:date:from:reply-to:user-agent
 :mime-version:to:subject:content-transfer-encoding;
 bh=fyDYiyuR8/g4JeZX7FULe+r6EXoMCVh5hijMQ7UL+MQ=;
 b=nSoJAd5eB3DCeFTVLI1osh0Aj2CE2Gc+l6l8t7MdJmtpTTD/MXeCBiAQ/+b0UlgcLg
 2+HSvsxhRdCMHbBPg39X7M8yE7QNMiBoid3vLOIR9Qv2x1b3VYwE2Th/JRNa95D2QZkB
 Ix1+L24VQ/D2PSSLjD5Ua7ZD0yhLTdLzMvlGM1YIptExfdvIvpmq3KANnzHLBgCGpLcU
 5KPNsWlgb09wYqz27SxOTViRPxIPpToNq66e/C1I/f0nvAsqruQ1Ze3zOjrGnMCp8ybz
 BtM5AJqLeL/X7j/8zPTl50PmDV4HJGPDdRrv7oZADDIwIXCugieIhRK5XVmVoxLgtog5
 lLRw==
X-Gm-Message-State: AOAM530ox+oPXT2ZENml5K0n9l80BtulidGqvHO8gkYUrZKMmVGpPhC+
 6spGB0jM6vJ9X4krd0XIQ9usKGUj6KY=
X-Google-Smtp-Source: ABdhPJzJmdV19MLTMeDXXN/GpWssJGMp2S7WHCoQ83GdwoaOnQZYIb1g8rzspjUojJEp1625W5ayag==
X-Received: by 2002:a05:6808:243:: with SMTP id
 m3mr266149oie.136.1605226537760; 
 Thu, 12 Nov 2020 16:15:37 -0800 (PST)
Received: from [192.168.2.42] (adsl-70-133-144-11.dsl.ablntx.sbcglobal.net.
 [70.133.144.11])
 by smtp.gmail.com with ESMTPSA id g3sm1512326oif.26.2020.11.12.16.15.36
 for <control <at> debbugs.gnu.org>
 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
 Thu, 12 Nov 2020 16:15:37 -0800 (PST)
Message-ID: <5FADD027.8040004@HIDDEN>
Date: Thu, 12 Nov 2020 18:15:35 -0600
From: Jacob Bachmeyer <jcb62281@HIDDEN>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.8.1.22) Gecko/20090807 MultiZilla/1.8.3.4e SeaMonkey/1.1.17
 Mnenhy/0.7.6.0
MIME-Version: 1.0
To: GNU bug tracker automated control server <control <at> debbugs.gnu.org>
Subject: bug administrivia 2020-11-12
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.5 (/)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: jcb62281@HIDDEN
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

package dejagnu

# these will be known bugs in 1.6.3
owner 44462 !
owner 44602 !

# these are potential release blockers
owner 44544 !
owner 44545 !

send-detail 44580

thanks

Last modified: Fri, 13 Nov 2020 00:30:02 UTC

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