AnalogClock::staticMetaObject': definition of dllimport static data member not allowe

I'm using Qt 6.4.3 and took the example of the analog clock customwidgetplugin included in the Qt installation package. I compiled the plugin and placed it in the path C:\Qt\Tools\QtCreator\bin\plugins\designer. I create a new qt project based on QWidget. In its .ui form I select and insert the created plugin. So far, so good. When I compile the plugin test program, I get this error message:

Code:

---

D:\dev\Qt\ProvaEsempioPlugin\debug\moc_analogclock.cpp:59: error: C2491: 'AnalogClock::staticMetaObject': definition of dllimport static data member not allowed

---

I don't understand where is the problem... You can help me ?

Google is your friend here.

Either you are building the plugin with the wrong dllimport / dllexport declaration or you are trying to use it in a program with the wrong declaration. You use dllexport when you are building the DLL and use dllimport when your are using the DLL in a program.

And in Microsoft world, you cannot mix debug and release mode code. If the DLL was built in release mode to use with Qt Designer, you cannot link with that same release mode DLL if you are building a debug mode program. You must build a debug mode DLL to link with your debug mode program.

d_stranz
No, the test project (like the plugin itself) are Release. I am attaching the .pro file of the test:

Code:

---

QT       += core gui
 
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
 
CONFIG += c++17
 
# You can make your code fail to compile if it uses deprecated APIs.
# In order to do so, uncomment the following line.
#DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x060000    # disables all the APIs deprecated before Qt 6.0.0
 
SOURCES += \
    main.cpp \
    widget.cpp
 
HEADERS += \
    widget.h \
    analogclock.h
 
FORMS += \
    widget.ui

---

If it can be useful, I also put the .pro of the plugin:

Code:

---

QT          += widgets uiplugin
 
QTDIR_build {
# This is only for the Qt build. Do not use externally. We mean it.
PLUGIN_TYPE = designer
PLUGIN_CLASS_NAME = AnalogClockPlugin
load(qt_plugin)
CONFIG += install_ok
} else {
# Public example:
 
CONFIG      += plugin
TEMPLATE    = lib
 
TARGET = $$qtLibraryTarget($$TARGET)
 
target.path = $$[QT_INSTALL_PLUGINS]/designer
INSTALLS += target
}
 
HEADERS     = analogclock.h \
              customwidgetplugin.h
 
SOURCES     = analogclock.cpp \
              customwidgetplugin.cpp

---

Where do I find the reference of dllimport in Qt code ? Please note that here I'm doing everything only in Qt environment, including IDE, for the moment I don't use Visual Studio C++ (here the same plugin project works fine, including the test program).
I want to be able to make everything work in Qt environment, so I can finally verify the old QLed problem that you will remember well :-))

Quote:

---

No, the test project (like the plugin itself) are Release.

---

Then why does your original post say this?

D:\dev\Qt\ProvaEsempioPlugin\debug\moc_analogclock.cpp:59: error: C2491

Anyway, the error is because you are including the header file "analogclock.h" as part of the HEADERS section in your .pro file. This causes Qt to create the moc_analogclock.cpp and try to compile it. But that file has already been compiled and is in your plugin DLL. So the compiler is complaining that you have defined the same static variable in two different places, your DLL and your application. Just remove the "analogclock.h" line from your .pro file. You are using the header, not building it.

Quote:

---

Where do I find the reference of dllimport in Qt code ?

---

The header analogclock.h decalares the AnalogClock class this way:

Code:

---

class QDESIGNER_WIDGET_EXPORT AnalogClock : public QWidget

---

The macro QDESIGNER_WIDGET_EXPORT expands to:

Code:

---

// qdesignerexportwidget.h
 
#if defined(QDESIGNER_EXPORT_WIDGETS)
#  define QDESIGNER_WIDGET_EXPORT Q_DECL_EXPORT
#else
#  define QDESIGNER_WIDGET_EXPORT Q_DECL_IMPORT
#endif

---

and Q_DECL_IMPORT and Q_DECL_EXPORT expand to:

Code:

---

// qcompilerdetection.h
 
#  define Q_DECL_EXPORT __declspec(dllexport)
#  define Q_DECL_IMPORT __declspec(dllimport)

---

The .pro file for the plugin causes QDESIGNER_EXPORT_WIDGETS to be defined for the plugin build, probably by some combination of the QTDIR_build section and CONFIG += plugin and TEMPLATE = lib declarations.

If you are going to try to build a Qt Designer plugin in a Visual Studio project, then you need to add QDESIGNER_EXPORT_WIDGETS as a Preprocessor Definition in the C/C++ -> Preprocessor section of your plugin project Properties. That means the __declspec( dllexport ) declaration is active and causes the compiler to export the AnalogClock class from the DLL so you can use it in projects.

When you are using the plugin in an application project, you do not use this define. If QDESIGNER_EXPORT_WIDGETS is not defined, then the __declspec( dllimport ) declaration is active and your class is imported from the DLL.

