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

Ivan Maidanski ivmai at mail.ru
Mon Mar 5 10:16:49 PST 2012


Hi Bruce,

05 03 2012, 19:07 Bruce Mitchener <bruce.mitchener at gmail.com>:
> We can solve the problem with pkg-config ... it is the same thing that
> breaks Cygwin.

Good.

> 
> I'm still planning on cooking up a patch, but I'm in the final 36 hours
> before leaving on a 5 day holiday so I'm a bit busy with a lot of stuff.
>  If I don't do it while on holiday, I'll do it next week when I return.

NP. Thanks.

> 
> It is safe to drop to 2.61 for AC requirements in my testing so far.

Ok. I've just applied the patch to master branch of bdwgc and libatomic_ops.

Regards.

> 
>  - Bruce
> 
> On Mon, Mar 5, 2012 at 9:52 PM, Ivan Maidanski <ivmai at mail.ru> wrote:
> 
> > 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