ModelicaInternal.c fails compilation with MinGW 15

[d94pn]

When upgrading compiler from MinGW 8 to MinGW 15 on Windows I get below compiler errors (both for 32-bit and 64-bit).

ModelicaInternal.c: In function 'ModelicaInternal_mkdir':
ModelicaInternal.c:371:18: error: implicit declaration of function '_mkdir'; did you mean 'mkdir'? [-Wimplicit-function-declaration]
371 | int result = _mkdir(directoryName);

ModelicaInternal.c: In function 'ModelicaInternal_chdir':
ModelicaInternal.c:1170:18: error: implicit declaration of function '_chdir'; did you mean 'chdir'? [-Wimplicit-function-declaration]
1170 | int result = _chdir(directoryName);

I can see two reasons for triggering those:

• Something has changed for MinGW that requires updates of the pre-processor variables controlling the compliation.
• gcc in MinGW is more picky about implicit declarations and reports them as error instead of warnings.

Since I've noticed other unrelated implicit declarations errors when upgrading to MinGW 15 I'm inclined to favor the second. I.e. the declaration has been implicit also earlier but has passed unnoticed. So perhaps the preprocessor variables are simply not fully adopted for MinGW?

A possible fix is to move the || defined(__GNUC__) higher up to handle MinGW on Windows orrectly.

#if defined(__WATCOMC__) || defined(__LCC__) || defined(__GNUC__)
    int result = mkdir(directoryName);
#elif defined(__BORLANDC__) || defined(_WIN32)

and similar for chdir.

[AHaumer]

Which tool are you using? Which OS? I suppose this is a tool issue, not an issue of the Modelica Standard Library. MINGW sounds like OpenModelica. Have you contacted OM in github?

[d94pn]

Using (and developers of) Dymola under Windows. We cannot see that this an obvious tool issue unfortunately. If you have a testbench with different compilers available, it would be good if you could try MinGW 15 on some scenario that tests this code section. If you don't, have a Dymola version installed and want the scenario for Dymola, please let me know.

I understand if you don't have the time and resources for testing all reportes issues. But then it would be good with some comment on the proposed fix. Does it make sense or is there a reason for keeping the || defined(__GNUC__) in its original place?

[beutlich]

I wonder why it is not reproducable in CI when GCC 12 or GCC 14 is used.

[d94pn]

I realized the suggested modification will fail on systems where _POSIX_ and __GNU__ are both set. It instead needs to be:

#if defined(_POSIX_)
    int result = mkdir(directoryName, S_IRUSR | S_IWUSR | S_IXUSR);
#elif defined(__WATCOMC__) || defined(__LCC__) || defined(__GNUC__)
    int result = mkdir(directoryName);
#elif defined(__BORLANDC__) || defined(_WIN32)
    int result = _mkdir(directoryName);
#else
   ModelicaNotExistError("ModelicaInternal_mkdir");
#endif

[HansOlsson]

I realized the suggested modification will fail on systems where _POSIX_ and __GNU__ are both set. It instead needs to be:

#if defined(_POSIX_)
    int result = mkdir(directoryName, S_IRUSR | S_IWUSR | S_IXUSR);
#elif defined(__WATCOMC__) || defined(__LCC__) || defined(__GNUC__)
    int result = mkdir(directoryName);
#elif defined(__BORLANDC__) || defined(_WIN32)
    int result = _mkdir(directoryName);
#else
   ModelicaNotExistError("ModelicaInternal_mkdir");
#endif

To keep the GNU non-POSIX on non-Windows case as before (assuming that case exist) shouldn't it be:

#if defined(_POSIX_) || ( defined(__GNUC__) && !defined(_WIN32) )
    int result = mkdir(directoryName, S_IRUSR | S_IWUSR | S_IXUSR);
#elif defined(__WATCOMC__) || defined(__LCC__)
    int result = mkdir(directoryName);
#elif defined(__BORLANDC__) || defined(_WIN32)
    int result = _mkdir(directoryName);
#else
   ModelicaNotExistError("ModelicaInternal_mkdir");
#endif

[d94pn]

Ok, but you still need the || defined(__GNUC__) on the line

#elif defined(__WATCOMC__) || defined(__LCC__) || defined(__GNUC__)

else MinGW will end up in the next condition and get the _mkdir which fails.

[beutlich]

• Does the error only happen with GCC 15?
• Can you check direct.h of the MinGW include files for _mkdir/_chdir!
• Can you print the exact compiler command!

Thank you!

[beutlich]

I also noticed that even if _rmdir is available in MinGW header direct.h, ModelicaInternal.c uses rmdir in line 388 and not _rmdir of line 390. Hence, it is not consistent between _mkdir/_chdir and _rmdir.

https://github.com/modelica/ModelicaStandardLibrary/blob/c2dabe7c979b321760bfc99ad8cc99d2a8777624/Modelica/Resources/C-Sources/ModelicaInternal.c#L385-L393