Quote:

---

Originally Posted by d_stranz

Then why does your original post say this?
D:\dev\Qt\ProvaEsempioPlugin\debug\moc_analogclock.cpp:59: error: C2491

---

Because in the meantime I tried to understand where the problem was and then I tried to compile the plugin test project as Release and not as Debug (when I asked the question on the forum).
Thanks for the explanations on the QDESIGNER_WIDGET_EXPORT macro. I also found on the Qt document the explanation that you also put on its meaning. But I'm working directly in the Qt environment, so I don't use Visual Studio C++ for testing (as well as for the plugin). I work everything on Qt Creator (including project compilation) for both plugin and testing. So my question now is: What did I do wrong when I created the test program using the Qt wizard for a QWidget based application ?
Note that I have provided the .pro files of both the plugin and the test.

---

Added after 1 18 minutes:

I managed to finish compiling the test program for the plugin. I had also done the same plugin and test program using Visual Studio C++ + Qt 6.4.3 and here it worked right away. So I took the plugin created in Visual Studio C++ + Qt (files .lib, .dll, .h) and I used them in the test program project using only Qt Creator 10.0.1 environment based on Qt 6.4.3 and creating the link to these in the .pro file that I show you:

Code:

---

QT       += core gui
 
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
 
CONFIG += c++17
 
TARGET = test
TEMPLATE = app
 
# You can make your code fail to compile if it uses deprecated APIs.
# In order to do so, uncomment the following line.
#DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x060000    # disables all the APIs deprecated before Qt 6.0.0
 
SOURCES += \
    main.cpp \
    widget.cpp
 
INCLUDEPATH += .
 
HEADERS += widget.h
 
FORMS += widget.ui
 
win32:CONFIG(release, debug|release): LIBS += -L$$PWD/../../__Cpp/QtWidgetsCustom/AnalogClockPlugin/x64/release/ -lAnalogClockPlugin
else:win32:CONFIG(debug, debug|release): LIBS += -L$$PWD/../../__Cpp/QtWidgetsCustom/AnalogClockPlugin/x64/debug/ -lAnalogClockPlugin
 
INCLUDEPATH += $$PWD/../../__Cpp/QtWidgetsCustom/AnalogClockPlugin
DEPENDPATH += $$PWD/../../__Cpp/QtWidgetsCustom/AnalogClockPlugin

---

The compilation was completed this time and the test program finally works.

At this point we have to ask ourselves, why is it not good to do the plugin only in the Qt 10.0.1 environment based on Qt 6.4.3 ?

To you the difficult answer :cool:

Quote:

---

At this point we have to ask ourselves, why is it not good to do the plugin only in the Qt 10.0.1 environment based on Qt 6.4.3 ?

---

I think you are confused about your tools and what they are doing.

Qt Creator and Visual Studio are two different "Integrated Development Environments" ("IDE"). They each provide different ways of configuring a project, editing code and user interfaces, and compiling, linking, and testing programs. That's all they are - project management tools. You can use either one of them to build the same DLL or EXE on Windows.

Internally, both Qt Creator and Visual Studio can be configured to use different "tool chains", a collection of compilers, linkers, and debuggers that turn your source code into an executable. For building a project on Windows, there are mostly two choices, the minGW tool chain and the Visual C++ tool chain. You can configure either one (or both) of them for Qt Creator to use ("kits"). Visual Studio uses the Visual C++ tool chain by default, but you can use others in new versions of Visual Studio.

Do not confuse the IDE with the tool chain. Qt Creator and Visual Studio are simply different products that can be used with tool chains to build products. minGW and Visual C++ are tool chains, not development environments. You can create programs the old, hard way, using a text editor and Makefiles, but it is much easier to use an IDE.

Early versions of Qt Creator used qmake and .pro / .pri files to create projects. Visual Studio used .sln / .vcproj / .vcxproj files. Now both products can use CMake and CMakelists files. All of these are just sets of instructions and configuration information that the IDE and tool chain uses to build the project.

For your plugin, the set of instructions in the qmake .pro file told qmake how to build the plugin with all of the correct preprocessor, compiler, and linker settings and commands. You configured Qt Creator to use a certain "kit" (a tool chain), probably the Visual C++ tool chain. It built a working plugin for you.

In Visual Studio, you need to do a little bit more work, by defining preprocessor variables and the project type, but in the end, you can still create a working plugin. I did this using your source code.

In your case, I think you made some mistakes in configuring the project so you were never able to create a working plugin using Visual Studio. From everything you have described about how the LED widget behaved in Qt Designer, I think the plugin was never able to actually create a QLed instance (almost certainly because QDESIGNER_WIDGET_EXPORTS was not defined when building the plugin DLL). Qt Designer was using the description of the QLed widget and its properties because of the domXML() code, the header file for the widget (which defined the properties), and the icon, but because it could not actually create the widget, changing the properties in Designer had no effect on the appearance on the design form.

