[Gc] gc's embedded libatomic_ops

Boehm, Hans hans.boehm at hp.com
Fri Oct 3 10:33:04 PDT 2008

The current GNU-style build machinery tries to use a system-wide one if it's available, and falls back to the internal one if not.  It's not clear to me how we could change this without making some builds a lot more inconvenient.  For example, I'm not at all sure how a Windows/VC++ build would work without the embedded libatomic_ops.

The other peculiarity here is that currently the libatomic_ops tree embedded in gc IS my development tree for libatomic_ops.  It is in fact a full tree that should build stand-alone without the GC.  This is admittedly inelegant.  It was driven by the fact that I couldn't see a way to get away from the embedded tree, and I was doing a bad job at keeping two source trees in sync, mostly for lack of time.  Plus atomic_ops didn't have a proper cvs/svn repository.


> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Rex Dieter
> Sent: Friday, October 03, 2008 9:57 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] gc's embedded libatomic_ops
> Just noticed the embedded copy of libatomic_ops.
> Any reason to *not* use a system-wide/external libatomic_ops?
> Any objections to my preparing patches to do that? :)
> -- Rex
> _______________________________________________
> 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