#14 MATIO Compilation Error on MinGW (vasprintf not found)

[Anonymous]

Originally created by: wissem01chiha
Originally owned by: wissem01chiha

Original Isuse https://github.com/tbeu/matio/issues/326

[Anonymous]

• assigned_to: wissem01chiha

[Anonymous]

Originally posted by: wissem01chiha

fixed with a workaround, but need more in depth, as matio not yet used in codebase, it can wait

[Anonymous]

Originally posted by: tbeu

I dug into this and believe I found the root cause. It is a CMake cache collision between json-c and matio, specific to MinGW:

1. json-c's CMakeLists.txt runs list(APPEND CMAKE_REQUIRED_DEFINITIONS -D_GNU_SOURCE) and then check_symbol_exists(vasprintf stdio.h HAVE_VASPRINTF).
2. With _GNU_SOURCE defined, mingw-w64's stdio.h declares vasprintf (redirected via __MINGW_ASM_CALL to __mingw_vasprintf from libmingwex), so json-c's check succeeds and stores HAVE_VASPRINTF=1 in the shared top-level CMake cache.
3. matio's own check_symbol_exists(vasprintf stdio.h HAVE_VASPRINTF) (cmake/compilerOptions.cmake) then sees the cache variable already defined and skips the check entirely, so matio inherits HAVE_VASPRINTF=1 without _GNU_SOURCE being defined for its compilation units.
4. Since mingw-w64 does not declare vasprintf without _GNU_SOURCE, the call at snprintf/snprintf.c:1453 inside rpl_asprintf fails with implicit declaration of function 'vasprintf'. (HAVE_ASPRINTF is correctly not detected, so rpl_asprintf is compiled.)

So it is an interaction between json-c's CMAKE_REQUIRED_DEFINITIONS and CMake's per-variable global check cache, and it only manifests on MinGW because mingw-w64 hides vasprintf behind _GNU_SOURCE. matio is tracking this upstream in tbeu/matio#326 (a CI reproduction was added there): https://github.com/tbeu/matio/actions/runs/30849805719/job/91806795254

[Anonymous]

Originally posted by: wissem01chiha

Ah , Thanks very much @tbeu , i got it now, i though that was a nasty mix of cmake configuration flags , but didn't resolve the root cause, that explain lot of things, thanks for your time and, for adding the CI checks in MATIO

[Anonymous]

Originally posted by: wissem01chiha

does it seem logical to repost this in json-c repository, and fix it there ?

[Anonymous]

Originally posted by: wissem01chiha

thanks for forking my project @tbeu , however it still in early implementation phase an i am changing a lot in the API and design as well as build scripts and CI

[Anonymous]

Originally posted by: tbeu

Well, if you remove your workaround and swap configuration such that matio is configured before json-c, you get build errors for json-c, because json-c's fallback static vasprintf conflicts with its own _GNU_SOURCE declaration.

So there is no ordering that works with the current cache behavior:

• json-c first: matio fails
• matio first: json-c fails

I have a workaound ready for matio to unset the cached variables, but it only hides the issue. Hence, I am reluctant to push.

[Anonymous]

Originally posted by: wissem01chiha

Hi , ok no problem , honestly i would touch MATIO at this level , i am planning to fix if i dig more in json-c library build script logic , or replace the hole json-c with more modern third-party that throw away this , however this is not my first issue which related to json-c , it caused me pain in past , i will find a solution , anyway,
thanks very much @tbeu for your time , your project was a source of inspiration for me

[Anonymous]

Originally posted by: wissem01chiha

if i find a clean solution , i will came back here and post it 😁