View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004268 | OpenFOAM | Bug | public | 2025-08-24 17:44 | 2025-08-24 18:05 |
| Reporter | jacob | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | MinGW-w64 | OS | Windows | OS Version | 11 |
| Product Version | 13 | ||||
| Summary | 0004268: Thermo relies on specific ordering of global constructors in separate translation units | ||||
| Description | The static attributes `derivedThermoName` in thermo classes are initialized in different translation units (e.g. "psiThermo.C") than in which they are used to populate run-time selection tables (e.g. "psiThermos.C") by means of other constructors. While it seems to work well for common workflow using GNU ld on Linux, in general this is an undefined behaviour in C++ ( https://isocpp.org/wiki/faq/ctors#static-init-order ). I actually ran into this problem with the MinGW-w64 compiler in Cygwin64 on Windows 11. There, apparently, `derivedThermoName` was not initialized prior to its use in the `defineThermo` macro, resulting in empty string being used to compute the amalgamated thermo name entering the constructor table. As a consequence, thermo models based on distinct basic models (`psiThermo`, `rhoFluidThermo`, etc.) produced identical run-time selection table entries, causing the solver to fail, complaining about the duplicates. I was able to work around this issue by changing the static attribute `derivedThermoName` to an inline static function of the same name that returned the required string. The macro `defineThermo` then simply called that function. | ||||
| Tags | No tags attached. | ||||
