GNU bug report logs - #44462
Problem with get_multilibs on macOS

Previous Next

Full log

View this message in rfc822 format

From: Jacob Bachmeyer <jcb62281 <at> gmail.com>
To: Fred Wright <fw <at> fwright.net>
Cc: 44462 <at> debbugs.gnu.org
Subject: bug#44462: Problem with get_multilibs on macOS
Date: Mon, 09 Nov 2020 23:13:21 -0600

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

Previous Next

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