SystemModeler compiler can't find inttypes.h?

[mmacenaeng (Michel Oliveira)]

I tried to compile a co-simulation FMU (2.0) and the compiler complains that inttypes.h
is missing. The same error ocurred when I try to run any model. Here is the compiler settings:

And here is the compiler error:

There is a macro in modelica_types.h: HAVE_INTTYPES_H and seems to me
that it is defined somewhere else, so the compiler tries to compile with this header but doesn’t find it. I inspected the folder of modelica_types.h but didn’t see any inttypes.h.

System:

Product version: 12.3.1.7

Client: Model Center

Client version: 12.3.1.6

Client creation date: 2021-06-07T11:45:13.640000

Client build revisions: S:1b0160c02, J:1dbf5d051, L:38c242434

Client build type: 64 bit

Kernel version: 12.3.1.7

Kernel creation date: 2021-05-27T14:59:37.824000

Kernel build revisions: S:745840ba9, J:84e3d9a4b, L:38c242434

Kernel root directory: C:\Program Files\Wolfram Research\SystemModeler 12.3.1

Installation directory: C:\Program Files\Wolfram Research\SystemModeler 12.3.1

Platform: Windows 10 Version 1909

[ottot (Otto Tronarp)]

You are most likely missing a necessary component of Visual Build Tools. I would suggest that you install the compiler by pressing the “Check for Compatible Compiler” button in the dialog shown above. This will preselect the necessary components of Visual Studio Build Tools that you need to install.

Otto

[mmacenaeng (Michel Oliveira)]

As soon as I finished SM installation, it prompted me to set a compiler. I let
it choose and the first option was VS 2019 version, than a I did as you told,
I’ve clicked in “check for compatible compiler” and it asked me to install VS 2017.
I’ve installed the full “Visual C++ build tools” workload for Vs 2017 and it still fails with the same problem. I couldn’t find inttypes.h header in my computer also, I don’t now why the macro HAVE_INTTYPES_H is set.

[ottot (Otto Tronarp)]

The HAVE_INTTYPES_H macro is set because Visual Studio should have the inttypes.h header since VS2013.

Just to make sure did you verify that the selected compiler was changed to you newly installed VS 2017?

I’ve installed the full “Visual C++ build tools” workload for Vs 2017

That is not communicated that clearly, but you are not supposed to change anything during the installation, the necessary components should be preselected.

For me the component that seems to add the inttypes.h file is Windows Universal CRT SDK

[mmacenaeng (Michel Oliveira)]

Ok, I have confused the 12.1 version of SM with 12.3 version, I had both installed.
But I still have the problem. Now in 12.3 version, I checked for compatible compilers and choose visual C++ build tools 2019. Than the main VS screen doesn’t offer anything new to install. And the component that you show is installed. It is in portuguese but you can get it.

PS: I have reinstalled SM 12.3 to try to fix it, but didn’t work.

EDIT: I’ve uninstalled all VS packages and I started SM again, it prompted me to set the compiler and it, as always, opens the VS installer (VS 2019). I just installed everything SM pre-selected and the problem still happens.

EDIT 2: I found inttypes.h, is at:

C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt

I added this path with the /I flag in a custom compiler setting:

After that the error changes:

It said that it could not open the file, also in the folders:

C:\Program Files\Wolfram Research\SystemModeler 12.3.1\lib\win64\VS2019

and

C:\Program Files\Wolfram Research\SystemModeler 12.3.1\lib\win64\VS2019\msl\3.2.3

there is no libucrt.lib file.

Does SM need some environmental variables? for itself or for VS2019 tools ?
Is there any important stuff that SM requires that should be in the PATH env. var. ?

[mmacenaeng (Michel Oliveira)]

After a week spent on this I could manage to solve the problem. Actually, the problem was with Visual Studio 2019 installation. For some strange reason, the command VsDevCmd messes with all the needed environmental variables to do a proper compilation. It is something related with having more than one version of Windows SDK in the computer. It shouldn’t be a problem as SM “asked” VS2019 the proper setup to compile its files. The toolkit with all needed headers and libraries is the 10.0.19041.0 version. You can find the toolkits in (if you haven’t changed the standard path):

C:\Program Files (x86)\Windows Kits\10\Include

There is a folder for each version:

Solution:

1. Select custom setup for the compiler;
2. Add -winsdk=10.0.19041.0 command to the line “Visual C++ setup script arguments”;
3. Click Verify Compiler, it is expected to succeed;
4. Click OK.

My compiler options screen after setup:

Hope this helps anyone with the same problem!

Relevant link:
https://renenyffenegger.ch/notes/Windows/dirs/Program-Files-x86/Microsoft-Visual-Studio/version/edition/Common7/Tools/VsDevCmd_bat

[ottot (Otto Tronarp)]

I’m glad that you figured it out and thanks for sharing the solution.

That the old 10.0.10240.0 doesn’t work isn’t that surprising, this was back in the day with VS2015 and then perhaps some of the libraries came with the compiler.

I’m still perplexed by the fact that it doesn’t work out of the box for you, if you don’t specify -winsdk VsDevCmd.bat is supposed to select the newest as far as I can tell and for you that would be 10.0.22000.0 and that one certainly works for me. According to posts at the Visual Studio community it’s supposed to read that information from the registry: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\Windows\v10.0
You could take a look there and see which version it points to.

Otto

[mmacenaeng (Michel Oliveira)]

You’re welcome.

In my HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MicrosoftSDKs\Windows\v10.0
the version is 10.0.19041. I don’t understand why is not 10.0.22000.0 version. Also, the 10.0.19041 folder have more and different stuff than the 10.0.22000.0 folder.

10.0.22000.0 folder:

10.0.19041 folder: