What's the config.log output for these tests using the standard configure script?

Also, we would need a patch to configure.ac, not a "modified configure script".

Created attachment 266309 [details]
Failed Build config.log

../../../../repos/src/libqof/qof/guid.c: In function 'init_from_file':
../../../../repos/src/libqof/qof/guid.c:243:5: error: unknown conversion type character 'l' in format
../../../../repos/src/libqof/qof/guid.c:243:5: error: format '%s' expects type 'char *', but argument 5 has type 'long long unsigned int'
../../../../repos/src/libqof/qof/guid.c:243:5: error: too many arguments for format
../../../../repos/src/libqof/qof/guid.c: In function 'guid_init':
../../../../repos/src/libqof/qof/guid.c:510:5: error: unknown conversion type character 'l' in format
../../../../repos/src/libqof/qof/guid.c:510:5: error: too many arguments for format
../../../../repos/src/libqof/qof/guid.c:513:9: error: unknown conversion type character 'l' in format
../../../../repos/src/libqof/qof/guid.c:513:9: error: too many arguments for format

That's a well-known MinGW problem [1]. Make sure that 

-D__USE_MINGW_ANSI_STDIO is in CXXFLAGS.

[1]https://sourceforge.net/mailarchive/forum.php?thread_name=4F893862.1060206%40users.sourceforge.net&forum_name=mingw-w64-public