[d94pn]

Find attached the direct.h from 32-bit MinGW 15. Unclear why mkdir instead of _mkdir is used in this case.

direct.zip

It happens with MinGW 15 with gcc 15.1. It does not happen older MinGW like e.g. MinGW 8. Havn't tried those in between,

If you have any Dymola release from the latest years, you can reproduce by selecting MinGW 15 in the Simulation setup and then do

translateModelFMU(
  "Modelica.Blocks.Examples.PID_Controller",
  false,
  "",
  "3",
  "all",
  true,
  2,
  fill("", 0));

For what it is worth, the gcc call is:

"E:/MinGW_15/bin/gcc.exe" -c dsmodel.c  "E:/Program Files/Dymola 2025x/source/FMI/fmi3Functions.c"  -m32    -DSkip_f2c_Undefs -I . -I "E:/Program Files/Dymola 2025x/source/FMI" -I "E:/Program Files/Dymola 2025x/source" -static -Wl,--no-undefined -Wl,--allow-multiple-definition   -DDYMOLA_STATIC= -DFMI_MODULE_NAME=Modelica_Blocks_Examples_PID_0Controller.dll -DBUILDFMU -DFMI_VERSION=300 

So this can be reproduced also with MSL 4.0.0.

[beutlich]

So this can be reproduced also with MSL 4.0.0.

Ah, good to know that at least it is not an MSL regression.

[beutlich]

Find attached the direct.h from 32-bit MinGW 15. Unclear why mkdir instead of _mkdir is used in this case.

That's the same file content as for MinGW 14.2. It's included and should be available.

https://github.com/modelica/ModelicaStandardLibrary/blob/c2dabe7c979b321760bfc99ad8cc99d2a8777624/Modelica/Resources/C-Sources/ModelicaInternal.c#L302-L303

[beutlich]

• Where did you get MinGW 15? I can't find it, neither here nor here.

• With your MinWW 15, can you please compile ModelicaInternal.c via: gcc.exe -Wall -Wpedantic -Wextra -c ModelicaInternal.c! That's what I get with MinGW 14.2.0

  

• I can't reproduce in Dymola 2024 R1 with MinGW 14 because of error (even if compiler verification succeeded), which I am unable to circumvent:

  The best matching gcc directory: gcc510 has a higher version than used compiler: gcc1420.
  

[d94pn]

A parital reply for now:

• MinGW 15 is here: https://github.com/niXman/mingw-builds-binaries/releases
• The The best matching gcc directory:... is just a warning message. You can workaround by renaming the folder "gcc510" to "gcc"

[beutlich]

A parital reply for now:

* MinGW 15 is here: https://github.com/niXman/mingw-builds-binaries/releases

Thanks. That's what I get now, hence I doubt it is a MSL issue.

[beutlich]

If you have any Dymola release from the latest years, you can reproduce by selecting MinGW 15 in the Simulation setup and then do

translateModelFMU(
  "Modelica.Blocks.Examples.PID_Controller",
  false,
  "",
  "3",
  "all",
  true,
  2,
  fill("", 0));

I do, but w/o the option to generate FMU source code.

[beutlich]

• The The best matching gcc directory:... is just a warning message. You can workaround by renaming the folder "gcc510" to "gcc0510"

If I only knew where to find that folder. It's an error in case of pedantic translation though.

[d94pn]

• The The best matching gcc directory:... is just a warning message. You can workaround by renaming the folder "gcc510" to "gcc0510"

If I only knew where to find that folder. It's an error in case of pedantic translation though.

>find "Modelica 4.0.0" -name gcc510
Modelica 4.0.0/Resources/Library/win32/gcc510
Modelica 4.0.0/Resources/Library/win64/gcc510

Also, correction: Rename from "gcc510" to "gcc".

[d94pn]

If you have any Dymola release from the latest years, you can reproduce by selecting MinGW 15 in the Simulation setup and then do

translateModelFMU(
  "Modelica.Blocks.Examples.PID_Controller",
  false,
  "",
  "3",
  "all",
  true,
  2,
  fill("", 0));

I do, but w/o the option to generate FMU source code.

Yes, I can reproduce with Dymola 2025x Refresh 1.

[beutlich]

I fail to setup GCC in Dymola. Not an issue to dig further.

Anyway, could the original compilation issue be due to the unity/jumbo build of Dymola?

[d94pn]

Anyway, could the original compilation issue be due to the unity/jumbo build of Dymola?

I cannot with certainty exclude that the issue is Dymola specific although it did not appear so at first. Anyway, given the trouble it seems to be to recreate without Dymola, we can settle for a Dymola specific fix of the C-source in MSL until some other user of MinGW 15 and MSL reports the same issue.

[beutlich]

OK, I unassigned myself since I cannot reproduce and have no further idea.