|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000565||mercury||Bug||public||2023-09-04 00:27||2023-09-04 14:07|
|Priority||normal||Severity||major||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0000565: Installed mmake cannot build programs|
|Description||Attempting to build hello word, using the mmake from an installed compiler results in:|
gmake: *** No rule to make target `builtin.int', needed by `hello.c_date'. Stop.
This appears to be occurring as far back as rotd-2023-07-01 (which is the oldest compiler I have
installed on my system).
|Steps To Reproduce|
$ mmake hello.depend
$ mmake hello
|Additional Information||Linux x86_64 / gcc 4.8.5|
|Tags||No tags attached.|
I have a longer history of (compressed) install directories on my laptop.
I will try to isolate when the problem arose.
The downloads page lists rotds back to 2023 jul 10. I don't know what
algorithm we are currently using to decide that cutoff, but we should
consider changing it to
- keeping the first rotd of each year forever, plus
- keeping the first rotd of each month until the end of the *following* year,
or until the next stable release, whichever is later (so that there is
always at least 12 months of monthly rotds around), plus
- keeping the last N rotds as now, but with a smaller N if this is needed
to keep storage costs in check.
The problem also occurs on the release branch :-(
Specifically, it occurs between 22.01.5 and 22.01.6. My suspicion is that
some of the changes to the digraph module have tickled some latent bug
in the compiler. (The release procedure needs to be updated to explicitly
check that the installed mmake works, but that's another matter ...)
The cutoff for the rotds we keep on the downloads page is governed by the amount
of disk space available (which is not huge). The mercury-srcdist repo. on github should have every ROTD going back several years.
In that case, it should be possible to use mercury-srcdist to hone in
on which rotd introduced the problem. Your server machines seem better
suited to that than my laptop.
About checking that mmake works: while adding an entry to the release
checklist wouldn't hurt, I think a new entry added to the end of the
action for "mmake install" would be even better. Remind me to do that
once this bug is found and fixed (since there is no point in adding a test
whose correctness we cannot check :-()
|Not a problem, I'll identify the ROTD that introduced the problem.|
I've bisected it to this change
Author: Julien Fischer <email@example.com>
Date: Fri Apr 7 19:14:34 2023 +1000
Avoid a warning from make on Windows.
The cygpath utility prints a warning if it is invoked with an empty
BTW, another location you can download old srcdists is
However, these will also be cleared out from time to time to make space.
Yes, that appears to be the commit that broke it; its not obvious to me
*why* it breaks it.
Since any fix will have to work on Windows as well as Linux,
I am not the one to fix this.
Peter, whether the clearing out is done automatically or manually,
could we adopt the retention policy I proposed above?
|I will revert the affected commit for now -- the warnings from cygpath are annoying but otherwise harmless.|
> Peter, whether the clearing out is done automatically or manually,
> could we adopt the retention policy I proposed above?
Unless there is a script to automate it, I will forget such an intricate policy. But it doesn't matter: at the current rate we should be able to retain 2 or more years worth of archives on the server. The mercury-srcdist repository has everything anyway. The archives on testing.mercurylang.org are mainly a side-effect of how the testing setup works; I mention it only in passing.
|2023-09-04 00:27||juliensf||New Issue|
|2023-09-04 10:51||zs||Note Added: 0001208|
|2023-09-04 11:13||juliensf||Note Added: 0001209|
|2023-09-04 11:30||zs||Note Added: 0001210|
|2023-09-04 11:35||juliensf||Note Added: 0001211|
|2023-09-04 11:49||wangp||Note Added: 0001212|
|2023-09-04 12:15||juliensf||Note Added: 0001213|
|2023-09-04 12:20||zs||Note Added: 0001214|
|2023-09-04 12:28||juliensf||Note Added: 0001215|
|2023-09-04 12:29||juliensf||Assigned To||=> juliensf|
|2023-09-04 12:29||juliensf||Status||new => assigned|
|2023-09-04 14:07||wangp||Note Added: 0001216|