[Gc] libatomic_ops: time to alpha release?

Boehm, Hans hans.boehm at hp.com
Wed Oct 14 15:52:13 PDT 2009

Is there a reason to put together an alpha release for libatomic_ops before putting one together for the gc?

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?


> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ivan Maidanski
> Sent: Wednesday, October 14, 2009 4:38 AM
> To: gc at napali.hpl.hp.com
> 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.
> Bye.
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list