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

Ivan Maidanski ivmai at mail.ru
Mon Mar 5 06:52:18 PST 2012


Hi Petter,

To sum up, you think:
1) it's safe to relax AC requirements from 2.63 to 2.61;
2) nothing [more] could we do to address the problem with old autotools/pkg-config of Xcode.

Correct? If yes I'll downgrade to 2.61 in both GC and libatomic_ops (of "master" branch).

Regards.

03 02 2012, 18:20 Petter Urkedal <urkedal at nbi.dk>:
> 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?
> > > >
> > > >
> > >
> > >
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 



More information about the Gc mailing list