2024-10-15 17:00 AEDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000565mercuryBugpublic2023-09-04 14:07
Reporterjuliensf 
Assigned Tojuliensf 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusassignedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0000565: Installed mmake cannot build programs
DescriptionAttempting 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 InformationLinux x86_64 / gcc 4.8.5
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0001208

zs (developer)

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.

~0001209

juliensf (administrator)

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.

~0001210

zs (developer)

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 :-()

~0001211

juliensf (administrator)

Not a problem, I'll identify the ROTD that introduced the problem.

~0001212

wangp (developer)

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.

~0001213

juliensf (administrator)

Yes, that appears to be the commit that broke it; its not obvious to me
*why* it breaks it.

~0001214

zs (developer)

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?

~0001215

juliensf (administrator)

I will revert the affected commit for now -- the warnings from cygpath are annoying but otherwise harmless.

~0001216

wangp (developer)

> 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.
+Notes

-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
+Issue History