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