View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0000565 | mercury | Bug | public | 2023-09-04 00:27 | 2023-09-04 14:07 | ||||||||
Reporter | juliensf | ||||||||||||
Assigned To | juliensf | ||||||||||||
Priority | normal | Severity | major | Reproducibility | have not tried | ||||||||
Status | assigned | Resolution | open | ||||||||||
Product Version | |||||||||||||
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. | ||||||||||||
Attached Files |
|
Notes | |
zs (developer) 2023-09-04 10:51 |
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. |
juliensf (administrator) 2023-09-04 11:13 |
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. |
zs (developer) 2023-09-04 11:30 |
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 :-() |
juliensf (administrator) 2023-09-04 11:35 |
Not a problem, I'll identify the ROTD that introduced the problem. |
wangp (developer) 2023-09-04 11:49 |
I've bisected it to this change commit 8a3be4eae Author: Julien Fischer <juliensf@gmail.com> Date: Fri Apr 7 19:14:34 2023 +1000 Avoid a warning from make on Windows. scripts/Mmake.vars.in: The cygpath utility prints a warning if it is invoked with an empty argument. BTW, another location you can download old srcdists is http://testing.mercurylang.org/archives/ However, these will also be cleared out from time to time to make space. |
juliensf (administrator) 2023-09-04 12:15 |
Yes, that appears to be the commit that broke it; its not obvious to me *why* it breaks it. |
zs (developer) 2023-09-04 12:20 |
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? |
juliensf (administrator) 2023-09-04 12:28 |
I will revert the affected commit for now -- the warnings from cygpath are annoying but otherwise harmless. |
wangp (developer) 2023-09-04 14:07 |
> 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. |
Issue History | |||
Date Modified | Username | Field | Change |
---|---|---|---|
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 |