@JKSH Hey, thanks for the answer and sorry for the very late reply.

My path: C:\Qt\5.15.2\msvc2019\bin

The bitness of the windeploy.exe in that path is 32-bit.

It seems I misunderstood/forgot how the windeployqt is used, that I need to run it for each new release. The dll:s still are of different bitness from the application's .exe but I guess that's fine then...

It works now.

@timob256

target_link_libraries(${PROJECT_NAME} PRIVATE ${Qt5AxContainer_LIBRARIES}) target_link_libraries(compas_com_example PRIVATE Qt${QT_VERSION_MAJOR}::Core)

@Dariusz

Hi
Yes you can.
see this example (and reads the docs SGaist links)

https://doc.qt.io/qt-6/qtwidgets-tools-plugandpaint-app-example.html

Here the drawing app is extended with extra plugsins.

Do note, however, that you will need to do as sample does in
"The next step is to load dynamic plugins"

where is enumerate the files in a given folder using

const auto entryList = pluginsDir.entryList(QDir::Files); for (const QString &fileName : entryList) { QPluginLoader loader(pluginsDir.absoluteFilePath(fileName)); ...

so its not 100% automatic but almost ;)

Copy "libstdc++6.dll" from where the mingw bin files are located into your folder where the executable is located. This worked for me and it should work for yall :)

@UvQtcYZJuD7J5VW7 said in Dependencies missing after DLL compilation:

Unfortunately, LabView is not very talkative. This is the only error message I get. I have already recreated the node.

Ah, check the dependencies of the DLLs that you deployed. For example, libgcc_s_dw2-1.dll depends on other DLLs too.

Otherwise I could programming the entire program in Qt and so I will not have the need to use a DLL.

If you can do everything in 1 language, that makes life a lot easier.

Do you mean how to add paths so that your .exe files can be run from Qt Creator, or adding paths so that your .exe files can be run without Qt Creator?

In the first case (starting .exe files from Qt Creator) as long as you only have a single version of Qt installed on your PC, there should be no need to add any paths, as I said earlier, Qt Creator adds the path to the Qt dlls for you.

In the second case (starting .exe files without Qt Creator) then there are 2 ways to do it:

copy the Qt dlls to the same directory that your .exe file is in, either manually or by using the windeployqt.exe program adding the path to the Qt dlls to the PATH env. variable

Note: LIBS += -LMyPath has no effect on runtime lookup of .dlls or .so files
QMAKE_RPATHDIR has no effect on Windows, because Windows does not support adding a list of paths to your .exe/elf file where to find the Qt dlls/so files (works only on Linux and MacOS)
Also on Linux, QMAKE_RPATHDIR is not needed for the first case (starting .exe/elf files from Qt Creator) since Qt Creator does that automatically for you (by issuing a linker command e.g. -Wl,-rpath,/home/user/Qt/5.15.2/gcc_64/lib)

Are DLL(s) that are meant to be "optional plugins" that the EXE is designed to open with dlopen or (on windows) GetModuleHandle or LoadLibrary.... are those sorts of plugins suitable for use in injectors?

Nop

But that supposes the that executable in question is a Qt-dependent executable in the first place.
I guess you didn't explicitly mention that yet....
The process into which you attempt the injection... is that process any kind of Qt executable?

Nop, it was not made with Qt.

If not, then your injected code would (I believe) need to run a Qt event loop. Normally that would be done in the application's main.

Im really really dumb with Qt, but i will try to do something with this information. It's just sad because i can't find any example of what i want :(

Thanks

Hi,

It works thanks :)

Hi,

This stack overflow thread might be of interest to avoid having to play with the PATH environment variable.

Thank you @hskoglund for this option, it worked!
This is the perfect solution for me, it's simple, and now I can use C++ variables for the install path of my DLL if needed.

Thanks again!

@sierdzio I think you're second option is correct. I did

dumpbin /dependents

on both the debug and release versions of my util, and they have the same release QT dlls. I guess I never had to step into the QT code :-) . Usually, I get link errors when mixing debug with release, stemming from different array instrumentations. Sounds like QT was careful about this, to allow the mixing of debug with release -- unix-like.

@Yash001 said in why definition is talking from .cpp file?:

why it is working if I will define the definition inside the class

Because then the compiler sees the definition when you compile your executable.

just now I try Q_DECL_EXPORT virtual QString GetExpParamTxt(QWidget*)const;. I got same error.

You did not read the link carefully... you have to export it when compiling the lib, import it when linking against as explained.

Hello,

Sorry, it took me a bit of time to make the tests:

A simple "Hello world" project runs correctly in Qt Creator? When using the external lib, the program crashes. I suspect an incompatibility of this old lib with Windows 10.
I need to further investigated this issue...

Many thanks for your help!

@raven-worx do you know of any project to "Qt-ize" the interface?

Currently they use their own String class, which makes working with it difficult

@SGaist I am not using Labview's serial port directly because of my code contain many background functionalities. It will take time to implement all in Labview. We want to just give readable data and few User interface to Labview. So user can directly use readable value and interface in Labview.