I found out that between two cases (working and not working one) only file that differs substantially is qmlcache_loader.cpp. In non-working case it was over 5 times smaller than normally, and that's because 80% of all resources were not there. Now, the only reason why it's happened is because some qrc files has been added to RESOURCES twice, and only those resources were available at the end. Why it worked after moving file from one qrc file to another? Probably because only those part of the project which depends on that two files has been updated and though every qrc file has been included only once (duplicates was in my case in the other part of the project). EDIT: Before marking it as solved I will try to confirm all of the above hypothesis.

That error is usually happening with the shared version when an application has not been properly deployed. What do you mean shared? is that as opposed to the static build i've been trying to do? Sorry but I don't understand how your post is meant to help me. The application hasn't been 'deployed' (windeployqt? which i shouldn't need to do anyway because its meant to be static/standalone) yet because I'm still working on it in creator. The other plugins i need are now statically built / installed as was in an above response. The only thing that doesn't show up is the windows in "%QTDIR%\plugins\platforms" (I needed to add QT_QPA_PLATFORM_PLUGIN_PATH to windows environment variables) ive rebuilt the 5.12 static version multiple times now with other different configs to try to get it to work and the windows plugin simply never exists in plugins\platforms\

@JKSH Yes I did. On QT part, we followed a lot of techniques mentioned in that post. Using Loaders for lazy loading, optimizing images, using qtquickcompiler. The major challenge is on the OS boot time that we are working on.

Hi and welcome to devnet, Do you have any static QWidget based class in your library/application ?

No problem. Good luck with your project!

@koahnig SetName takes in a char* because it is a part of an API. @kshegunov Here are the relevant linker calls. I don't know how to get the .pro file from a VS project. Here is the linker call in the project that makes the dll: /OUT:"E:\Users\misappsci\Documents\Projects\yyy\x64\bin\yyy3D.dll" /MANIFEST /LTCG:incremental /NXCOMPAT /PDB:"E:\Users\misappsci\Documents\Projects\yyy\x64\bin\yyy3D.pdb" /DYNAMICBASE "sl_zed64.lib" "opencv_world310.lib" "cudart.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" "qtmain.lib" "Qt5Core.lib" "Qt5Multimedia.lib" "Qt5Gui.lib" "winmm.lib" /IMPLIB:"E:\Users\misappsci\Documents\Projects\yyy\x64\bin\yyy3D.lib" /DEBUG /DLL /MACHINE:X64 /OPT:REF /PGD:"E:\Users\misappsci\Documents\Projects\yyy\x64\bin\yyy3D.pgd" /SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"x64\3DRelease\yyy3D.dll.intermediate.manifest" /OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /LIBPATH:"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\lib\x64" /LIBPATH:"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0/lib/x64" /LIBPATH:"C:\Program Files (x86)\ZED SDK\dependencies\opencv_3.1.0/x64/vc14/lib" /LIBPATH:"C:\Program Files (x86)\ZED SDK\lib" /LIBPATH:"C:\Program Files\boost\boost_1_63_0/lib/x64" /LIBPATH:"C:\Qt\5.7\msvc2015_64\lib" /TLBID:1 Here is the linker call for the project that uses the dll and has the run time error: /OUT:"E:\Users\misappsci\Documents\Projects\Aerie\host_x64\x64\Release\AerieLib.dll" /MANIFEST /LTCG:incremental /NXCOMPAT /PDB:"E:\Users\misappsci\Documents\Projects\Aerie\host_x64\x64\Release\AerieLib.pdb" /DYNAMICBASE "Qt5Core.lib" "Qt5Gui.lib" "Qt5Multimedia.lib" "yyy3D.lib" "sl_zed64.lib" "opencv_world310.lib" "cudart.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /IMPLIB:"E:\Users\misappsci\Documents\Projects\Aerie\host_x64\x64\Release\AerieLib.lib" /DEBUG /DLL /MACHINE:X64 /OPT:REF /PGD:"E:\Users\misappsci\Documents\Projects\Aerie\host_x64\x64\Release\AerieLib.pgd" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"x64\Release\AerieLib.dll.intermediate.manifest" /OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /LIBPATH:"C:\Qt\5.7\msvc2015_64\lib" /LIBPATH:"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0/lib/x64" /LIBPATH:"C:\Program Files (x86)\ZED SDK\dependencies\opencv_3.1.0/x64/vc14/lib" /LIBPATH:"C:\Program Files (x86)\ZED SDK\lib" /LIBPATH:"E:\Users\misappsci\Documents\Projects\yyy\x64\bin" /LIBPATH:"C:\Program Files\boost\boost_1_63_0/lib/x64/" /TLBID:1

