{"thread":{"id":"17191","subject":"autoconf: C99 format check","startedAt":"2009-01-15T13:22:54Z","lastAt":"2009-01-20T07:04:52Z","messageCount":8,"participants":["Julius Naperkowski","Ralf Wildenhues","Johannes Schindelin","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"100575","messageId":"loom.20090115T123123-915@post.gmane.org","threadId":"17191","inReplyTo":null,"subject":"autoconf: C99 format check","fromName":"Julius Naperkowski","fromEmail":"j.nap@gmx.de","sentAt":"2009-01-15T13:22:54Z","receivedAt":"2009-01-15T13:22:54Z","isPatch":false,"sender":{"key":"j.nap@gmx.de","avatar":null},"body":"I am trying to cross-compile git for mips on a x86 host. But it seems that it is\nimpossible to pass the C99 Format check in the configure script when\ncross_compile mode is activated because the script quits even before it starts\nthe testprogramm. Is this behavior intentional?\n\nconfigure: CHECKS for programs\nchecking for mips-linux-cc... ccache mips-linux-uclibc-gcc\nchecking for C compiler default output file name... a.out\nchecking whether the C compiler works... yes\nchecking whether we are cross compiling... yes\nchecking for suffix of executables... \nchecking for suffix of object files... o\nchecking whether we are using the GNU C compiler... yes\nchecking whether ccache mips-linux-uclibc-gcc accepts -g... yes\nchecking for ccache mips-linux-uclibc-gcc option to accept ISO C89... none needed\nchecking if linker supports -R... no\nchecking if linker supports -Wl,-rpath,... yes\nchecking for mips-linux-gar... mips-linux-uclibc-ar\nchecking for gtar... /bin/tar\nchecking for asciidoc... no\nconfigure: CHECKS for libraries\nchecking for SHA1_Init in -lcrypto... no\nchecking for SHA1_Init in -lssl... no\nchecking for curl_global_init in -lcurl... no\nchecking for XML_ParserCreate in -lexpat... no\nchecking for iconv in -lc... no\nchecking for iconv in -liconv... no\nchecking for deflateBound in -lz... no\nchecking for socket in -lc... yes\nconfigure: CHECKS for header files\nchecking how to run the C preprocessor... ccache mips-linux-uclibc-gcc -E\nchecking for grep that handles long lines and -e... /bin/grep\nchecking for egrep... /bin/grep -E\nchecking for ANSI C header files... yes\nchecking for sys/types.h... yes\nchecking for sys/stat.h... yes\nchecking for stdlib.h... yes\nchecking for string.h... yes\nchecking for memory.h... yes\nchecking for strings.h... yes\nchecking for inttypes.h... yes\nchecking for stdint.h... yes\nchecking for unistd.h... yes\nchecking sys/select.h usability... yes\nchecking sys/select.h presence... yes\nchecking for sys/select.h... yes\nchecking for old iconv()... yes\nconfigure: CHECKS for typedefs, structures, and compiler characteristics\nchecking for struct dirent.d_ino... yes\nchecking for struct dirent.d_type... yes\nchecking for struct sockaddr_storage... yes\nchecking for struct addrinfo... yes\nchecking for getaddrinfo... (cached) yes\nchecking for library containing getaddrinfo... none required\nchecking whether formatted IO functions support C99 size specifiers...\nconfigure: error: cannot run test program while cross compiling\nSee `config.log' for more details.\n\n\nA snippet of the configure script:\n\n...\n4928: # Define NO_C99_FORMAT if your formatted IO functions (printf/scanf et.al.)\n4929: # do not support the 'size specifiers' introduced by C99, namely ll, hh,\n4930: # j, z, t. (representing long long int, char, intmax_t, size_t, ptrdiff_t).\n4931: # some C compilers supported these specifiers prior to C99 as an extension.\n4932: { echo \"$as_me:$LINENO: checking whether formatted IO functions support\nC99 size specifiers\" >&5\n4933: echo $ECHO_N \"checking whether formatted IO functions support C99 size\nspecifiers... $ECHO_C\" >&6; }\n4934: if test \"${ac_cv_c_c99_format+set}\" = set; then\n4935:   echo $ECHO_N \"(cached) $ECHO_C\" >&6\n4936: else\n4937:   # Actually git uses only %z (%zu) in alloc.c, and %t (%td) in mktag.c\n4938: if test \"$cross_compiling\" = yes; then\n4939:   { { echo \"$as_me:$LINENO: error: cannot run test program while cross\ncompiling\n4940: See \\`config.log' for more details.\" >&5\n4941: echo \"$as_me: error: cannot run test program while cross compiling\n4942: See \\`config.log' for more details.\" >&2;}\n4943:    { (exit 1); exit 1; }; }\n4944: else\n4945:   cat >conftest.$ac_ext <<_ACEOF\n4946: /* confdefs.h.  */\n4947: _ACEOF\n4948: cat confdefs.h >>conftest.$ac_ext\n4949: cat >>conftest.$ac_ext <<_ACEOF\n...\n\n\n--\nJulius\n"},{"id":"100712","messageId":"20090116094110.GD25275@ins.uni-bonn.de","threadId":"17191","inReplyTo":"loom.20090115T123123-915@post.gmane.org","subject":"Re: autoconf: C99 format check","fromName":"Ralf Wildenhues","fromEmail":"ralf.wildenhues@gmx.de","sentAt":"2009-01-16T09:41:10Z","receivedAt":"2009-01-16T09:41:10Z","isPatch":false,"sender":{"key":"ralf.wildenhues@gmx.de","avatar":null},"body":"Hello Julius,\n\n* Julius Naperkowski wrote on Thu, Jan 15, 2009 at 02:22:54PM CET:\n> I am trying to cross-compile git for mips on a x86 host. But it seems that it is\n> impossible to pass the C99 Format check in the configure script when\n> cross_compile mode is activated because the script quits even before it starts\n> the testprogramm. Is this behavior intentional?\n\nCross compilation assumes that test programs can be compiled and linked,\nbut not executed on the build system, i.e., at configure time.  The\nfourth argument of AC_RUN_IFELSE may be used to set a default test\nresult value in the cross compilation case, typically either a\npessimistic default, or one based on $host or so (using $host requires\nAC_CANONICAL_HOST, and the config.{guess,sub} scripts).\n\nAs a workaround, you the user can pass preset results if you know what\nfeatures the host system will have, to configure.  git's configure\nscript uses three runtime tests.  You can set them with something like\n  ./configure ac_cv_c_c99_format=yes \\\n              ac_cv_fread_reads_directories=no \\\n              ac_cv_snprintf_returns_bogus=no --host=... ...\n\nalthough I'm not quite sure if uclibc's *printf functions indeed do\nsupport C99 size specifiers (I think they do though).\n\nI can post a patch to add sane default settings for AC_RUN_IFELSE in\ncross compile setups, this weekend.\n\nCheers,\nRalf\n"},{"id":"101165","messageId":"20090119203400.GA3539@ins.uni-bonn.de","threadId":"17191","inReplyTo":"20090116094110.GD25275@ins.uni-bonn.de","subject":"[PATCH] Provide pessimistic defaults for cross compilation tests.","fromName":"Ralf Wildenhues","fromEmail":"ralf.wildenhues@gmx.de","sentAt":"2009-01-19T20:34:01Z","receivedAt":"2009-01-19T20:34:01Z","isPatch":true,"sender":{"key":"ralf.wildenhues@gmx.de","avatar":null},"body":"In a cross compile setup, configure tests that run programs\ncannot be executed; in that case, provide pessimistic default\nvalues.\n\nBug reported by Julius Naperkowski.\n---\n\n> I can post a patch to add sane default settings for AC_RUN_IFELSE in\n> cross compile setups, this weekend.\n\n configure.ac |    3 +++\n 1 files changed, 3 insertions(+), 0 deletions(-)\n\ndiff --git a/configure.ac b/configure.ac\nindex 363547c..4a208d4 100644\n--- a/configure.ac\n+++ b/configure.ac\n@@ -360,6 +360,7 @@ AC_RUN_IFELSE(\n \t\telse if (strcmp(buf, \"12345\"))\n \t\t  return 2;]])],\n \t[ac_cv_c_c99_format=yes],\n+\t[ac_cv_c_c99_format=no],\n \t[ac_cv_c_c99_format=no])\n ])\n if test $ac_cv_c_c99_format = no; then\n@@ -380,6 +381,7 @@ AC_RUN_IFELSE(\n \t\tFILE *f = fopen(\".\", \"r\");\n \t\treturn f && fread(&c, 1, 1, f)]])],\n \t[ac_cv_fread_reads_directories=no],\n+\t[ac_cv_fread_reads_directories=yes],\n \t[ac_cv_fread_reads_directories=yes])\n ])\n if test $ac_cv_fread_reads_directories = yes; then\n@@ -414,6 +416,7 @@ AC_RUN_IFELSE(\n \t\t  if (snprintf(buf, 3, \"%s\", \"12345\") != 5\n \t\t      || strcmp(buf, \"12\")) return 1]])],\n \t[ac_cv_snprintf_returns_bogus=no],\n+\t[ac_cv_snprintf_returns_bogus=yes],\n \t[ac_cv_snprintf_returns_bogus=yes])\n ])\n if test $ac_cv_snprintf_returns_bogus = yes; then\n-- \n1.6.1.137.g3d9e8\n"},{"id":"101183","messageId":"alpine.DEB.1.00.0901200037510.3586@pacific.mpi-cbg.de","threadId":"17191","inReplyTo":"20090119203400.GA3539@ins.uni-bonn.de","subject":"Re: [PATCH] Provide pessimistic defaults for cross compilation tests.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-19T23:39:44Z","receivedAt":"2009-01-19T23:39:44Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 19 Jan 2009, Ralf Wildenhues wrote:\n\n> In a cross compile setup, configure tests that run programs\n> cannot be executed; in that case, provide pessimistic default\n> values.\n\nYou may want to note in the subject that this patch is about configure.\n\nHow do you deal with the hardcoded limitation that uname_S is defined to \nbe the output of \"uname -s\" on the _build_ system, and that quite a large \npart of the Makefile sets variables dependent on this?\n\nIOW are you certain that configure (with your patch) will override _all_ \nuname_S dependent settings?\n\nCiao,\nDscho\n"},{"id":"101204","messageId":"7vab9mpu8w.fsf@gitster.siamese.dyndns.org","threadId":"17191","inReplyTo":"alpine.DEB.1.00.0901200037510.3586@pacific.mpi-cbg.de","subject":"Re: [PATCH] Provide pessimistic defaults for cross compilation tests.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-20T02:49:03Z","receivedAt":"2009-01-20T02:49:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> How do you deal with the hardcoded limitation that uname_S is defined to \n> be the output of \"uname -s\" on the _build_ system, and that quite a large \n> part of the Makefile sets variables dependent on this?\n>\n> IOW are you certain that configure (with your patch) will override _all_ \n> uname_S dependent settings?\n\nIt may be a valid question but it is not limited to cross compilation, is\nit?  The matter is if values the Makefile wants to default to can be\noverriden by whatever is placed in config.mak, and as long as that is Ok\nwe won't have a problem with or without use of configure (which is a\nsecond class citizen).\n"},{"id":"101221","messageId":"7v63kampwz.fsf@gitster.siamese.dyndns.org","threadId":"17191","inReplyTo":"20090119203400.GA3539@ins.uni-bonn.de","subject":"Re: [PATCH] Provide pessimistic defaults for cross compilation tests.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-20T06:50:52Z","receivedAt":"2009-01-20T06:50:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:\n\n> In a cross compile setup, configure tests that run programs\n> cannot be executed; in that case, provide pessimistic default\n> values.\n>\n> Bug reported by Julius Naperkowski.\n> ---\n>\n>> I can post a patch to add sane default settings for AC_RUN_IFELSE in\n>> cross compile setups, this weekend.\n>\n>  configure.ac |    3 +++\n>  1 files changed, 3 insertions(+), 0 deletions(-)\n>\n> diff --git a/configure.ac b/configure.ac\n> index 363547c..4a208d4 100644\n> --- a/configure.ac\n> +++ b/configure.ac\n> @@ -360,6 +360,7 @@ AC_RUN_IFELSE(\n>  \t\telse if (strcmp(buf, \"12345\"))\n>  \t\t  return 2;]])],\n>  \t[ac_cv_c_c99_format=yes],\n> +\t[ac_cv_c_c99_format=no],\n>  \t[ac_cv_c_c99_format=no])\n>  ])\n>  if test $ac_cv_c_c99_format = no; then\n\nThis one probably is Ok, but...\n\n> @@ -380,6 +381,7 @@ AC_RUN_IFELSE(\n>  \t\tFILE *f = fopen(\".\", \"r\");\n>  \t\treturn f && fread(&c, 1, 1, f)]])],\n>  \t[ac_cv_fread_reads_directories=no],\n> +\t[ac_cv_fread_reads_directories=yes],\n>  \t[ac_cv_fread_reads_directories=yes])\n>  ])\n>  if test $ac_cv_fread_reads_directories = yes; then\n\nI am not quite sure if this is an improvement ...\n\n> @@ -414,6 +416,7 @@ AC_RUN_IFELSE(\n>  \t\t  if (snprintf(buf, 3, \"%s\", \"12345\") != 5\n>  \t\t      || strcmp(buf, \"12\")) return 1]])],\n>  \t[ac_cv_snprintf_returns_bogus=no],\n> +\t[ac_cv_snprintf_returns_bogus=yes],\n>  \t[ac_cv_snprintf_returns_bogus=yes])\n>  ])\n>  if test $ac_cv_snprintf_returns_bogus = yes; then\n\n... nor this one.\n\nIs there a way to say something like \"I'll autodetect as much as I can\nwithout running tests, but please tell me these characteristics of the\ntarget system manually\" and leave the resulting config.mak.autogen in a\nshape that will guarantee compilation failure until the missing ones are\nsupplied by config.mak?\n\nThe thing is, I am not convinced that it is desirable to be able to build\na possibly suboptimal binary in a cross compilation environment, without\nbeing told in what aspect of the resulting binary is suboptimal.  I'd\nrather see a build system that honestly tells me what information it needs\nbut couldn't find, so that I would know I have a chance to help it.\n\nOf course, suggesting a pessimistic default that can result in suboptimal\nbut correct result would be a good thing to help the user help the build.\nI just think it is a good idea to tell the user we are giving such hint a\nbit more loudly to draw attention.\n"},{"id":"101222","messageId":"20090120065939.GC5561@ins.uni-bonn.de","threadId":"17191","inReplyTo":"7vab9mpu8w.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Provide pessimistic defaults for cross compilation tests.","fromName":"Ralf Wildenhues","fromEmail":"ralf.wildenhues@gmx.de","sentAt":"2009-01-20T06:59:39Z","receivedAt":"2009-01-20T06:59:39Z","isPatch":true,"sender":{"key":"ralf.wildenhues@gmx.de","avatar":null},"body":"* Junio C Hamano wrote on Tue, Jan 20, 2009 at 03:49:03AM CET:\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> > How do you deal with the hardcoded limitation that uname_S is defined to \n> > be the output of \"uname -s\" on the _build_ system, and that quite a large \n> > part of the Makefile sets variables dependent on this?\n\nOh, up to now I have blissfully ignored cross-compilation issues in git\noutside of configure.ac.  :-)\n\n> > IOW are you certain that configure (with your patch) will override _all_ \n> > uname_S dependent settings?\n\nNo, I am certain they won't override them at all.\n\nFixing Makefile will be more (but independent) work.  All I did was get\nconfigure.ac in shape to not error out in the face of cross compilation.\n\n> It may be a valid question but it is not limited to cross compilation, is\n> it?  The matter is if values the Makefile wants to default to can be\n> overriden by whatever is placed in config.mak, and as long as that is Ok\n> we won't have a problem with or without use of configure (which is a\n> second class citizen).\n\nYeah, I figured that.  I assume it makes little sense to suggest adding\nAC_CANONICAL_HOST to configure.ac, letting config.{guess,sub} do their\njob, and the user to use \"./configure --host=some-value\" to specify a\nhost alias, and then using the computed host triple to decide features,\nwithout the need to modify Makefile or other input files.\n\nSee, in a way I come from the GNU world here, and that's what I know\nbest.  Since git does its own setup here, I trust you will invent some\nway to solve this.\n\nThanks,\nRalf\n"},{"id":"101227","messageId":"20090120070451.GD5561@ins.uni-bonn.de","threadId":"17191","inReplyTo":"7v63kampwz.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Provide pessimistic defaults for cross compilation tests.","fromName":"Ralf Wildenhues","fromEmail":"ralf.wildenhues@gmx.de","sentAt":"2009-01-20T07:04:52Z","receivedAt":"2009-01-20T07:04:52Z","isPatch":true,"sender":{"key":"ralf.wildenhues@gmx.de","avatar":null},"body":"* Junio C Hamano wrote on Tue, Jan 20, 2009 at 07:50:52AM CET:\n> Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:\n> > --- a/configure.ac\n> > +++ b/configure.ac\n\n> > +\t[ac_cv_c_c99_format=no],\n\n> >  if test $ac_cv_c_c99_format = no; then\n> \n> This one probably is Ok, but...\n> \n> > @@ -380,6 +381,7 @@ AC_RUN_IFELSE(\n> >  \t\tFILE *f = fopen(\".\", \"r\");\n> >  \t\treturn f && fread(&c, 1, 1, f)]])],\n> >  \t[ac_cv_fread_reads_directories=no],\n> > +\t[ac_cv_fread_reads_directories=yes],\n> >  \t[ac_cv_fread_reads_directories=yes])\n> >  ])\n> >  if test $ac_cv_fread_reads_directories = yes; then\n> \n> I am not quite sure if this is an improvement ...\n> \n> > @@ -414,6 +416,7 @@ AC_RUN_IFELSE(\n> >  \t\t  if (snprintf(buf, 3, \"%s\", \"12345\") != 5\n> >  \t\t      || strcmp(buf, \"12\")) return 1]])],\n> >  \t[ac_cv_snprintf_returns_bogus=no],\n> > +\t[ac_cv_snprintf_returns_bogus=yes],\n> >  \t[ac_cv_snprintf_returns_bogus=yes])\n> >  ])\n> >  if test $ac_cv_snprintf_returns_bogus = yes; then\n> \n> ... nor this one.\n\nI can see why you're cautious here, but AFAICS the actual code that will\nbe enabled by these defaults is portable to systems that have no bogus\nsnprintf and whose fread does not read directories.  IOW, all you lose\nis a bit of performance at most.\n\n> Is there a way to say something like \"I'll autodetect as much as I can\n> without running tests, but please tell me these characteristics of the\n> target system manually\" and leave the resulting config.mak.autogen in a\n> shape that will guarantee compilation failure until the missing ones are\n> supplied by config.mak?\n\nWell, without my patch, each of these three tests will get configure to\nerror out.  Instead of setting a variable, these added arguments can\nalso output a more helpful error, in the sense of\n  \"please find out whether the return value of snprintf is ok,\n   and set $ac_cv_snprintf_returns_bogus accordingly when rerunning\n   configure\"\n\n> The thing is, I am not convinced that it is desirable to be able to build\n> a possibly suboptimal binary in a cross compilation environment, without\n> being told in what aspect of the resulting binary is suboptimal.  I'd\n> rather see a build system that honestly tells me what information it needs\n> but couldn't find, so that I would know I have a chance to help it.\n\nSure.\n\n> Of course, suggesting a pessimistic default that can result in suboptimal\n> but correct result would be a good thing to help the user help the build.\n> I just think it is a good idea to tell the user we are giving such hint a\n> bit more loudly to draw attention.\n\nAgreed, too.  Would you prefer a hard erroring out of configure, for\neach of the tests, or would it suffice to see a warning fly by?\n\nThanks,\nRalf\n"}]}