Problem recursing configure into add-on's stand alone sub-project.
Thu Sep 17 21:53:00 GMT 2009
On Tue, 2009-09-15 at 11:52 -0500, Ryan Arnold wrote:
> On Wed, Sep 9, 2009 at 10:12 AM, Ryan Arnold <firstname.lastname@example.org> wrote:
> > I have an add-on 'foo' which I enable with
> > --enable-add-ons=foo,nptl
> > The addon 'foo' requires a sub-project to be statically linked into
> > it. We'll call this 'bar'.
> > Sub-project 'bar' is maintained officially out-of-tree and has it's
> > own configure.ac and Makefile.in.
> > So the structure is:
> > glibc/foo/
> > glibc/foo/configure.in
> > glibc/foo/bar
> > glibc/foo/bar/configure.ac
> > The glibc/foo/configure.in looks like this:
> > GLIBC_PROVIDES
> > libc_add_on_canonical=dfp
> > AC_CONFIG_SUBDIRS([bar])
> > The GLIBC configure stage does indeed recurse into here and generates
> > configure as:
> > # This file is generated from configure.in by Autoconf. DO NOT EDIT!
> > libc_add_on_canonical=dfp
> > subdirs="$subdirs bar"
> > Unfortunately configure DOESN'T recurse into foo/bar/configure.in.
> > Does anyone know how to get this to work? The documentation isn't helpful.
> > I tried doing AC_CONFIG_SUBDIRS([foo/bar]) but that doesn't work.
> > I've also tried adding libc_add_on_subdirs=bar to foo/configure.in but
> > that doesn't work either.
> > Outside of the glibc build system AC_CONFIG_SUBDIRS(bar) is enough to
> > get this to work. I suspect it's due to the 'addon' machinery.
> > Ryan S. Arnold
> Hi Roland, et al
> Roland suggested the following fix, and I've verified that this works.
> There are a few caveats which I will discuss below:
> diff --git a/aclocal.m4 b/aclocal.m4
> index 4efa41e..0000000 100644
> --- a/aclocal.m4
> +++ b/aclocal.m4
> @@ -5,6 +5,7 @@ dnl AC_REQUIREs or AC_BEFOREs duplicatin
> define([GLIBC_PROVIDES], [dnl
> diff --git a/configure.in b/configure.in
> index 4584afe..0000000 100644
> --- a/configure.in
> +++ b/configure.in
> @@ -6,6 +6,9 @@ AC_CONFIG_SRCDIR([include/features.h])
> +dnl This is here and in GLIBC_PROVIDES so that configure fragments can use it.
> With this fix the important thing to note is that
> AC_CONFIG_SUBDIRS([<dir>]) MUST have the add-on in the path that's
> used in <dir>, e.g.
> The minimal glibc/foo/configure.in needs to look like this.
> An additional point:
> The add-on foo maintainer may find that the first time configure is
> run, when foo/configure hasn't been generated, that foo/bar/configure
> isn't run.
> The file foo/configure isn't generated until the first invocation of
> 'make' detects that the add-on foo needs to be generated. The way
> around this is to base level configure glibc, make (at least through
> the configure stage), and then reconfigure to verifty that the add-on
> builds correctly. Then distribute add-on foo with a pregenerated
> 'foo/configure'. In this way the top-level configure for the
> client/customer/user will invoke foo/bar/configure.
> Thanks for the fix Roland.
As a follow-up, here's a link to the git commit for Roland's fix.
It looks like he resolved the issue with AC_CONFIG_SUBDIRS needing a
add-on relative path. I'll try it out with just
Ryan S. Arnold
More information about the Libc-help