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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2011/6/1 Eric Blake <eblake@xxxxxxxxxx>:
> 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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]