I did make check on an x64 Linux box, and built using Makefile.direct on an ARM box. Everything looked OK. I attempted to put everything in the right places. Libatomic_ops may take a while to show up in the right place.
> -----Original Message-----
> From: Ivan Maidanski [mailto:ivmai <at> mail.ru]
> Sent: Wednesday, November 13, 2013 11:11 PM
> To: Boehm, Hans
> Subject: Re: GC v7.2e release and version numbering policy
> Hi Hans,
> OK, I forwarded it yesterday.
> Tue, 12 Nov 2013, 0:38 UTC from "Boehm, Hans" <hans.boehm <at> hp.com
> > This is embarrassing. I thought I saw your tar files, and was about
> to test them, but they seem to have disappeared from my mail box.
> Overzealous malware
> > detector? Could you please send them again, with a copy to
> hansboehm <at> yahoo.com
> > Thanks.
> > Hans
> > From: Ivan Maidanski [mailto:ivmai <at> mail.ru]
> > Sent: Sunday, November 10, 2013 8:31 AM
> > To: Boehm, Hans
> > Cc: gc <at> linux.hpl.hp.com
> > Subject: GC v7.2e release and version numbering policy
> > Hi Hans,
> > 1. I've prepared gc-7.2e.tar.gz and libatomic_ops-7.2e.tar.gz (I'll
> send to you privately in moment) - please do "make check" and put them
> to gc_source and linux/atomic_ops folder, respectively.
> > 2. I'm going to prepare tarballs for master branches but let's agree
> on the version numbers policy to avoid confusion with added 'b',
> 'c',... letters. As someone already mentioned on the ML,
> major.minor.micro could be a good alternative to
> > I could describe it as:
> > /* The policy regarding version numbers: development code has
> odd */
> > /* "minor" number (and "micro" part is 0); when development is
> finished */
> > /* and a release is prepared, "minor" number is incremented
> (keeping */
> > /* "micro" number still zero), whenever a defect is fixed a new
> release */
> > /* is prepared incrementing "micro" number (most stable release has
> the */
> > /* biggest "micro"
> value). */
> > In other words (similar to libatomic_ops:
> > * gc-7.2 remains as-is (gc-7.2f, ...)
> > * gc-7.3alpha3 is finalized to gc-7.4.0
> > * if a bug will be fixed in gc-7.4.0 then version is changed to gc-
> 7.4.1 when tarball is released (next set of bug fixes goes to gc-7.4.2,
> so on)
> > * gc-7.4.0 -> gc-7.5.0 for development (only exists in repository)
> > * gc-7.5.0 -> gc-7.6.0 on preparing a tarball
> > The drawback of this scheme is that there is no alpha/beta releases,
> but OTOH the bigger "micro" value, the more stable release is.
> > If no objections, I'll prepare gc-7.4.0 and libatomic_ops tarballs.
> > Thank you
> > Regards,
> > Ivan