Importing inline functions in MinGW

Question

I\'m using a shared library that defines inline functions in its header.

Here is a reduced test case, as seen by the compilation unit linking to the library (for the

Answer 1

Further information to Chris Dodd's answer:

I tested with MSVC 2017 and MinGW-w64 7.2.0; in both cases, with optimization enabled, the call of myFunc1() from myFunc2 resolved to the inline version, despite the warning. Even if the body of myFunc1 were moved to below main().

So my tentative conclusion is that it is safe to ignore this warning.

---

In the interest of a clean compile, the only method that seems to work in MinGW-w64 is to mark the function declaration within the class definition as inline. The compiler does not allow applying __declspec(dllimport) to the out-of-class function definition.

I have been unable to determine if there is a warning flag for g++ which will specifically disable this warning.

Answer 2

The problem comes about because of some magic in the way that dllimport works which normally means you only need it on the first declaration.

Basically, when you declare a function as dllimport and then later redeclare the function with an identical declaration except for the dllimport, the second declaration implicitly gets the dllimport. If the redeclaration is NOT identical, it doesn't get the implicit dllimport.

So what happens here is you first declare the function as dllimport/non-inline, and then declare it as non-dllimport/inline. Adding an inline to the first declaration fixes the problem, as the second then becomes implicitly dllimport. Alternately, adding a __declspec(dllimport) to the second declaration should fix the problem.

Note that reordering the definitions gets rid of the warning, since the warning is about using it before redeclaring it. With a reorder, you're no longer using it before the redeclaration, so you get no warning, though it will be using the non-dllimport version (ie, it will never use the version of the function from the dll).

Note also, using inline dllimport is dangerous. Any program built against the dll might use the inline function in some places and the non-inline function (from the dll) in others. Even if the two functions are identical NOW, a future version of the dll might change and have a different implementation. At which point the old program might start misbehaving if run with the new version of the dll.