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

Bruce Mitchener bruce.mitchener at gmail.com
Mon Mar 5 07:07:52 PST 2012


We can solve the problem with pkg-config ... it is the same thing that
breaks Cygwin.

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.

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

 - 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/
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20120305/2c628486/attachment.htm


More information about the Gc mailing list