#391 QwtInterval::QwtInterval() redeclared without dllimport attribute

[jschueller]

hi, with mingw, when qwt is compiled as a shared library, client code emits these warnings:
/usr/x86_64-w64-mingw32/include/qwt/qwt_interval.h:112:8: error: ‘QwtInterval::QwtInterval()’ redeclared without dllimport attribute after being referenced with dll linkage [-Werror]
112 | inline QwtInterval::QwtInterval()

the problem is some class methods are declared non-inline, eg:
class QWT_EXPORT QwtInterval
{
public:
QwtInterval::QwtInterval()
...
};

but then redefined as inline:
inline QwtInterval::QwtInterval()
: m_minValue( 0.0 )
, m_maxValue( -1.0 )
, m_borderFlags( IncludeBorders )
{
}

but on win32 targets QWT_EXPORT expands to dllimport/dllexport which conflict with inline visibility attribute

there are several solutions to this:

1. mark them inline in the class declaration too: "inline QwtInterval::QwtInterval();"
2. move the definitions into their .cpp

while 1 is the minimal fix, 2 would be more invasive but imho would be cleaner to reduce the client code compilation and clearly mark the interface separation

which option do you prefer ? I can propose a patch if you want

[Uwe Rathmann]

The inline keyword is not used in any of the Qwt class declarations - so the situation you are describing can be found in many Qwt headers.

However - it is ike this since 20 years and Qwt has been used in many projects using mingw. So there must be something special about your project ?

I had a look at the Qt headers and most of the inlined methods are indeed declared as inline in the class declaration. However you also find something like QSize::QSize, were the inline keyword is for the implementation only ( not 100% comparable with QwtIntervall::QwtInterval as it has the constexpr keyword )

[jschueller]

yes, as described it could be more than QwtInterval; happens with QwtPoint3D too, but maybe other classes

possible explanations to why is has not been adressed yet is:

1. projects do not use shared qwt dll (its common to use only static libs on windows platforms)
2. they use the dll but omit QWT_DLL (may still link ok in some situations apparently)
3. maybe recent gcc versions now turn this into an error even without -Werrror (gcc 16.2 here but I cannot test earlier versions)

j

minimal reproducer, compile with QWT_DLL on mingw/gcc16 with QWT_DLL:

#include <qwt_interval.h>
#include <qwt_point_3d.h>
int main(){ QwtInterval i; QwtPoint3D p; return 0; }

[Uwe Rathmann]

As mentioned before: Qwt is used in so many projects for so long that I can hardly imagine that you are the first one using DLLs with mingw on Windows.

So lets have a look how the compiler is used in your build process:

1) How do you build Qwt - using the official qmake project files ?
2) How do you build your application ?
3) What Qt version are you using ?

PS: I'm not using Windows myself - actually I do not have a Windows box at all here.

[jschueller]

I'm using mingw-w64-qwt 6.3.0 from archlinux, with latest qt6 6.11.x, here is a minimal reproducer that can be run from linux using docker:
https://gist.github.com/jschueller/bf45e0787a44d359b8b12cd18306bb1d

[Uwe Rathmann]

After looking a second time to your initial bug report I noticed, that it is "only" about a compiler warning, that is treated as error because you actively enabled -Werror - right ?

Could you please build without -Werror and show the line with the warning. Then we can see the specific compiler flag that is responsible for the warning ?

[Anonymous]

you are right my CMakeLists added -Werror, but even -Werror we cannot see any compiler flag id
the explanation is that this is a mingw backend warning (i386/winnt.c) and not a -W* option
so we have no -Wno-... to silence it either:

#16 2.511 [ 50%] Building CXX object CMakeFiles/repro.dir/main.cpp.obj
#16 2.512 /usr/sbin/x86_64-w64-mingw32-g++ -DMINGW_HAS_SECURE_API=1 -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQWT_DLL -DUNICODE -DWIN32 -DWIN64 -D_ENABLE_EXTENDED_ALIGNED_STORAGE -D_UNICODE -D_WIN64 @CMakeFiles/repro.dir/includes_CXX.rsp -D_FORTIFY_SOURCE=3 -D_GLIBCXX_ASSERTIONS -O2 -pipe -fexceptions --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fcf-protection -MD -MT CMakeFiles/repro.dir/main.cpp.obj -MF CMakeFiles/repro.dir/main.cpp.obj.d -o CMakeFiles/repro.dir/main.cpp.obj -c /tmp/repro_qwt/main.cpp
#16 4.282 In file included from /tmp/repro_qwt/main.cpp:1:
#16 4.282 /usr/x86_64-w64-mingw32/include/qwt/qwt_interval.h:112:8: warning: ‘QwtInterval::QwtInterval()’ redeclared without dllimport attribute after being referenced with dll linkage
#16 4.282   112 | inline QwtInterval::QwtInterval()
#16 4.282       |        ^~~~~~~~~~~
#16 4.303 In file included from /tmp/repro_qwt/main.cpp:2:
#16 4.303 /usr/x86_64-w64-mingw32/include/qwt/qwt_point_3d.h:65:8: warning: ‘QwtPoint3D::QwtPoint3D()’ redeclared without dllimport attribute after being referenced with dll linkage
#16 4.303    65 | inline QwtPoint3D::QwtPoint3D()
#16 4.303       |        ^~~~~~~~~~
#16 4.684 [100%] Linking CXX executable repro.exe

[Anonymous]

So I believe the fix is still to avoid dllimport out-of-line inlines as proposed initially, either to declare them inline, or merge declaration and definition as inline, or move definition to .cpp

[Uwe Rathmann]

O.k. now it is understandable, that nobody complained before and I would consider it less urgent than a compiler error. However Qwt headers should not be the reason for warnings when compiling application code and these warnings have to be be avoided - like a couple of deprecation warnings that started to happen with recent Qt versions.

Moving the implementation to the cpp file means that there is no inlining anymore. I also dislike this solution because the next Qwt release will drop Qt4.x ( nobody needs it anymore ) and the code can rely on more modern c++ versions using constexpr etc.

Moving the implementation into the class declaration makes reading the class API harder, that's why I do not like this solution either.

So my preferred solutions is to duplicate the inline keyword before the method declaration. This might be the expected solution as this is what is done in Qt headers. Will do the fixes the next time I'm working on Qwt.

[Anonymous]

great, thanks a lot