Installation Problem, JSON requirements | Windows

Hi all

Following the current installation guidelines on Windows, I run in to troubles with the “JSON for Modern C++” requirement during config:

MRtrix build type requested: release

Detecting OS: windows
Looking for compiler [g++]: g++.exe (Rev1, Built by MSYS2 project) 7.3.0
Checking for C++11 compliance: ok
Checking shared library generation: ok
Detecting pointer size: 64 bit
Detecting byte order: little-endian
Checking for variable-length array support: ok
Checking for non-POD variable-length array support: not found
Checking for ::max_align_t: 16 bytes
Checking for std::max_align_t: 16 bytes
Checking for Eigen3 library: 3.3.3
Checking for zlib compression library: 1.2.11
Checking for "JSON for Modern C++" requirements:
ERROR: runtime error!

   Unable to configure JSON for modern C++

  See the file 'configure.log' for details. If this doesn't help and you need
  further assistance, please post on the MRtrix3 community forum
  (, and make sure to include the full contents of
  the 'configure.log' file.

My MSYS2 is up to date an I ran all the commands from mingw64.exe. Here’s the error from the configure.log file:

REPORT: Checking for "JSON for Modern C++" requirements:

COMPILE /tmp/tmptzxt3pjq.cpp:

#include "file/json.h"
int main (int argc, char* argv[])
  nlohmann::json json;
  json["key"] = "value";

CMD: g++ -c -std=c++11 -pthread -DMRTRIX_WINDOWS -mms-bitfields -Wa,-mbig-obj -D_FILE_OFFSET_BITS=64 -DMRTRIX_WORD64 -DMRTRIX_NO_NON_POD_VLA -isystem /mingw64/include -I/home/admin/mrtrix3/core /tmp/tmptzxt3pjq.cpp -o /tmp/tmptzxt3pjq.o

CMD: g++ /tmp/tmptzxt3pjq.o -pthread -Wl,--allow-multiple-definition -L/mingw64/lib -lz -o a.out

CMD: ./a.out
EXIT: 127

ERROR: runtime error!
   Unable to configure JSON for modern C++

Did somebody encounter the same problem? Any ideas?

Thanks in advance



That’s unexpected… Maybe it’s because the test program doesn’t explicitly return an exit status. Can you try adding return 0; to configure at line 912, so it looks like this:

int main (int argc, char* argv[])
  nlohmann::json json;
  json["key"] = "value";
  return 0;

Then try ./configure again, see if that helps.

That makes sense, I actually ran ./a.out in the cmd to see if some error gets thrown, but no error. I‘ll try your suggestion and keep you updated!

Unfortunately it did not resolve the issue:

COMPILE /tmp/tmp_d0l5jg7.cpp:

#include "file/json.h"
int main (int argc, char* argv[])
  nlohmann::json json;
  json["key"] = "value";
  return 0;

CMD: g++ -c -std=c++11 -pthread -DMRTRIX_WINDOWS -mms-bitfields -Wa,-mbig-obj -D_FILE_OFFSET_BITS=64 -DMRTRIX_WORD64 -DMRTRIX_NO_NON_POD_VLA -isystem /mingw64/include -I/home/admin/mrtrix3/core /tmp/tmp_d0l5jg7.cpp -o /tmp/tmp_d0l5jg7.o

CMD: g++ /tmp/tmp_d0l5jg7.o -pthread -Wl,--allow-multiple-definition -L/mingw64/lib -lz -o a.out

CMD: ./a.out
EXIT: 127

ERROR: runtime error!

   Unable to configure JSON for modern C++

The runtime error must happend at line
nlohmann::json json;
if I move the return 0 in between the object creation and the value assignment, the check still fails. Not sure if this helps, but if I skip the json-Test by returning 0 straight away, I get another runtime error at the Qt application stage (configuration with -nogui works however if I skip the json Test).
I’ll happy to provide more information if it helps to resolve this issue.

I’ve not encountered this issue myself (yet), which unfortunately makes diagnosis difficult. But getting a subsequent runtime error at the Qt step also makes me suspicious of the compiler. Are you able to try with g++ version 5 or 6? (Set the CXX environment variable when running the configure script to force it to use a particular compiler)

Another thing you can try for the sake of it is locally replacing the contents of file core/file/json.h with the most up-to-date version of that library. It’s possible that fixes to the JSON for Modern C++ code have been required to prevent issues with more recent compilers; but the fact that you get a similar runtime issue with Qt suggests that this is not the underlying issue.

Ok a few more things I tried:

  • Downgrading to mingw-w64-x86_64-gcc-5.1.0-1 (including gcc-libs) -> same result, json runtime error, if I omit the test, runtime error in qt application. Downgrading to 6.1.0-1 was somehow not possible due to dependencies of other libraries UPDATE: I managed to install mingw gcc 6.3.0, but I also get the json runtime error and if I skip that test, I run into the qt runtime error

  • swapping json.h -> json test also fails (even if I rename json.h and keep json.hpp without renaming to json.h, same behaviour)

  • Uninstalling msys2 64bit completely and reinstalling the current version, following all the instructions in the installation guide -> same result

  • Another fresh installation of msys2 64bit, reinstalling only mingw-gcc- with libs and mingw-w64-x86_64-eigen3 -> JSON runtime error

  • trying g++ (currently 5.1.0) in the same installation -> json error

  • if I try /usr/bin/gcc or g++ (5.3.0) the config fails at C++11 compliance

  • uninstalling all gcc-libs and gcc versions, trying to install gcc instead of mingw-gcc => installs gcc 6.4.0 and ./configure stops at zlib step. Installing mingw-w64-x86_64-zlib fixes that issue, now even the json-test passes for the first time (with g++ (6.4.0), gcc (6.4.0) fails at detecting pointer size) but qt stuff is missing

  • install mingw_w64-x86_64-qt5 and -> ./configure throws an error linking Qt application (/usr/lib/gcc/x86_64-pc-msys/6.4.0/../../../../x86_64-pc-msys/bin/ld: cannot find -lmingw32 collect2: error: ld returned 1 exit status)

  • ./configure -nogui runs through, however, if I try to build, I get lots of errors:

    ERROR: ( 9/366) [CC] tmp/core/file/ofstream.o
    ERROR: ( 5/366) [CC] tmp/core/formats/nifti1_gz.o
    ERROR: ( 8/366) [CC] tmp/core/formats/nifti2.o
    ERROR: ( 12/366) [CC] tmp/core/image_io/sparse.o
    ERROR: ( 19/366) [CC] tmp/core/formats/mri.o
    ERROR: ( 3/366) [CC] tmp/src/dwi/tractography/seeding/list.o
    ERROR: ( 2/366) [CC] tmp/cmd/5tt2gmwmi.o
    ERROR: ( 1/366) [CC] tmp/src/dwi/tractography/roi.o
    ERROR: ( 21/366) [CC] tmp/core/formats/mrtrix_sparse_legacy.o

    ERROR: ( 9/366) [CC] tmp/core/file/ofstream.o`

    /usr/bin/g++ -c -std=c++11 -pthread -DMRTRIX_WINDOWS -mms-bitfields -Wa,-mbig-obj - D_FILE_OFFSET_BITS=64 -DMRTRIX_WORD64 -isystem /mingw64/include -DMRTRIX_TIFF_SUPPORT -isystem /mingw64/include -DEIGEN_FFTW_DEFAULT -isystem /mingw64/include -Wall -O3 -DNDEBUG -Isrc -I./core -Icmd -isystem /mingw64/include/eigen3 -DEIGEN_DONT_PARALLELIZE core/file/ofstream.cpp -o tmp/core/file/ofstream.o

    failed with output

    In file included from core/file/ofstream.cpp:17:0:
    ./core/file/utils.h: In function ‘void MR::File::mkdir(const string&)’:
    ./core/file/utils.h:200:13: error: too few arguments to function ‘int mkdir(const char*, mode_t)’
    In file included from ./core/file/utils.h:20:0,
    from core/file/ofstream.cpp:17:
    /usr/include/sys/stat.h:150:5: note: declared here
    int mkdir (const char *_path, mode_t __mode );

Not sure what else I could try…

Well I just upgraded my own Windows installation, which included MSYS2 base upgrades, and GCC 7.3.0 However I was able to configure and build just fine. My concern was that a MSYS2 update had broken things, in which case I’d need to get the word out as quickly as possible for people to avoid updating MSYS2.

Can you confirm that you have definitely used the correct version of the MSYS2 shell, as described in the documentation? It’s maybe conceivable that using the wrong shell could lead to issues like this. Also did you definitely close the current shell & all other shells after having performed MSYS2 updates via pacman, as pacman instructs when doing such updates?

One other thing that could be indicative of an issue is the specific line at which your attempted compilation fails:

./core/file/utils.h:200:13: error: too few arguments to function ‘int mkdir(const char*, mode_t)’
/usr/include/sys/stat.h:150:5: note: declared here
int mkdir (const char *_path, mode_t __mode );

The surrounding MRtrix3 code is:

if (::mkdir (folder.c_str()
            , 0777

So the “mkdir()” function is called with 1 argument on Windows, 2 on other OS’s; but it looks as though your included libraries define this function with two arguments. Maybe that might give a hint as to what else you could look into. Have you installed any MSYS2 packages related to POSIX compliance or such? Also, which version of Windows are you on? (I’ve observed using the same MSYS2 installer on Windows 7 and 8.1 machines and getting different resulting installations)

I’m surprised that you were not able to reproduce this issue. The errors occur on a Windows 7 machine. I’m pretty sure I used the correct shell and followed all the steps including updating pacman, closing the shell in between and so on, I also did it a few times already.
I’ll try to reproduce it on another Windows machine (also Win7 I think) in the coming days and keep you updated…

If I list all the installed packages, I can find libpcreposix 8.40-2 which depends on pcre. If I remove it with all dependencies (pactoys-git, pkgfile, pcre and finally libpcreposix), I still get the json error if I try ./configure

Yeah, if you need to remove pkgfile that’s probably something that’s not out of the ordinary to have installed.

One other thing you can try (just got this more-or-less working myself for other nefarious purposes):

pacman -S mingw-w64-x86_64-clang
CXX=clang++ CFLAGS="-Wno-incompatible-ms-struct" ./configure

You’ll still get some compiler warnings if you do manage to build, but this will at least tell us whether it’s something specific to g++ or whether it’s something in the MSYS2 runtimes that’s giving you grief.

I’ll also try a fresh MSYS2 install on my Windows 7 machine when I can.

using clang, I still get the json error, if I skip that check, I’ll end up at a qt compilation error (clang++.exe: error: unknown argument: '-fno-keep-inline-dllexport') but if I run configure with the -nogui option, the build runs through (with some warnings, as you mentioned)
Another strange phenomenon I noticed after the compilation, If I try to run one of the compiled binaries (e.g. mrinfo), I get a blank output from the shell. If I run it from outside the shell (e.g. windows cmd), I get an error entry point XXX could not be located in the dynamic link library libstdc++-6.dll but this might be caused by the path-envorinment. Inside the mingw-shell I get /mingw64/bin/libstdc++-6.dll as path to the library which seems normal to me I guess.

I’m impressed with your tenacity with this! :fist:

I have to admit that I have no idea what’s going on with your install. But also that when issues occur on Windows, it’s often a fair bit more difficult to get to the bottom of it, given that many parts of Windows are fairly opaque – this is one of the main advantages of open-source systems… But that’s a different discussion.

I have my own issue on my install, which I haven’t seen anywhere else – but at least they’re not related to the build stage. One thing that hasn’t come up yet is the possibility that this might be due to interference from an anti-virus program. Do you have one installed? What happens if you disable it…? You’d probably need to remove MSYS2 and re-install with all anti-virus programs disabled to really get to the bottom of this…

Well I just wanted to “quickly” update an old mrtrix installation of one of the windows machines to the current version, but sometimes things just take much more time than expected…

I do have McAfee running but I now disabled all of its services, uninstalled msys2 and re-installed. A clean msys2 installation already contains the libpcreposix library by the way, I just checked (even prior to pacman -Syuu).

Unfortunately it did not help, same behaviour, json-error, if I skip, Qt runtime error.

But it was worth a try…

Total mystery…

Can I just check whether you’ve tried rebooting the system…? Seems obvious, I know, but just in case a Windows update got installed recently that may require a reboot to finalise or something…?

Otherwise I’m not sure I’ve got anything further to contribute…

Actually, one thing you could try is posting the whole of your configure.log here for us to have a look through. There may be clues in previous tests that may shed some light into what’s going on – long shot though.

I restarted the computer at least two times during all of the testing, but I’ll try to test / reproduce the errors on another win7 machine tomorrow, maybe that helps spotting the error… I’ll keep you updated!

It worked just fine on another win7 pc, so I’ll try to find a difference between the two computers. The installation was performed the same way, but without any bugs on the second pc. I’ll try to find the difference between the two machines, at least hardware and software should be pretty similar. The configure.log files look the same except the temp-filenames and that on the working PC, non-POD variable-length check is OK and on the other machine it is “not found” with EXIT: 127.
I figured that if I copy the libstdc++-6.dll from the msys64\mingw64\bin folder, the non-POD test and the json-test works fine. However, if I run which libstdc++-6.dll I get msys64\mingw64\bin as if during the linking, the correct dll is chosen but for the running, a wrong dll is picked. The same happens even if I add msys64\mingw64\bin to my path, it does not seem to matter.
At least I got rid of the JSON problem by copying the dll to the mrtrix3 folder. The next error is during Qt application test. I suspect it is also due to some dll Problem, I’ll try to find the relevant one as well. Finally making some progress…
Qt also fails because of libstdc++-6.dll, the fix did not work because the qt application is started from a separate folder in the tmp directory during the check and not from the mrtrix3-folder itself.
I found a copy (but probably slightly different version / compilation) of libstdc++-6.dll in one of my %SystemRoot% folders and that dll-file got prioritized over the one in the mingw64 independent of what was written in the path environment variable.
Renaiming that dll helped and now configure & build worked like a charm (I hope I did not break any other software with this hack)!
If somebody runs into a similar (dll-related) problem on windows, running the compiled test-routines in the native windows-shell sometimes opens a popup error message with some information regarding the corrupt/missing dll in comparison to the mingw64 shell.
Thanks everybody for the support, problem solved!

1 Like

Great detective work! So it looks like there’s a conflict in the linker search path, so that the runtime linker resolves the wrong version of the libstdc++-6.dll at application start-up. If you’ve managed to build any of the executables, try running ldd bin/mrinfo from the MRtrix3 folder. Mine looks like this:

$ ldd bin/mrconvert.exe
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffb47c60000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffb47a30000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffb44c90000)
        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ffb45620000)
        libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x64940000)
        libgcc_s_seh-1.dll => /mingw64/bin/libgcc_s_seh-1.dll (0x61440000)
        mrtrix-3.0_RC2.dll => /home/donald/mrtrix3/bin/mrtrix-3.0_RC2.dll (0x65680000)
        zlib1.dll => /mingw64/bin/zlib1.dll (0x62e80000)
        libstdc++-6.dll => /mingw64/bin/libstdc++-6.dll (0x6fc40000)
        ??? => ??? (0x2de0000)
        USER32.dll => /c/WINDOWS/System32/USER32.dll (0x7ffb46450000)
        win32u.dll => /c/WINDOWS/System32/win32u.dll (0x7ffb44480000)
        GDI32.dll => /c/WINDOWS/System32/GDI32.dll (0x7ffb47bf0000)
        gdi32full.dll => /c/WINDOWS/System32/gdi32full.dll (0x7ffb440b0000)
        msvcp_win.dll => /c/WINDOWS/System32/msvcp_win.dll (0x7ffb44bf0000)
        ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ffb45030000)
        libtiff-5.dll => /mingw64/bin/libtiff-5.dll (0x68ec0000)
        liblzma-5.dll => /mingw64/bin/liblzma-5.dll (0x63cc0000)
        libjpeg-8.dll => /mingw64/bin/libjpeg-8.dll (0x6b800000)

That might give you a clue as to what it’s trying to do.

Might also be worth having a dig though how windows locates DLLs, that might allow you to figure out whether there is another version of this same DLL that happens to be in a location that Windows will search first, which could explain the conflict…

Interesting that this question comes along.

Actually I have the exact same problem on CentOs 7. ./configure fails with the message that JSON can’t be configured. And in error.log it says that /lib64/ version ‘GLIBCXX_3.4.21’ is not found. Any ideas how to approach this?