Problems with gconstructor.h and source FMU's in MSVC #4576

KarlWernersson · 2025-03-07T08:47:46Z

Hi

When trying to compile a Dymola source FMU together with a Dymola simulation and then link them there are many identical functions that causes link problems. A way to simply solve this is by making sure things are static declared.

Now for the gconstructor for MSVC the constructor has the following hack to force some function calls before main

#define G_DEFINE_CONSTRUCTOR(_func) G_MSVC_CTOR (_func, G_MSVC_SYMBOL_PREFIX)

#define G_MSVC_CTOR(_func,_sym_prefix) \
  static void _func(void); \
  extern int (* _array ## _func)(void); \
  int _func ## _wrapper(void) { _func(); return _array ## _func == NULL; } \
  __pragma(comment(linker,"/include:" _sym_prefix # _func "_wrapper")) \
  __pragma(section(".CRT$XCU",read)) \
  __declspec(allocate(".CRT$XCU")) int (* _array ## _func)(void) = _func ## _wrapper;

As some of these functions aren't static declared i get to problems when both the FMU and the dymola simuation uses modelicaInternal.c

I tried to modify the hack to make it static but it don't seem to work and i cant say I am an expert in this low level mscv hacking.

My workaround was to copy the name pasting of ModelIdentifier from FMI as this for us is only an issue for FMU's for us.

added to gconstructor _MSC_VER >=1500 defined

#ifndef MODEL_IDENTIFIER
#define MODEL_IDENTIFIER
#endif

#define G_Paste(a,b)     a ## b
#define G_PasteB(a,b)    G_Paste(a,b)
#define G_FullName(name) G_PasteB(MODEL_IDENTIFIER, name)

non _MSC_VER

#define G_FullName(name) name

and then later in ModelicaRandom,c ModelicaInternal.c, modelicaStandardTables.c I modified the use of G_DEFINE_CONSTRUCTOR by inserting the G_FullName macro

G_DEFINE_CONSTRUCTOR(G_FullName(ModelicaInternal_initializeCS))

static void G_FullName(ModelicaInternal_initializeCS)(void) {
    InitializeCriticalSection(&cs);
}

G_DEFINE_DESTRUCTOR(G_FullName(ModelicaInternal_deleteCS))
static void G_FullName(ModelicaInternal_deleteCS)(void) {
    DeleteCriticalSection(&cs);
}

If anyone has a better solution i am al ears, otherwise i am happy to make a pull request

The text was updated successfully, but these errors were encountered:

KarlWernersson · 2025-03-07T08:48:09Z

@beutlich

beutlich · 2025-03-09T20:42:08Z

@KarlWernersson I understand that it might be a problem if a source code FMU contains the same source files as the simulation environment. I want to create a minimal example, indpendent of FMU or Dymola. Is it as simple as building an executable which compiles ModelicaRandom.c and links ModelicaExternalc.lib where

ModelicaRandom.c mimics the file of the source code FMU
Linking ModelicaExternalc.lib (which already contains the symbols of ModelicaRandom) mimics the Dymola simulation environment

…symbols issue

…ols issue

…ols issue in test code

beutlich · 2025-03-10T20:06:06Z

@KarlWernersson Have a look at my branch beutlich:issue4576 where I first added some test case demonstrating the MSVC build error on duplicated symbols (following the TDD approach) and afterwards applied the name mangling following your proposal. Let me know if it works for you if you export FMU and re-import FMU from this branch.

HansOlsson · 2025-03-11T09:12:25Z

@KarlWernersson will look at that next week.

However, I realized that we have to be even more careful regarding this, as there are two interrelated problems:

Upgrading uses of gconstructor to avoid link-conflicts
Versioning of gconstructor

The second issue ( related to modelica-3rdparty/ExternData#53 ) is that if you have a library (like ExternData) using the existing gconstructor.h having a new file with the same name but different contents will cause problems (especially as it impacts code using it and thus is an "API-change"). Since we cannot immediately change all existing copies of such libraries (including ExternData) I believe that the safest approach is to rename the file when modifying it.

(Obviously those libraries should be upgraded as well at some time.)

…code

beutlich · 2025-03-11T17:40:32Z

Yes, it might be better to have a new file and new macros to avoid any potential compatibility problems. I updated my branch accordingly.

GarronFish · 2025-03-14T06:39:10Z

Will this mean that older versions of ExtrernData will not be compatible with Dymola 2025x R1 in which these changes have been made?

KarlWernersson · 2025-03-14T08:32:49Z

Hi @GarronFish we will try to avoid that.

beutlich · 2025-03-18T18:50:21Z

@KarlWernersson will look at that next week.

Did you find the time to inspect my proposed and test changes? I also wonder if this change is relevant for upcoming MSL v4.1.0?

KarlWernersson · 2025-03-19T08:27:20Z

@beutlich
Thanks for taking you time looking at this and your quick response, i will look at it today or tomorrow, I got struck with a strong case of the flu and was on a business trip so i didn't have time to look at it until now.

beutlich · 2025-04-01T18:44:01Z

Did you find the time to inspect my proposed and test changes? I also wonder if this change is relevant for upcoming MSL v4.1.0?

@KarlWernersson Any news on this?

KarlWernersson · 2025-04-02T09:07:53Z

@beutlich Hi sorry for they delay. Your solution looks good, i have ported it already to Dymola, initial tests are OK, but more thorough tests will run over the night.
Thanks for your help and sorry for my delay.

casella · 2025-04-11T10:47:17Z

@KarlWernersson any results from your further batch of tests?

KarlWernersson · 2025-04-11T10:49:34Z

Hi @casella @beutlich sorry yes everything seems to work well.

The updates has been ported and will be included in Dymola 2025x Refresh 1

casella · 2025-04-11T11:03:06Z

@beutlich how do we proceed? Shall something be merged on master?

* Introduce and apply name mangling to avoid MSVC duplicated symbols issue * Bump version by renaming file and macros

beutlich · 2025-04-13T16:56:22Z

@beutlich how do we proceed? Shall something be merged on master?

I am unsure if this is a library issue or a general MSL issue with re-imported FMUs.

I am unsure what @KarlWernersson means by "has been ported and will be included in Dymola 2025x Refresh 1". If it means that Dymola no longer distributes an officially released MSL (like other tool-vendors do), I wonder if I am still able to load my MSL from repository.

Nevertheless, I created #4620 from the proposed changes. It does not harm at all to merge it (provided that no tool vendor or library vendor was ever depending on the existence of gconstructor.h).

* Introduce and apply name mangling to avoid MSVC duplicated symbols issue * Bump version by renaming file and macros

KarlWernersson mentioned this issue Mar 7, 2025

Rename or remove gconstructor.h from c-sources and Include modelica-3rdparty/ExternData#53

Closed

beutlich self-assigned this Mar 9, 2025

beutlich added the L: C-Sources Issue addresses Modelica/Resources/C-Sources label Mar 9, 2025

beutlich added a commit to beutlich/ModelicaStandardLibrary that referenced this issue Mar 10, 2025

refs modelica#4576: Add test case to mock MSVC duplicated symbols error

7560174

beutlich added a commit to beutlich/ModelicaStandardLibrary that referenced this issue Mar 10, 2025

refs modelica#4576: Introduce name mangling to avoid MSVC duplicated …

4e30696

…symbols issue

beutlich added a commit to beutlich/ModelicaStandardLibrary that referenced this issue Mar 10, 2025

refs modelica#4576: Apply name mangling to avoid MSVC duplicated symb…

8c805ea

…ols issue

beutlich added a commit to beutlich/ModelicaStandardLibrary that referenced this issue Mar 10, 2025

refs modelica#4576: Apply name mangling to avoid MSVC duplicated symb…

214fb65

…ols issue in test code

beutlich added a commit to beutlich/ModelicaStandardLibrary that referenced this issue Mar 11, 2025

refs modelica#4576: Bump version by renaming file and macros

f7b4ff2

beutlich added a commit to beutlich/ModelicaStandardLibrary that referenced this issue Mar 11, 2025

refs modelica#4576: Bump version by renaming file and macros in test …

1225162

…code

beutlich added a commit to beutlich/ModelicaStandardLibrary that referenced this issue Apr 13, 2025

refs modelica#4576: Update gconstructor handling

de2925b

* Introduce and apply name mangling to avoid MSVC duplicated symbols issue * Bump version by renaming file and macros

beutlich linked a pull request Apr 13, 2025 that will close this issue

Update gconstructor.h handling #4620

Open

beutlich added a commit to beutlich/ModelicaStandardLibrary that referenced this issue Apr 21, 2025

refs modelica#4576: Update gconstructor handling

0559083

* Introduce and apply name mangling to avoid MSVC duplicated symbols issue * Bump version by renaming file and macros

beutlich added a commit to beutlich/ModelicaStandardLibrary that referenced this issue May 5, 2025

refs modelica#4576: Update gconstructor handling

8a9ce9d

* Introduce and apply name mangling to avoid MSVC duplicated symbols issue * Bump version by renaming file and macros

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Problems with gconstructor.h and source FMU's in MSVC #4576

Problems with gconstructor.h and source FMU's in MSVC #4576

KarlWernersson commented Mar 7, 2025

KarlWernersson commented Mar 7, 2025

beutlich commented Mar 9, 2025 •

edited

Loading

beutlich commented Mar 10, 2025 •

edited

Loading

HansOlsson commented Mar 11, 2025

beutlich commented Mar 11, 2025 •

edited

Loading

GarronFish commented Mar 14, 2025

KarlWernersson commented Mar 14, 2025

beutlich commented Mar 18, 2025

KarlWernersson commented Mar 19, 2025

beutlich commented Apr 1, 2025

KarlWernersson commented Apr 2, 2025

casella commented Apr 11, 2025

KarlWernersson commented Apr 11, 2025 •

edited

Loading

casella commented Apr 11, 2025

beutlich commented Apr 13, 2025 •

edited

Loading

Problems with gconstructor.h and source FMU's in MSVC #4576

Problems with gconstructor.h and source FMU's in MSVC #4576

Comments

KarlWernersson commented Mar 7, 2025

KarlWernersson commented Mar 7, 2025

beutlich commented Mar 9, 2025 • edited Loading

beutlich commented Mar 10, 2025 • edited Loading

HansOlsson commented Mar 11, 2025

beutlich commented Mar 11, 2025 • edited Loading

GarronFish commented Mar 14, 2025

KarlWernersson commented Mar 14, 2025

beutlich commented Mar 18, 2025

KarlWernersson commented Mar 19, 2025

beutlich commented Apr 1, 2025

KarlWernersson commented Apr 2, 2025

casella commented Apr 11, 2025

KarlWernersson commented Apr 11, 2025 • edited Loading

casella commented Apr 11, 2025

beutlich commented Apr 13, 2025 • edited Loading

beutlich commented Mar 9, 2025 •

edited

Loading

beutlich commented Mar 10, 2025 •

edited

Loading

beutlich commented Mar 11, 2025 •

edited

Loading

KarlWernersson commented Apr 11, 2025 •

edited

Loading

beutlich commented Apr 13, 2025 •

edited

Loading