autoconf: C99 format check

autoconf: C99 format check

[Julius Naperkowski]

I am trying to cross-compile git for mips on a x86 host. But it seems that it is
impossible to pass the C99 Format check in the configure script when
cross_compile mode is activated because the script quits even before it starts
the testprogramm. Is this behavior intentional?

configure: CHECKS for programs
checking for mips-linux-cc... ccache mips-linux-uclibc-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether ccache mips-linux-uclibc-gcc accepts -g... yes
checking for ccache mips-linux-uclibc-gcc option to accept ISO C89... none needed
checking if linker supports -R... no
checking if linker supports -Wl,-rpath,... yes
checking for mips-linux-gar... mips-linux-uclibc-ar
checking for gtar... /bin/tar
checking for asciidoc... no
configure: CHECKS for libraries
checking for SHA1_Init in -lcrypto... no
checking for SHA1_Init in -lssl... no
checking for curl_global_init in -lcurl... no
checking for XML_ParserCreate in -lexpat... no
checking for iconv in -lc... no
checking for iconv in -liconv... no
checking for deflateBound in -lz... no
checking for socket in -lc... yes
configure: CHECKS for header files
checking how to run the C preprocessor... ccache mips-linux-uclibc-gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking for old iconv()... yes
configure: CHECKS for typedefs, structures, and compiler characteristics
checking for struct dirent.d_ino... yes
checking for struct dirent.d_type... yes
checking for struct sockaddr_storage... yes
checking for struct addrinfo... yes
checking for getaddrinfo... (cached) yes
checking for library containing getaddrinfo... none required
checking whether formatted IO functions support C99 size specifiers...
configure: error: cannot run test program while cross compiling
See `config.log' for more details.


A snippet of the configure script:

...
4928: # Define NO_C99_FORMAT if your formatted IO functions (printf/scanf et.al.)
4929: # do not support the 'size specifiers' introduced by C99, namely ll, hh,
4930: # j, z, t. (representing long long int, char, intmax_t, size_t, ptrdiff_t).
4931: # some C compilers supported these specifiers prior to C99 as an extension.
4932: { echo "$as_me:$LINENO: checking whether formatted IO functions support
C99 size specifiers" >&5
4933: echo $ECHO_N "checking whether formatted IO functions support C99 size
specifiers... $ECHO_C" >&6; }
4934: if test "${ac_cv_c_c99_format+set}" = set; then
4935:   echo $ECHO_N "(cached) $ECHO_C" >&6
4936: else
4937:   # Actually git uses only %z (%zu) in alloc.c, and %t (%td) in mktag.c
4938: if test "$cross_compiling" = yes; then
4939:   { { echo "$as_me:$LINENO: error: cannot run test program while cross
compiling
4940: See \`config.log' for more details." >&5
4941: echo "$as_me: error: cannot run test program while cross compiling
4942: See \`config.log' for more details." >&2;}
4943:    { (exit 1); exit 1; }; }
4944: else
4945:   cat >conftest.$ac_ext <<_ACEOF
4946: /* confdefs.h.  */
4947: _ACEOF
4948: cat confdefs.h >>conftest.$ac_ext
4949: cat >>conftest.$ac_ext <<_ACEOF
...


--
Julius

Re: autoconf: C99 format check

[Ralf Wildenhues]

Hello Julius,

* Julius Naperkowski wrote on Thu, Jan 15, 2009 at 02:22:54PM CET:
> I am trying to cross-compile git for mips on a x86 host. But it seems that it is
> impossible to pass the C99 Format check in the configure script when
> cross_compile mode is activated because the script quits even before it starts
> the testprogramm. Is this behavior intentional?

Cross compilation assumes that test programs can be compiled and linked,
but not executed on the build system, i.e., at configure time.  The
fourth argument of AC_RUN_IFELSE may be used to set a default test
result value in the cross compilation case, typically either a
pessimistic default, or one based on $host or so (using $host requires
AC_CANONICAL_HOST, and the config.{guess,sub} scripts).

As a workaround, you the user can pass preset results if you know what
features the host system will have, to configure.  git's configure
script uses three runtime tests.  You can set them with something like
  ./configure ac_cv_c_c99_format=yes \
              ac_cv_fread_reads_directories=no \
              ac_cv_snprintf_returns_bogus=no --host=... ...

although I'm not quite sure if uclibc's *printf functions indeed do
support C99 size specifiers (I think they do though).

I can post a patch to add sane default settings for AC_RUN_IFELSE in
cross compile setups, this weekend.

Cheers,
Ralf

[PATCH] Provide pessimistic defaults for cross compilation tests.

[Ralf Wildenhues]

In a cross compile setup, configure tests that run programs
cannot be executed; in that case, provide pessimistic default
values.

Bug reported by Julius Naperkowski.
---

> I can post a patch to add sane default settings for AC_RUN_IFELSE in
> cross compile setups, this weekend.

 configure.ac |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/configure.ac b/configure.ac
index 363547c..4a208d4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -360,6 +360,7 @@ AC_RUN_IFELSE(
 		else if (strcmp(buf, "12345"))
 		  return 2;]])],
 	[ac_cv_c_c99_format=yes],
+	[ac_cv_c_c99_format=no],
 	[ac_cv_c_c99_format=no])
 ])
 if test $ac_cv_c_c99_format = no; then
@@ -380,6 +381,7 @@ AC_RUN_IFELSE(
 		FILE *f = fopen(".", "r");
 		return f && fread(&c, 1, 1, f)]])],
 	[ac_cv_fread_reads_directories=no],
+	[ac_cv_fread_reads_directories=yes],
 	[ac_cv_fread_reads_directories=yes])
 ])
 if test $ac_cv_fread_reads_directories = yes; then
@@ -414,6 +416,7 @@ AC_RUN_IFELSE(
 		  if (snprintf(buf, 3, "%s", "12345") != 5
 		      || strcmp(buf, "12")) return 1]])],
 	[ac_cv_snprintf_returns_bogus=no],
+	[ac_cv_snprintf_returns_bogus=yes],
 	[ac_cv_snprintf_returns_bogus=yes])
 ])
 if test $ac_cv_snprintf_returns_bogus = yes; then
-- 
1.6.1.137.g3d9e8

Re: [PATCH] Provide pessimistic defaults for cross compilation tests.

[Johannes Schindelin]

Hi,

On Mon, 19 Jan 2009, Ralf Wildenhues wrote:

> In a cross compile setup, configure tests that run programs
> cannot be executed; in that case, provide pessimistic default
> values.

You may want to note in the subject that this patch is about configure.

How do you deal with the hardcoded limitation that uname_S is defined to 
be the output of "uname -s" on the _build_ system, and that quite a large 
part of the Makefile sets variables dependent on this?

IOW are you certain that configure (with your patch) will override _all_ 
uname_S dependent settings?

Ciao,
Dscho

Re: [PATCH] Provide pessimistic defaults for cross compilation tests.

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> How do you deal with the hardcoded limitation that uname_S is defined to 
> be the output of "uname -s" on the _build_ system, and that quite a large 
> part of the Makefile sets variables dependent on this?
>
> IOW are you certain that configure (with your patch) will override _all_ 
> uname_S dependent settings?

It may be a valid question but it is not limited to cross compilation, is
it?  The matter is if values the Makefile wants to default to can be
overriden by whatever is placed in config.mak, and as long as that is Ok
we won't have a problem with or without use of configure (which is a
second class citizen).

Re: [PATCH] Provide pessimistic defaults for cross compilation tests.

[Junio C Hamano]

Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:

> In a cross compile setup, configure tests that run programs
> cannot be executed; in that case, provide pessimistic default
> values.
>
> Bug reported by Julius Naperkowski.
> ---
>
>> I can post a patch to add sane default settings for AC_RUN_IFELSE in
>> cross compile setups, this weekend.
>
>  configure.ac |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 363547c..4a208d4 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -360,6 +360,7 @@ AC_RUN_IFELSE(
>  		else if (strcmp(buf, "12345"))
>  		  return 2;]])],
>  	[ac_cv_c_c99_format=yes],
> +	[ac_cv_c_c99_format=no],
>  	[ac_cv_c_c99_format=no])
>  ])
>  if test $ac_cv_c_c99_format = no; then

This one probably is Ok, but...

> @@ -380,6 +381,7 @@ AC_RUN_IFELSE(
>  		FILE *f = fopen(".", "r");
>  		return f && fread(&c, 1, 1, f)]])],
>  	[ac_cv_fread_reads_directories=no],
> +	[ac_cv_fread_reads_directories=yes],
>  	[ac_cv_fread_reads_directories=yes])
>  ])
>  if test $ac_cv_fread_reads_directories = yes; then

I am not quite sure if this is an improvement ...

> @@ -414,6 +416,7 @@ AC_RUN_IFELSE(
>  		  if (snprintf(buf, 3, "%s", "12345") != 5
>  		      || strcmp(buf, "12")) return 1]])],
>  	[ac_cv_snprintf_returns_bogus=no],
> +	[ac_cv_snprintf_returns_bogus=yes],
>  	[ac_cv_snprintf_returns_bogus=yes])
>  ])
>  if test $ac_cv_snprintf_returns_bogus = yes; then

... nor this one.

Is there a way to say something like "I'll autodetect as much as I can
without running tests, but please tell me these characteristics of the
target system manually" and leave the resulting config.mak.autogen in a
shape that will guarantee compilation failure until the missing ones are
supplied by config.mak?

The thing is, I am not convinced that it is desirable to be able to build
a possibly suboptimal binary in a cross compilation environment, without
being told in what aspect of the resulting binary is suboptimal.  I'd
rather see a build system that honestly tells me what information it needs
but couldn't find, so that I would know I have a chance to help it.

Of course, suggesting a pessimistic default that can result in suboptimal
but correct result would be a good thing to help the user help the build.
I just think it is a good idea to tell the user we are giving such hint a
bit more loudly to draw attention.

Re: [PATCH] Provide pessimistic defaults for cross compilation tests.

[Ralf Wildenhues]

* Junio C Hamano wrote on Tue, Jan 20, 2009 at 03:49:03AM CET:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > How do you deal with the hardcoded limitation that uname_S is defined to 
> > be the output of "uname -s" on the _build_ system, and that quite a large 
> > part of the Makefile sets variables dependent on this?

Oh, up to now I have blissfully ignored cross-compilation issues in git
outside of configure.ac.  :-)

> > IOW are you certain that configure (with your patch) will override _all_ 
> > uname_S dependent settings?

No, I am certain they won't override them at all.

Fixing Makefile will be more (but independent) work.  All I did was get
configure.ac in shape to not error out in the face of cross compilation.

> It may be a valid question but it is not limited to cross compilation, is
> it?  The matter is if values the Makefile wants to default to can be
> overriden by whatever is placed in config.mak, and as long as that is Ok
> we won't have a problem with or without use of configure (which is a
> second class citizen).

Yeah, I figured that.  I assume it makes little sense to suggest adding
AC_CANONICAL_HOST to configure.ac, letting config.{guess,sub} do their
job, and the user to use "./configure --host=some-value" to specify a
host alias, and then using the computed host triple to decide features,
without the need to modify Makefile or other input files.

See, in a way I come from the GNU world here, and that's what I know
best.  Since git does its own setup here, I trust you will invent some
way to solve this.

Thanks,
Ralf

Re: [PATCH] Provide pessimistic defaults for cross compilation tests.

[Ralf Wildenhues]

* Junio C Hamano wrote on Tue, Jan 20, 2009 at 07:50:52AM CET:
> Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> > --- a/configure.ac
> > +++ b/configure.ac

> > +	[ac_cv_c_c99_format=no],

> >  if test $ac_cv_c_c99_format = no; then
> 
> This one probably is Ok, but...
> 
> > @@ -380,6 +381,7 @@ AC_RUN_IFELSE(
> >  		FILE *f = fopen(".", "r");
> >  		return f && fread(&c, 1, 1, f)]])],
> >  	[ac_cv_fread_reads_directories=no],
> > +	[ac_cv_fread_reads_directories=yes],
> >  	[ac_cv_fread_reads_directories=yes])
> >  ])
> >  if test $ac_cv_fread_reads_directories = yes; then
> 
> I am not quite sure if this is an improvement ...
> 
> > @@ -414,6 +416,7 @@ AC_RUN_IFELSE(
> >  		  if (snprintf(buf, 3, "%s", "12345") != 5
> >  		      || strcmp(buf, "12")) return 1]])],
> >  	[ac_cv_snprintf_returns_bogus=no],
> > +	[ac_cv_snprintf_returns_bogus=yes],
> >  	[ac_cv_snprintf_returns_bogus=yes])
> >  ])
> >  if test $ac_cv_snprintf_returns_bogus = yes; then
> 
> ... nor this one.

I can see why you're cautious here, but AFAICS the actual code that will
be enabled by these defaults is portable to systems that have no bogus
snprintf and whose fread does not read directories.  IOW, all you lose
is a bit of performance at most.

> Is there a way to say something like "I'll autodetect as much as I can
> without running tests, but please tell me these characteristics of the
> target system manually" and leave the resulting config.mak.autogen in a
> shape that will guarantee compilation failure until the missing ones are
> supplied by config.mak?

Well, without my patch, each of these three tests will get configure to
error out.  Instead of setting a variable, these added arguments can
also output a more helpful error, in the sense of
  "please find out whether the return value of snprintf is ok,
   and set $ac_cv_snprintf_returns_bogus accordingly when rerunning
   configure"

> The thing is, I am not convinced that it is desirable to be able to build
> a possibly suboptimal binary in a cross compilation environment, without
> being told in what aspect of the resulting binary is suboptimal.  I'd
> rather see a build system that honestly tells me what information it needs
> but couldn't find, so that I would know I have a chance to help it.

Sure.

> Of course, suggesting a pessimistic default that can result in suboptimal
> but correct result would be a good thing to help the user help the build.
> I just think it is a good idea to tell the user we are giving such hint a
> bit more loudly to draw attention.

Agreed, too.  Would you prefer a hard erroring out of configure, for
each of the tests, or would it suffice to see a warning fly by?

Thanks,
Ralf