After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 722200 - configure script does not pick the correct am_cv_scanf version on 64-bit Windows system
configure script does not pick the correct am_cv_scanf version on 64-bit Wind...
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Build system
unspecified
Other Windows
: Normal normal
: ---
Assigned To: gnucash-core-maint
gnucash-core-maint
Depends on:
Blocks:
 
 
Reported: 2014-01-14 17:57 UTC by Rich
Modified: 2018-06-29 23:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
configure script with about additions. (1020.92 KB, application/octet-stream)
2014-01-14 17:57 UTC, Rich
Details
Failed Build config.log (245.04 KB, text/plain)
2014-01-14 23:38 UTC, Rich
Details
Attempted install.sh 5/31/2014 (363.02 KB, text/plain)
2014-05-31 18:33 UTC, Rich
Details
06/01/2014 Configure of Maint branch (1.00 MB, text/plain)
2014-06-01 12:40 UTC, Rich
Details
06/01/2014 config.log built using maint branch (245.49 KB, text/plain)
2014-06-01 12:42 UTC, Rich
Details
legacy_macros.m4 changes for scanf-lld config.log (6.00 KB, text/plain)
2014-06-03 12:44 UTC, Rich
Details

Description Rich 2014-01-14 17:57:40 UTC
Created attachment 266283 [details]
configure script with about additions.

You must manually edit the configure script adding:

am_cv_scanf_i64d=yes
am_cv_scanf_lld=no
am_cv_scanf_qd=no

Once these lines are added at the correct spot in the configure script, the build completes without failure.
Comment 1 Derek Atkins 2014-01-14 18:07:06 UTC
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".
Comment 2 Rich 2014-01-14 23:38:50 UTC
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
Comment 3 John Ralls 2014-01-15 00:35:29 UTC
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
Comment 4 Rich 2014-01-15 11:28:50 UTC
(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.
Comment 5 Derek Atkins 2014-01-15 15:57:31 UTC
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.
Comment 6 John Ralls 2014-05-31 16:27:58 UTC
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.
Comment 7 Rich 2014-05-31 18:33:00 UTC
Created attachment 277629 [details]
Attempted install.sh 5/31/2014

Install.sh failed with gnucash-2.6.99-2014-05-31-git-81fb773+
Comment 8 John Ralls 2014-05-31 19:40:52 UTC
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.
Comment 9 Rich 2014-06-01 12:36:46 UTC
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
Comment 10 Rich 2014-06-01 12:40:35 UTC
Created attachment 277678 [details]
06/01/2014 Configure of Maint branch
Comment 11 Rich 2014-06-01 12:42:14 UTC
Created attachment 277679 [details]
06/01/2014 config.log built using maint branch
Comment 12 John Ralls 2014-06-01 14:10:40 UTC
Can you look in config.h and make sure that the 
#define __USE_MINGW_ANSI_STDIO 1
line is there?
Comment 13 Rich 2014-06-01 17:38:08 UTC
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.
Comment 14 Rich 2014-06-01 18:23:48 UTC
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
Comment 15 John Ralls 2014-06-01 18:48:18 UTC
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.
Comment 16 Rich 2014-06-01 19:17:23 UTC
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 */
Comment 17 Rich 2014-06-01 21:14:27 UTC
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
Comment 18 Derek Atkins 2014-06-02 15:42:49 UTC
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.
Comment 19 Rich 2014-06-02 20:37:09 UTC
(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.
Comment 20 Rich 2014-06-02 21:09:20 UTC
(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
Comment 21 John Ralls 2014-06-02 21:16:58 UTC
(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.
Comment 22 John Ralls 2014-06-03 00:40:52 UTC
(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.
Comment 23 Rich 2014-06-03 12:42:08 UTC
(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...
Comment 24 Rich 2014-06-03 12:44:28 UTC
Created attachment 277795 [details]
legacy_macros.m4 changes for scanf-lld  config.log
Comment 25 Rich 2014-06-03 14:36:36 UTC
(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.
Comment 26 John Ralls 2014-06-03 14:40:56 UTC
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)
Comment 27 Rich 2014-06-03 16:23:05 UTC
(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.
Comment 28 John Ralls 2014-06-03 17:09:26 UTC
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.
Comment 29 John Ralls 2014-06-03 18:32:22 UTC
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.
Comment 30 John Ralls 2018-06-29 23:24:48 UTC
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.