(In reply to comment #3)
> That's a well-known MinGW problem [1]. Make sure that 
> 
> -D__USE_MINGW_ANSI_STDIO is in CXXFLAGS.
> 
> [1]https://sourceforge.net/mailarchive/forum.php?thread_name=4F893862.1060206%40users.sourceforge.net&forum_name=mingw-w64-public

Thanks for the tip.  I'm not a developer for Gnucash, just a hobbyist.  I would prefer that the Gnucash developers fix this so all I must do is use the Gnucash Install.sh script, letting the build system decide the correct options for my machine.

I agree.  I think that if this flag is required in the windows build then we should make sure our win32 build scripts supply the flag.  Therefore I have reopened the bug.

I've pushed f954865 to maint, which sets __USE_MINGW_ANSI_STDIO if compiling "printf("%lld", 3); fails. At the moment, both my Win7 build environments work without setting that flag so I can't be sure that it's working. Please test it.

Created attachment 277629 [details]
Attempted install.sh 5/31/2014

Install.sh failed with gnucash-2.6.99-2014-05-31-git-81fb773+

No errors? That's really strange. Is this a tarball you downloaded from GitHub?
Was there an error dialog or any other indication why it stopped?

Besides, it's the wrong commit. You need f9548652 from the maint branch.

I can't seem to capture the entire build process with (install.sh |tee <file>), the <file> gets truncated.  It still fails because configure is setting up scanf %lld conversions, but this fails to compile. I was building the Master.

When I build using the Maintenance branch, configure still sets up scanf %lld conversions(tail end of failure):

/bin/sh ../../../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../../../repos/src/libqof/qof -I../../..  -I../../../../repos/lib
/libc -I../../../../repos/src -mms-bitfields -Id:/gnusoft/gnome/include/glib-2.0 -Id:/gnusoft/gnome/lib/glib-2.0/include   -DG_LOG_DOMAIN=\"qof\"
 -I/D/gnusoft/autotools/include -I/D/gnusoft/regex/include -I/D/gnusoft/gnome/include -I/D/gnusoft/gmp/include -I/D/gnusoft/guile/include -I/D/gn
usoft/libdbi/include -I/D/gnusoft/gwenhywfar/include -I/D/gnusoft/hh/include -mms-bitfields -Id:/gnusoft/libsoup/include/libsoup-2.4 -Id:/gnusoft
/gnome/include/libxml2 -Id:/gnusoft/gnome/include/glib-2.0 -Id:/gnusoft/gnome/lib/glib-2.0/include   -D_WIN32   -Werror -Wdeclaration-after-state
ment -Wno-pointer-sign -D_FORTIFY_SOURCE=2 -g  -mms-bitfields -g  -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations  -Wno-unused -MT gui
d.lo -MD -MP -MF .deps/guid.Tpo -c -o guid.lo ../../../../repos/src/libqof/qof/guid.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../../../repos/src/libqof/qof -I../../.. -I../../../../repos/lib/libc -I../../../../repos/src -mm
s-bitfields -Id:/gnusoft/gnome/include/glib-2.0 -Id:/gnusoft/gnome/lib/glib-2.0/include -DG_LOG_DOMAIN=\"qof\" -I/D/gnusoft/autotools/include -I/
D/gnusoft/regex/include -I/D/gnusoft/gnome/include -I/D/gnusoft/gmp/include -I/D/gnusoft/guile/include -I/D/gnusoft/libdbi/include -I/D/gnusoft/g
wenhywfar/include -I/D/gnusoft/hh/include -mms-bitfields -Id:/gnusoft/libsoup/include/libsoup-2.4 -Id:/gnusoft/gnome/include/libxml2 -Id:/gnusoft
/gnome/include/glib-2.0 -Id:/gnusoft/gnome/lib/glib-2.0/include -D_WIN32 -Werror -Wdeclaration-after-statement -Wno-pointer-sign -D_FORTIFY_SOURC
E=2 -g -mms-bitfields -g -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wno-unused -MT guid.lo -MD -MP -MF .deps/guid.Tpo -c ../../.
./../repos/src/libqof/qof/guid.c  -DDLL_EXPORT -DPIC -o .libs/guid.o
cc1.exe: warnings being treated as errors
../../../../repos/src/libqof/qof/guid.c: In function 'init_from_file':
../../../../repos/src/libqof/qof/guid.c:250:5: error: unknown conversion type character 'l' in format
../../../../repos/src/libqof/qof/guid.c:250:5: error: format '%s' expects type 'char *', but argument 5 has type 'long long unsigned int'
../../../../repos/src/libqof/qof/guid.c:250:5: error: too many arguments for format
../../../../repos/src/libqof/qof/guid.c: In function 'guid_init':
../../../../repos/src/libqof/qof/guid.c:517:5: error: unknown conversion type character 'l' in format
../../../../repos/src/libqof/qof/guid.c:517:5: error: too many arguments for format
../../../../repos/src/libqof/qof/guid.c:520:9: error: unknown conversion type character 'l' in format
../../../../repos/src/libqof/qof/guid.c:520:9: error: too many arguments for format
make[5]: *** [guid.lo] Error 1
make[5]: Leaving directory `/D/gnusoft/gnucash/build/src/libqof/qof'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/D/gnusoft/gnucash/build/src/libqof/qof'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/D/gnusoft/gnucash/build/src/libqof'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/D/gnusoft/gnucash/build/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/D/gnusoft/gnucash/build'
make: *** [all] Error 2

Created attachment 277678 [details]
06/01/2014 Configure of Maint branch

Created attachment 277679 [details]
06/01/2014 config.log built using maint branch

Can you look in config.h and make sure that the 
#define __USE_MINGW_ANSI_STDIO 1
line is there?

I do not see #define __USE_MINGW_ANSI_STDIO 1 in either the makefile or config.h

I cloned the git maint repository to build from.  But I'm not sure that includes your fix.

if I insert #define __USE_MINGW_ANSI_STDIO 1 in config.h, make still fails

if I insert __USE_MINGW_ANSI_STDIO=1 in makefile, make still fails

There's no "maint" repository. This is git: http://wiki.gnucash.org/wiki/Git 

However, the "configure" that you posted does include the directive, so you built the right version, it just seems not to have worked. I just pushed a change that should get it to work.

You can't edit the files in the build directory and re-run install.sh: They just get overwritten.

Updated my repository.  configure.ac changed.  but make still fails the same way.

config.h has the following at the end:

/* MinGW needs ANSI_STDIO hack. */
/* #undef __USE_MINGW_ANSI_STDIO */

Install.sh with master branch:
Fails as original.
Change directory to build
Inserted #define __USE_MINGW_ANSI_STDIO 1 in config.h
manual make fails as follows:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../../../master/src/backend/xml -I../../.. -I.. -I../.. -DLOCALE_DIR=\"D:/gnusoft/gnucash/inst/sh
are/locale\" -I../../../../master/src/backend -I../../../../master/src/engine -I../../../../master/src/core-utils -I../../../../master/src/gnc-mo
dule -I../../../../master/lib/libc -I../../../../master/src/libqof/qof -I../../../../master/src -Id:/gnusoft/gnome/include/libxml2 -mms-bitfields
 -Id:/gnusoft/gnome/include/glib-2.0 -Id:/gnusoft/gnome/lib/glib-2.0/include -DG_LOG_DOMAIN=\"gnc.backend.xml\" -I/D/gnusoft/autotools/include -I
/D/gnusoft/regex/include -I/D/gnusoft/gnome/include -I/D/gnusoft/gmp/include -I/D/gnusoft/guile/include -I/D/gnusoft/libdbi/include -I/D/gnusoft/
gwenhywfar/include -I/D/gnusoft/hh/include -mms-bitfields -Id:/gnusoft/libsoup/include/libsoup-2.4 -Id:/gnusoft/gnome/include/libxml2 -Id:/gnusof
t/gnome/include/glib-2.0 -Id:/gnusoft/gnome/lib/glib-2.0/include -D__USE_MINGW_ANSI_STDIO -D_WIN32 -Werror -Wdeclaration-after-statement -Wno-poi
nter-sign -D_FORTIFY_SOURCE=2 -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -Wno-unused -g -mms-bitfields -g -MT sixtp-utils.lo -MD
-MP -MF .deps/sixtp-utils.Tpo -c ../../../../master/src/backend/xml/sixtp-utils.c  -DDLL_EXPORT -DPIC -o .libs/sixtp-utils.o
cc1.exe: warnings being treated as errors
../../../../master/src/backend/xml/sixtp-utils.c: In function 'string_to_gint64':
../../../../master/src/backend/xml/sixtp-utils.c:175:5: error: unknown conversion type character 'l' in format
../../../../master/src/backend/xml/sixtp-utils.c:175:5: error: format '%n' expects type 'int *', but argument 3 has type 'long long int *'
../../../../master/src/backend/xml/sixtp-utils.c:175:5: error: too many arguments for format
make[5]: *** [sixtp-utils.lo] Error 1
make[5]: Leaving directory `/d/gnusoft/gnucash/build/src/backend/xml'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/d/gnusoft/gnucash/build/src/backend/xml'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/d/gnusoft/gnucash/build/src/backend'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/d/gnusoft/gnucash/build/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/d/gnusoft/gnucash/build'
make: *** [all] Error 2

Is there any reason we just don't use G_INT64_FORMAT?
There's no reason we should need to test for this in configure.
I think it's safe to assume that printf() and scanf() use the same tokens.

(In reply to comment #18)
> Is there any reason we just don't use G_INT64_FORMAT?
> There's no reason we should need to test for this in configure.
> I think it's safe to assume that printf() and scanf() use the same tokens.

I don't know about G_INT64_FORMAT.

Configure falsely sets scanf format to %lld.  but it should be $I64d.  The build will fail with %lld but succeeds with %I64D.

I noticed that the nightly builds use HAVE_SCANF_I64D.

There must be a way so that install.sh sets this up as an option.

(In reply to comment #18)
> Is there any reason we just don't use G_INT64_FORMAT?
> There's no reason we should need to test for this in configure.
> I think it's safe to assume that printf() and scanf() use the same tokens.

If I alter configure.ac, install.sh will compile without errors:

configure.ac change:

SCANF_LLD_CHECK
if test x$am_cv_scanf_lld = "xno"; then
  SCANF_QD_CHECK

  if test x$am_cv_scanf_qd = "xno"; then
    SCANF_I64D_CHECK
    if test x$am_cv_scanf_i64d = "xno"; then
      AC_MSG_ERROR([Cannot continue, no long long conversion support in scanf.])
    fi
  fi
fi

to:
   SCANF_I64D_CHECK
   if test x$am_cv_scanf_i64d = "xno"; then
     AC_MSG_ERROR([Cannot continue, no long long conversion support in scanf.])
   fi

(In reply to comment #18)
> Is there any reason we just don't use G_INT64_FORMAT?
> There's no reason we should need to test for this in configure.
> I think it's safe to assume that printf() and scanf() use the same tokens.

G_GINT64_FORMAT, but yeah, that's what we do everywhere else except where we use QOF_SCANF_LLD, which has a note at its definition (in qof-utils.h) that it shouldn't be used for printf.

I've got a change to do that in guid.c testing now.

(In reply to comment #20)
> (In reply to comment #18)
> > Is there any reason we just don't use G_INT64_FORMAT?
> > There's no reason we should need to test for this in configure.
> > I think it's safe to assume that printf() and scanf() use the same tokens.
> 
> If I alter configure.ac, install.sh will compile without errors:

So the problem is at least in part that in your build environment both SCANF_LLD_CHECK and SCANF_I64D_CHECK return true, and the former check is wrong.
I guess that should have been obvious to me from your earlier posts. It is now that I've re-read them.

See if adding this:
--- a/macros/legacy_macros.m4
+++ b/macros/legacy_macros.m4
@@ -117,6 +117,7 @@ int main ()
   if ((sscanf ("10000000000", "%lld", &d) != 1) || (d != e))
     exit (1);
 
+  printf("%lld\n", d);
   exit (0);
 }
 ],

gets that check to fail.

I've also just pushed the change to guid.c for G_GUINT64_FORMAT, but that won't fix the failure in sixtp-utils.c.

(In reply to comment #22)
> (In reply to comment #20)
> > (In reply to comment #18)
> > > Is there any reason we just don't use G_INT64_FORMAT?
> > > There's no reason we should need to test for this in configure.
> > > I think it's safe to assume that printf() and scanf() use the same tokens.
> > 
> > If I alter configure.ac, install.sh will compile without errors:
> 
> So the problem is at least in part that in your build environment both
> SCANF_LLD_CHECK and SCANF_I64D_CHECK return true, and the former check is
> wrong.
> I guess that should have been obvious to me from your earlier posts. It is now
> that I've re-read them.
> 
> See if adding this:
> --- a/macros/legacy_macros.m4
> +++ b/macros/legacy_macros.m4
> @@ -117,6 +117,7 @@ int main ()
>    if ((sscanf ("10000000000", "%lld", &d) != 1) || (d != e))
>      exit (1);
> 
> +  printf("%lld\n", d);
>    exit (0);
>  }
>  ],
> 
> gets that check to fail.
> 
> I've also just pushed the change to guid.c for G_GUINT64_FORMAT, but that won't
> fix the failure in sixtp-utils.c.

The macro fails if I exit with 1, not 0:

see the attached config.log excerpt...

Created attachment 277795 [details]
legacy_macros.m4 changes for scanf-lld  config.log

(In reply to comment #22)
> (In reply to comment #20)
> > (In reply to comment #18)
> > > Is there any reason we just don't use G_INT64_FORMAT?
> > > There's no reason we should need to test for this in configure.
> > > I think it's safe to assume that printf() and scanf() use the same tokens.
> > 
> > If I alter configure.ac, install.sh will compile without errors:
> 
> So the problem is at least in part that in your build environment both
> SCANF_LLD_CHECK and SCANF_I64D_CHECK return true, and the former check is
> wrong.
> I guess that should have been obvious to me from your earlier posts. It is now
> that I've re-read them.
> 
> See if adding this:
> --- a/macros/legacy_macros.m4
> +++ b/macros/legacy_macros.m4
> @@ -117,6 +117,7 @@ int main ()
>    if ((sscanf ("10000000000", "%lld", &d) != 1) || (d != e))
>      exit (1);
> 
> +  printf("%lld\n", d);
>    exit (0);
>  }
>  ],
> 
> gets that check to fail.
> 
> I've also just pushed the change to guid.c for G_GUINT64_FORMAT, but that won't
> fix the failure in sixtp-utils.c.

When I compile the config-sscanf-lld test manually(gcc test.c) it succeeds.
When I compile the config-sscanf-lld test namually(gcc -Wall -Werror it fails.
The actual configure test does not treat warnings as errors, whereas the actual build does treat warnings as errors and then fails whenever "scanf-lld" is used.

Thought so. Try this:
--- configure.ac	Tue Oct  1 08:56:00 2013
+++ configure.ac	Tue Jun  3 07:33:33 2014
@@ -162,6 +162,8 @@
 ])
 
 STRUCT_TM_GMTOFF_CHECK
+cflags_save=${CFLAGS}
+CFLAGS="${CFLAGS} -Wall -Werror"
 SCANF_LLD_CHECK
 if test x$am_cv_scanf_lld = "xno"; then
   SCANF_QD_CHECK
@@ -173,6 +175,7 @@
     fi
   fi
 fi
+CFLAGS="${cflags_save}"
 
 # test whether we are building directly from svn/svk/git/bzr
 AC_MSG_CHECKING(if building from an scm managed directory)

(In reply to comment #26)
> Thought so. Try this:
> --- configure.ac    Tue Oct  1 08:56:00 2013
> +++ configure.ac    Tue Jun  3 07:33:33 2014
> @@ -162,6 +162,8 @@
>  ])
> 
>  STRUCT_TM_GMTOFF_CHECK
> +cflags_save=${CFLAGS}
> +CFLAGS="${CFLAGS} -Wall -Werror"
>  SCANF_LLD_CHECK
>  if test x$am_cv_scanf_lld = "xno"; then
>    SCANF_QD_CHECK
> @@ -173,6 +175,7 @@
>      fi
>    fi
>  fi
> +CFLAGS="${cflags_save}"
> 
>  # test whether we are building directly from svn/svk/git/bzr
>  AC_MSG_CHECKING(if building from an scm managed directory)

Yes, your change in configure.ac causes scanf_lld and scanf_qd to fail. Scanf_I64d passes.

checking if scanf supports %lld conversions... no
checking if scanf supports %qd conversions... no
checking if scanf supports %I64d conversions... yes

I believe that the real problem is with GCC itself.  
sscanf_lld is working correctly, but GCC falsely generates warnings
(unknown conversion type character 'l' in format)
(too many arguments for format)

If I compile and run the sscanf_lld test, I get the correct results.
(sscanf-lld-succeeded: d=10000000000, e=10000000000)

So we should really keep the original sscanf_lld test, but get GCC fixed so that it doesn't falsely warn about %lld.

I don't think that it's actually GCC's fault. The MinGW folks claim that the problem is in the rather ancient msvcrt.dll that they use to ensure compatibility across Windows versions and that there's not anything that they can do about it beyond the __USE_MINGW_ANSI_STDIO hack. It's likely that hack that causes the behavior you see: After all, the format parser is already compiled so it doesn't know whether that macro is defined or not and has to parse "%lld" either way. 
all the macro can do is disable a compile-time check of the format parameters.

Forcing the use of %I64d on M$ platforms is certainly harmless. GLib does it based on the MS-defined _MSC_VER macro -- if it's defined, G_GINT64_FORMAT is %I64d, no testing.

I'll push that change soon, and close this bug.

This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.
8ac8c70 on maint branch.

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=722200. Please update any external references or bookmarks.