[package] m4/1.4.19: Runtime assertion windows pops up on MSVC in Debug mode

[jmarrec]

Package and Environment Details (include every applicable attribute)

• Package Name/Version: m4/1.4.19
• Operating System+version: Windows 10
• Compiler+version: MSVC 2017, 2019 in DEBUG
• Conan version: conan 1.44.0
• Python version: Python 3.9.5

I have a recipe that depends on bison. 3.7.6 gives me parse errors, so I keep it at 3.7.1. I had pinned the exact bison/3.7.1 recipe and all worked well. I am trying to update my dependencies, so I tried the newest bison/3.7.1 revision, and I am now getting an assertion popup in m4.

I have tried various combinations to see if I could pinpoint what changed. My conclusion is that it's the move from m4/1.4.18 to m4/1.4.19 (I have tried the newest recipe revision of m4/1.4.18 and it worked, and the only m4/1.4.19 available fails).

        # Latest bison/3.7.1 with m4/1.4.18
        #self.build_requires("bison/3.7.1#dcffa3dd9204cb79ac7ca09a7f19bb8b") #  Works

        # First bison/3.7.1 with m4/1.4.19
        self.build_requires("bison/3.7.1#47f49e709ddb9f8e055471c4e3c4e67d"): # Fails

        # Latest bison/3.7.1
        #self.build_requires("bison/3.7.1#ad29e804e82c8b6d58765096676b5a5e") # Fails

Conan profile (output of conan profile show default or conan profile show <profile> if custom profile is in use)

[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug
compiler=Visual Studio
compiler.runtime=MDd
compiler.version=16
os=Windows
os_build=Windows
[options]
[build_requires]
[env]

Steps to reproduce (Include if Applicable)

git clone git@github.com:NREL/conan-openstudio-ruby.git
git checkout update_ruby_installer_and_remotes

'C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat' x64

conan create . openstudio_ruby/2.7.2@nrel/testing -b missing -b openstudio_ruby -s build_type=Debug

Logs (Include/Attach if Applicable)

Example of a failed run: https://github.com/NREL/conan-openstudio-ruby/runs/4787415523?check_suite_focus=true

[jmarrec]

@madebr is this "reb" on purpose?

conan-center-index/recipes/m4/all/patches/1.4.19-0001-open-files-in-binary-mode.patch

Line 12 in cd61e7b

+ FILE *fp = fopen (file, "reb");

The 1.4.18 version has "rb" (which is familar to me, unlike reb...):

conan-center-index/recipes/m4/all/patches/1.4.18-0008-open-files-in-binary-mode.patch

Line 12 in cd61e7b

+ FILE *fp = fopen (file, "rb");

[madebr]

The patch is adding 'b' (it is already "re").
It looks like it is a GNU extension:

       e (since glibc 2.7)
              Open  the  file with the O_CLOEXEC flag.  See open(2) for more information.  This flag is ignored for
              fdopen().

The problem you're seeing with debug 2019 is probably the same we saw when adding m4/1.4.19.
See #7369 for our analysis at that time.

We have a short reproducer.

I don't remember why we didn't patch out the _close of fclose.

[jmarrec]

I just got the same issue building bison/3.7.6 in debug FYI

[madebr]

The problem is with m4. The bison version is kinda irrelevant.
m4 is only used as a build requirement since it provides no library.
I think you can work around the problem by adding -s:b m4:build_type=Release.

[jmarrec]

I'd like to do that, but unfortunately all my attemps of forcing the build_requires to be in Release mode failed when using CPT and docker (locally it works plently fine if I issue the conan create command manually)

conan-io/conan-package-tools#595 (comment)

[SSE4]

@jmarrec have you already tried asking in m4 mail list, as it was discussed in #7369? it seems like there is no configure option to bypass the check, and proper fix may require to patch m4 sources.

[jmarrec]

Both jmarrec@9c7fa44 and jmarrec@d5e6472 when built locally allow me to build bison/3.7.6 (both in debug) without the popup

[jmarrec]

Not sure which solution we prefer. Perhaps combining them both actually...

[SSE4]

jmarrec/conan-center-index@d5e6472

I personally prefer jmarrec@d5e6472, as it doesn't require patching sources

[jmarrec]

I'm less certain that this HAVE_MSVC_INVALID_PARAMETER_HANDLER actually fixes it in all cases though. And you wrote on #7369 (comment)

I see in m4 code they install some custom invalid parameter handler (HAVE_MSVC_INVALID_PARAMETER_HANDLER), but it doesn't seem to help...

[jmarrec]

It does seem to work. I'll open a PR

[jmarrec]

Cf PR #8984