Re: [Gc]: libatomic_ops: time to alpha release?
ivmai at mail.ru
Wed Oct 14 23:36:17 PDT 2009
"Boehm, Hans" <hans.boehm at hp.com> wrote:
> Is there a reason to put together an alpha release for libatomic_ops before putting one together for the gc?
Not sure for alpha, but someone on the ML asks for a newer tarball in https://www.hpl.hp.com/research/linux/atomic_ops/download.php4
At least, I think, the atomic_ops version info should be updated in the coming GC tarball.
> I seem to be able to build everything again, sort of, after a
> rm /usr/share/aclocal/librapi2.m4
> (actually, I did back it up somewhere)
> It seems to be the case that if some ancient package drops something into /usr/share/aclocal and then doesn't get updated, autotools break?
> More importantly, it also seems I still need to move libtool.m4 out of the way to reconfigure, which I think is unacceptable. It seems like Petter's patch from https://article.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/3379
> fixes that. Is there a reason not to commit it? If I understand correctly, this forces us to permanently remove libtool.m4, create an m4 subdirectory, and presumably check the generated contents of that into the tree, so that libtool is again part of the tree. That's a minor annoyance, but seems OK, since it seems to be the new improved way of doing things. Does this sound right?
Ok. Checked in the first patch and regenerated (adding m4 folder). Added m4 folder to the repo. (autoreconf says "the contents of m4/lt~obsolete.m4 should be added to aclocal.m4" - I've ignored it, is it ok?)
> > Subject: [Gc] libatomic_ops: time to alpha release?
> > Hi!
> > It seems the parties agreed on the building scripts issues...
> > Is it time to make an alpha tarball for libatomic_ops? If
> > yes, I could change the version info in the CVS and prepare
> > the tarball.
More information about the Gc