[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#44462: Problem with get_multilibs on macOS

From: Jacob Bachmeyer
Subject: bug#44462: Problem with get_multilibs on macOS
Date: Mon, 09 Nov 2020 23:13:21 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090807 MultiZilla/ SeaMonkey/1.1.17 Mnenhy/

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]