@SGaist This is so new and fresh, I love it. I'll consider making a few pull requests in the near future. :)

Indeed it did the work, it is working fine now, thank you :)

Hi, welcome to the forum. This package does not contain static Qt libraries. The .a files are used to ease the dynamic linking. On Windows there are two ways to use dynamic libraries. The first one is by calling LoadLibrary (or using QLibrary that wraps it) at runtime. It's not convenient because you need to resolve all the symbols manually this way - lots of pointless work with a huge library like Qt. The other way (preferable and used here) is to link to a library that will load and resolve the shared library (dll) at runtime for you. The .a files you listed are just that. You link to them and you still need the dlls at runtime. As for how you use them: When you create a project in Qt Creator , in your .pro file you add the modules you need in the QT variable, for example: QT += core gui widgets network. After that you just run qmake (Build->Run qmake). This handles all the linking to the right .a files for you. To have a static build (without the dlls) of Qt you need to build it manually from source package. Be aware that there are licensing restrictions for the open-sourced version of Qt when linking statically.

Thx,and it is really simple to use add library guide to add in the .dll and .lib that I want. And what I found is that maybe most of situations didn't have a .dll file for debug mode（which you can simply tell from it if has a -d suffix）,but you can use the given ones in a release mode. thx again.

Okay... finally i solved it. Nothing to do with .pro file or PLUGIN macro. It was a basic PATH issue. qmake was searching for 'plugin' directory in /PREFIX path not in /SYSROOT/PREFIX path. I just copied all plugin directory from /SYSROOT/PREFIX to /PREFIX directory. I know this may not be the right way, but it temporarily solved my issue. If someone could suggest the correct solution please let me know.

@zappy Hello. Have you looked at the bug report in the other thread you were following? Apparently there were some bug in the static building for Qt 5.5 and it's fixed in Qt 5.6.1 (https://bugreports.qt.io/browse/QTBUG-51071). So aside from upgrading, am at a loss ...

I'll try that, thanks for the help.

You can try to add your static libraries like this: LIBS += PATH_TO_LIB_DIR/libLIBNAME.lib

Hi, You should build your application on the lowest version you want to support. [edit: fixed typo SGaist]

But this time, I have a different error: /home/kumararajas/ti-sdk-am335x-evm-07.00.00.00/linux-devkit/sysroots/i686-arago-linux/usr/bin/../lib/gcc/arm-linux-gnueabihf/4.7.3/../../../../arm-linux-gnueabihf/bin/ld: /home/kumararajas/Integrate_UI/G-CPU/lib/libuicorelib.a(uicontroller.o): undefined reference to symbol '__cxa_begin_catch@@CXXABI_1.3' /home/kumararajas/ti-sdk-am335x-evm-07.00.00.00/linux-devkit/sysroots/i686-arago-linux/usr/bin/../lib/gcc/arm-linux-gnueabihf/4.7.3/../../../../arm-linux-gnueabihf/bin/ld: note: '__cxa_begin_catch@@CXXABI_1.3' is defined in DSO /home/kumararajas/ti-sdk-am335x-evm-07.00.00.00/linux-devkit/sysroots/i686-arago-linux/usr/bin/../arm-linux-gnueabihf/libc/lib/arm-linux-gnueabihf/libstdc++.so.6 so try adding it to the linker command line /home/kumararajas/ti-sdk-am335x-evm-07.00.00.00/linux-devkit/sysroots/i686-arago-linux/usr/bin/../arm-linux-gnueabihf/libc/lib/arm-linux-gnueabihf/libstdc++.so.6: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status make[4]: *** [bin/FireApp] Error 1 make[3]: *** [libraries] Error 2 make[2]: *** [libraries] Error 2 make[1]: *** [libraries] Error 2 This looks like standard library compatibility issue. Any thoughts on this?

Basically no, there is always some type of license for Qt libs in place. Either you use LPGL for no cost or a commercial license. However, this is the same as with any other SW around. Please check out the different options for licenses.