In your test program, you were building the code for QLed as part of your project and not using the code in the plugin DLL. Your UI looked fine and changed appearance when you changed properties because you were using the version of the widget you built in your test program, not the one from the plugin DLL.

If QDESIGNER_WIDGET_EXPORTS is not defined when building the plugin, the QLed widget cannot be used outside of the DLL, either by a test program or by Qt Designer. Qt Designer is smart enough to use the icon to represent the widget in the form, but because it cannot create the actual widget, changing properties has no effect. Qt Designer is inserting a picture of the widget, not the widget itself.

Thanks for all your explanations d_stranz .
In fact I think I have a huge confusion on the project in question. For this I would need a tutorial that would clarify all these steps and lead me "holding my hand" to the completion of the plugin project and the test program. As for the development environment or IDE it was already clear to me. It's my fault for how I expressed myself, not using the right terms, but it is clear to me the fact of the tools depending on the IDE that is being used for the creation of the project and its compilation. Even if it falls outside the topic of my request on the forum, I need a good tutorial to help me better understand the use of CMake, which I've always avoided because I don't know how to use it well, it always gives me a lot of errors and I manage very few times to get to the creation of the .sln file (to be used in the Visual Studio C++ IDE) in order to be able to compile it. Therefore remaining on the topic of my request on the forum, how should I proceed using only Qt 6.4.3 as IDE and its Qt Creator and Qt Designer for the creation of the plugin and the program that tests it ?

Quote:

---

how should I proceed using only Qt 6.4.3 as IDE and its Qt Creator and Qt Designer for the creation of the plugin and the program that tests it ?

---

This is more confusion. Qt 6.4.3 is only a set of libraries that are used in developing applications. They can be used by any IDE (Qt Creator or Visual Studio) and tool chain (minGW or Visual C++) to build a project. If you install a Qt version that was built using minGW, then you need to use a minGW tool chain to build your plugin and your test program. If your version of Qt was made using Visual C++, then you have to use a Visual C++ tool chain to build your plugin and test program.

But Qt Creator and Visual Studio are completely independent of the Qt version and tool chains they use - they are just programs that use your instructions to compile and link code into applications. Qt Creator built using Qt 5 can be used to build Qt 6 programs and vice-versa, It doesn't matter. Visual Studio was not built using Qt at all, but it can be used to build applications using any version of Qt.

If you are using Qt Designer to create a user interface .ui file (and that is all that that software does - it is a program that gives you an interactive way to build a UI that is written to an XML .ui file), then you can use a Qt Designer program that was built with any version of the Qt libraries. The UI file it creates can be used with Qt 5 or Qt 6. However, if you want to write your own plugins for Qt Designer, you must use the same version of Qt libraries that was used to build Qt Designer. This is because there could be incompatible differences between Qt versions which could cause Qt Designer to work incorrectly. So if you want to build a Qt 6 plugin, you should use a version of Qt Designer that was built with Qt 6.

Usually this is not a problem - when you build the whole Qt distribution from source code, this will also build Qt Designer, Qt Creator, and all of the other Qt libraries with the same version. It is also true when you download a pre-built version of Qt.

Until recently, you also had to be sure that your version of Qt was built using the same Visual C++ version that you use to make your own projects. However, starting with Visual Studio 2015 (I think), new Visual Studio versions are backwards compatible, so you can use a version of Qt built with the Visual Studio 2015 tool chain with Visual Studio 2022. I did this until a couple of months ago.

If you want to develop your own Qt Designer plugins, then you can use either Qt Creator or Visual Studio (or both). You just have to make sure that you build your plugin using the same version of the Qt libraries that Qt Designer uses. You also need to use a version of Qt that was built using the same compiler tool chain.

CMake is just another tool for building programs. In some ways it is like qmake, but it is much more powerful. You can set up a CMake project to use any tool chain, and you can tell it to create Makefiles that you use with make / nmake or you can tell it to make Visual Studio .sln / .vcxproj files that you use with Visual Studio.

If you want to use CMake, then you really only need two CMakelists.txt files that you can use as templates: one for configuring to build a Qt Designer plugin, and another to configure to build a test program. The only thing you should need to change is the name of the project and the source files used to build it. All of the rest of the CMakelists.txt file can stay the same.

If you want me to, I can create these CMakelists.txt files for you for your QLed project. You should be able to modify them for any future project.

Quote:

---

Originally Posted by d_stranz

If you want me to, I can create these CMakelists.txt files for you for your QLed project. You should be able to modify them for any future project.

---

Yes d_stranz, the CMake files for the QLed plugin and test project would help. Then last night I was able to successfully compile the test for Analog Clock, there were errors in some parts of the plugin code. I took the original ones from the Qt 6.4 site. I look forward to your CMake files so I study them and try to figure out how to do it.