2011/6/1 Eric Blake <eblake(a)redhat.com>:
On 05/31/2011 02:51 PM, Matthias Bolte wrote:
> AM_GNU_GETTEXT calls AM_ICONV_LINK. AM_ICONV_LINK saves and alters
> CPPFLAGS, but doesn't restore it when it finds libiconv. This
> results in /usr/local/include ending up in the gcc command line
> before the include path for the local include directory. This makes
> gcc pick a previous installed libvirt.h instead of the correct one
> from the source tree.
>
> Workaround this problem by saving and restoring CPPFLAGS around
> the AM_GNU_GETTEXT call.
> ---
> configure.ac | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index b2ba930..8f46dbd 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2011,8 +2011,16 @@ dnl Enable building libvirtd?
> AM_CONDITIONAL([WITH_LIBVIRTD],[test "x$with_libvirtd" =
"xyes"])
>
> dnl Check for gettext - don't go any newer than what RHEL 5 supports
> +dnl
> +dnl save and restore CPPFLAGS around gettext check as the internal iconv
> +dnl check might leave -I/usr/local/include in CPPFLAGS on FreeBSD resulting
> +dnl in the build picking up previously installed libvirt/libvirt.h instead
> +dnl of the correct one from the soucre tree
> +
> +save_CPPFLAGS="$CPPFLAGS"
> AM_GNU_GETTEXT_VERSION([0.17])
> AM_GNU_GETTEXT([external])
> +CPPFLAGS="$save_CPPFLAGS"
Does this still pick up /usr/local/include later in the command line,
for the portion of the build that actually needs to include iconf
headers, but in a position after our internal headers have been found first?
I didn't check, but when we assume that AM_GNU_GETTEXT extends
CPPFLAGS for a reason and not just by accident then we need to
preserve it's additions to CPPFLAGS but in a later place in the
commandline. As the actual problem is that CPPFLAGS comes before
-I../include.
I was actually thinking that we should instead work around this by
setting AM_CPPFLAGS somewhere in our Makefile.am files. That is, when
AM_CPPFLAGS is set, then automake outputs $(AM_CPPFLAGS) $(CPPFLAGS)
when producing compilation rules, such that our internal CPPFLAGS
settings come first in the command line, prior to anything inherited
during configure (including the internal iconv settings). That is, with
new enough automake, I think this alternative patch solve your BSD
compilation (although other directories need the same treatment),
without needing any configure.ac hacks.
On the other hand, it looks like RHEL 5 only supports automake 1.9.6,
and the automake NEWS doesn't mention AM_CPPFLAGS until 1.10 :(
So even if the approach in my patch solves your issue, I think it's a
non-starter, and something like your patch may be the best we can do.
But I'm still worried that we have to use -I/usr/local/include somewhere
in the command line, which means we would have to modify src/Makefile.am
(and friends) to have:
INCLUDES= ... $(GETTEXT_CPPFLAGS)
where GETTEXT_CPPFLAGS is substituted with the difference in
$save_CPPFLAGS and $CPPFLAGS prior to the point where we restore $CPPFLAGS.
That's probably what we should do here.
Now how to compute this difference? When we assume that save_CPPFLAGS
and CPPFLAGS have a common prefix that we need to strip to get
GETTEXT_CPPFLAGS then we could do it like this
echo $(CPPFLAGS) | cut -c 1-`expr length $(save_CPPFLAGS)` --complement -
This is probably neither the best nor a robustest way to do this. Do
you have a better idea?
--
Matthias Bolte
http://photron.blogspot.com