[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Assertion error when building in Debug mode with MSVC

From: Julien Marrec
Subject: Re: Assertion error when building in Debug mode with MSVC
Date: Mon, 31 Jan 2022 09:09:12 +0100

Thank you both.

I'll try the patch to see if it changes anything. The conan recipe pulls from https://ftp.gnu.org/gnu/m4/m4-1.4.19.tar.gz and I suppose that's preconfigured sources or something, so I need to figure out how to get to that point from the sources already.

If you wanted to actually shut these dialog box, I think you need `_CrtSetReportMode`. This proposed patch on my PR to conan-center-index does that early in main() (in m4.c) and will not display the dialog box, instead it prints to the console.  https://github.com/conan-io/conan-center-index/pull/8984/files#diff-ccc0213dad321989f54ebce565d4f15fad8e8010d9fa47a09ef1e007e87083bf

As far as the 'n' format specifier and co, see how the conan recipe works around it when MSVC is used here: https://github.com/conan-io/conan-center-index/blob/051d449332db77854cf56650d2c92dff8a207d9b/recipes/m4/all/conanfile.py#L54-L61 Basically it passes conf args `["gl_cv_func_printf_directive_n=no", "gl_cv_func_snprintf_directive_n=no", "gl_cv_func_snprintf_directive_n=no"]`. Perhaps you could default the same directly when MSVC is encountered?

Julien Marrec, EBCP, BPI MFBA
Owner at EffiBEM
T: +33 6 95 14 42 13

LinkedIn (en) | (fr) :

Le dim. 30 janv. 2022 à 00:51, Bruno Haible <bruno@clisp.org> a écrit :
Paul Eggert wrote:
> I installed the attached patch into Gnulib and propagated this into m4
> on Savannah so it should appear in the next m4 release.

The patch is fine. In the case of the GNU m4 binary, however, it has no
effect, since the module 'fclose' is used for m4 already since 2011-02-05.
Even with libm4_a-fclose.obj compiled in, "./m4.exe --version" (compiled
with '-MDd') still presents an dialog
  "Debug Assertion Failed!
   File: minkernel\crts\ucrt\src\appcrt\lowio\close.cpp
   Line: 49
   _expression_: (_osfile(fh) & FOPEN)"
three times.

> In the meantime you can build with /MD instead of /MDd.

Yes, exactly, that's the solution. There's no point for us in trying
to handle debug assertions in the Microsoft debug libraries,
when we already handle them in the source code and the only reason
you see dialogs is that in 'Debug' mode these dialogs appear *even though*
we have installed handlers.

Other such dialogs that I see (during configure, in 'Debug' mode only) are:
  _expression_: ("'n' format specifier disabled", 0)
  _expression_: ("Invalid file open mode", 0)


2022-01-29  Bruno Haible  <bruno@clisp.org>

        doc: Clarify MSVC support.
        * doc/gnulib-intro.texi (Supported Platforms): Document that "debug"
        builds are unsupported.

diff --git a/doc/gnulib-intro.texi b/doc/gnulib-intro.texi
index 049c8ab3d7..a80c0995f5 100644
--- a/doc/gnulib-intro.texi
+++ b/doc/gnulib-intro.texi
@@ -158,7 +158,8 @@ GNU Hurd 0.7 is rarely tested.
 Native Windows, with MSVC as compiler, is rarely tested and low priority.
 The versions of MSVC that are supported are MSVC 14 (Visual Studio 2015) or
+newer.  Furthermore only ``release'' builds (compiler option @samp{-MD}) are
+supported, not ``debug'' builds (compiler option @samp{-MDd}).
 @c There is musl-gcc on Ubuntu, and Alpine Linux 3.3.3.
 musl libc is rarely tested.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]