[Gc] Re: Building on OS X: Autotools vs pkg-config issues

Petter Urkedal urkedal at nbi.dk
Sat Mar 3 06:16:59 PST 2012


As far as I understand AC_PREREQ is just a sanity check that the used
Autoconf is recent enough, so it won't affect the actual version used
(by e.g. autoreconf).  Therefore, I think the optimal value for the
argument of this macro is, depending on how cautious we want to be,
a) the earliest version which is not known to break, or b) the earliest
version which is known to work.

I tried on RHEL-5 which has Autoconf 2.59.  I had to replace
"LT_INIT([disable-shared])" with "AC_PROG_LIBTOOL" in libatomic_ops
since libtool was too old, but apart from that it builds.  In other
words, I think 2.59 and thus 2.61 is safe.  On the other hand, I don't
think we can do anything about the libtool incompatibility unless we
revert to the now deprecated "AC_PROG_LIBTOOL".

On 2012-03-03, Ivan Maidanski wrote:
> Hi Bruce,
> 
> Is my understanding correct that you don't have problems with pre-generated configure (distributed in "release" branch and tar-balls)?
> 
> I'm not an expert in autotools - could somebody else express the opinion? (May be, Petter Urkedal's could.)
>  
> I'm really not excited about downgrading AC_PREREQ (we already did it from 2.64 to 2.63 and use suggest move to 2.61).
> 
> PS. Cygwin autotools fails to process configure.ac too but build is done w/o problems (provided you have generated configure).
> 
> 
> 02 03 2012, 09:48 Bruce Mitchener <bruce.mitchener at gmail.com>:
> > On Fri, Mar 2, 2012 at 12:28 PM, Bruce Mitchener
> > <bruce.mitchener at gmail.com>wrote:
> > 
> > > Hello,
> > >
> > > It would be really nice if Boehm could build out of the box on Mac OS X
> > > without having to install updated autotools and pkg-config.  A quick check
> > > seems to show that it could work with the version of autotools shipped on
> > > OS X, with the exception of the usage of pkg-config.
> > >
> > > One fix would be to put a copy of pkg.m4 in bdwgc/m4/ next to the
> > > gc_set_version.m4 and distribute that yourself.  With that and changing the
> > > AC_PREREQ to use 2.61 for both the GC and libatomic_ops, things appear to
> > > work.  There's an argument to be made that shipping pkg.m4 here is bad, but
> > > the current situation also seems a bit bad.
> > >
> > > Another fix might be to not use pkg-config or to support some way of not
> > > using it, but that seems like more work.
> > >
> > > Is there another way that we could get this to where it works out of the
> > > box on a roughly out of the box XCode installation?
> > >
> > 
> > An alternative here would be to just do a classic autoconf check against
> > --with-libatomic-ops=/path/to/installation/prefix and touch up CFLAGS /
> > LIBS accordingly. That'd remove the dependency on PKG_CHECK_MODULES and add
> > maybe 20 lines of autoconf hackery.  (Other people / libraries can still
> > use pkg-config to find Boehm / libatomic_ops, just that the Boehm
> > configuration process wouldn't use it.)
> > 
> >  - Bruce
> > 
> > > The background for this is that in Open Dylan (http://opendylan.org/), we
> > > have various build / packaging issues where we'd rather just pull in Boehm
> > > via a git submodule and do our own build as part of our build system to
> > > make sure that everything is correctly configured and then link to the
> > > static library.  But we don't require newer autotools or pkg-config, so
> > > this is a bit of an issue for us in terms of developer usability.
> > > Thoughts?
> > >
> > >
> > 
> > 


More information about the Gc mailing list