[libvirt] [PATCH] freebsd: Fix build problem due to picking up the wrong libvirt.h

Matthias Bolte matthias.bolte at googlemail.com
Tue Jul 26 20:45:35 UTC 2011

2011/6/1 Eric Blake <eblake at 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
>> +
>>  AM_GNU_GETTEXT([external])
> 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 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:
> 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

More information about the libvir-list mailing list