Re: autofoo help requested

[Simon Marchi <simark at simark dot ca>]

On 2017-12-22 06:21 PM, John Baldwin wrote:
> I'm attempting to get a "bare" build of GDB on FreeBSD working so that the
> existing FreeBSD build bots will start working.  By "bare" I mean just
> using "./configure" without any arguments or build-related environment
> variables.  The build currently dies in bfd/ because it is unable to locate
> the header for gettext:
> 
> In file included from ../../bfd/archive.c:134:
> ../../bfd/sysdep.h:184:11: fatal error: 'libintl.h' file not found
> # include <libintl.h>
>           ^~~~~~~~~~~
> 
> In FreeBSD gettext is installed as a 3rd party package in /usr/local
> and the configure script for the intl/ subdirectory does find the
> library, but it leaves INCINTL set to an empty value when I think
> it should be set to "-I /usr/local/include":
> 
> % cat config.intl 
> # This file records the configuration of libintl in a form that
> # can be read back in by a configure script in a sister directory.
> # See config/gettext.m4 for its use.
> 
> USE_NLS='yes'
> LIBINTL='/usr/local/lib/libintl.so -Wl,-rpath -Wl,/usr/local/lib'
> LIBINTL_DEP=''
> INCINTL=''
> 
> XGETTEXT='/usr/local/bin/xgettext'
> GMSGFMT='/usr/local/bin/msgfmt'
> POSUB='po'
> 
> Looking in config.log of the 'intl/' subdirectory, it does figure out
> that it needs '-I /usr/local/include' in CPPFLAGS, but it doesn't
> include it in the generated INCINTL:
> 
> grep local.include *
> Makefile:CPPFLAGS = -I/usr/local/include
> config.log:configure:5455: cc -o conftest -g -O2  -I/usr/local/include   conftest.c  >&5
> config.log:configure:5518: cc -o conftest -g -O2  -I/usr/local/include   conftest.c  /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib >&5
> config.log:configure:5601: cc -c -g -O2 -I/usr/local/include conftest.c >&5
> config.log:configure:5639: cc -o conftest -g -O2 -I/usr/local/include   conftest.c  >&5
> config.log:configure:5674: cc -o conftest -g -O2 -I/usr/local/include   conftest.c  >&5
> config.log:configure:5833: cc -o conftest -g -O2 -I/usr/local/include   conftest.c  >&5
> config.log:configure:6251: cc -o conftest -g -O2 -I/usr/local/include    conftest.c  /usr/local/lib/libintl.so -Wl,-rpath -Wl,/usr/local/lib >&5
> config.log:CPPFLAGS='-I/usr/local/include'
> config.status:S["CPPFLAGS"]="-I/usr/local/include"
> 
> I have tried looking at the config/gettext.m4 file to ascertain how it
> would set INCINTL and trying to guess why it isn't doing so, but so far
> I haven't made much progress.
> 
> Does anyone have any useful suggestions or pointers on how I can track
> this down further?
> 
> Thanks.
> 

I don't know what the expected output of AM_GNU_GETTEXT is.  Should we expect
it to set INCINTL or CPPFLAGS?

In any case, INCINTL is reset to an empty value in intl/configure.ac, and CPPFLAGS
is used not fowarded to config.intl, so there's no way right now the preprocessor
flags found by AM_GNU_GETTEXT can make their way to config.intl.  It can be done
by assigning CPPFLAGS to INCINTL, like this:


diff --git a/intl/configure b/intl/configure
index 2abbcb5b05..0c655d6c38 100755
--- a/intl/configure
+++ b/intl/configure
@@ -6617,6 +6617,8 @@ case $USE_INCLUDED_LIBINTL in
     ;;
 esac

+INCINTL="$CPPFLAGS"
+
 ac_config_files="$ac_config_files Makefile config.intl"

 cat >confcache <<\_ACEOF
diff --git a/intl/configure.ac b/intl/configure.ac
index 36cf97fe4b..80ea7dfd78 100644
--- a/intl/configure.ac
+++ b/intl/configure.ac
@@ -47,5 +47,7 @@ case $USE_INCLUDED_LIBINTL in
     ;;
 esac

+INCINTL="$CPPFLAGS"
+
 AC_CONFIG_FILES(Makefile config.intl)
 AC_OUTPUT


With this, I am able to get the build to go further.  I don't know if this is
just papering over the real problem or if it would be a valid solution (of
course not as-is, since it doesn't consider the USE_INCLUDED_LIBINTL=yes case).
But in a sense if AM_GNU_GETTEXT sets CPPFLAGS to -I/usr/local/include, it's
because it found out that this flag was needed in order to use libintl.  And
the INCINTL value in config.intl should contain the preprocessor flags needed
to get libintl working.  So it might make sense to do it...

Simon