[Gc] Maintainers attention: libatomic_ops

Matthias Andree matthias.andree at gmx.de
Wed Sep 30 05:08:34 PDT 2009


Am 29.09.2009, 22:46 Uhr, schrieb Boehm, Hans <hans.boehm at hp.com>:

> Thanks for doing this.
>
> Just to clarify:
>
> It looks like Ivan removed libatomic_ops-1.2 and added libatomic_ops,  
> which I think is all you can easily do with cvs.  If you had no pending  
> changes in libatomic_ops, it looks to me like "cvs update -d ." will do  
> the right thing.  I'm not sure whether a local rename/mv will.  I  
> suspect that might cause problems with the CVS meta-information?
>
> I can build correctly again, but I'm seeing
>
> ../bdwgc/configure: line 1656: GC_SET_VERSION: command not found
>
> I haven't looked into where that comes from.

This is typically caused by aclocal not picking up/finding a definition  
(usually AC_DEFUN) for GC_SET_VERSION.

How do you typically rebuild the auto* toolchain? The canonical command  
has been "autoreconf" for a while; "autoreconf -ivf" should fix most  
issues. If local m4 directories are missing, they may need to be added to  
Makefile.am, see for example the beginning of  
http://mknod.org/svn/fetchmail/branches/BRANCH_6-3/Makefile.am.

> I suspect we should standardize on particular versions of the autotools  
> to minimize gratuitous and voluminous output from cvs diff.

No, don't do that. You shouldn't ever need that, you'd only need to  
stipulate minimum automake (AUTOMAKE_OPTIONS in Makefile.am) and autoconf  
versions (AC_PREREQ in configure.{ac,in}) if you use newer features.

Make sure to check autoconf output for warnings, especially about  
definitions not found.

BTW, the instructions (README.QUICK) may need adjustment, you can usually  
use "make check" to build and test an automake-built SW package, and it's  
usually more efficient than "make && make check".

HTH

-- 
Matthias Andree


More information about the Gc mailing list