[Gc] gc's embedded libatomic_ops
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
More information about the Gc