Solved Deploying with embedded Python
-
Hello all,
I'm sorry my first post is about my troubles, but I'm at my wits' end.
I've been following this tutorial here to embed the Python interpreter into a regular C++ Qt Widget app. It's for Ubuntu and I'm on Windows 10 (running Qt 5.13 with MinGW btw), but I figured I could adapt things. That actually went pretty well and the app compiles and runs when I click the green start arrow in Qt Creator. Now the trouble starts when I try to run the app regularly. A double-click on it gives me this non-specific error:
(Basically, "the app couldn't start correctly")Now I've done my fair share of googling and did use the windeployqt tool and looked at the .exe with Dependency Walker, which gives me this:
And now I'm unsure whether this is a QMake problem, a Windows problem or a Python problem.
My .pro file looks like this:#------------------------------------------------- # # Project created by QtCreator 2019-09-01T15:53:18 # #------------------------------------------------- QT += core gui greaterThan(QT_MAJOR_VERSION, 4): QT += widgets TARGET = embedPython TEMPLATE = app # The following define makes your compiler emit warnings if you use # any feature of Qt which has been marked as deprecated (the exact warnings # depend on your compiler). Please consult the documentation of the # deprecated API in order to know how to port your code away from it. DEFINES += QT_DEPRECATED_WARNINGS # You can also make your code fail to compile if you use deprecated APIs. # In order to do so, uncomment the following line. # You can also select to disable deprecated APIs only up to a certain version of Qt. #DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x060000 # disables all the APIs deprecated before Qt 6.0.0 CONFIG += c++11 SOURCES += \ main.cpp \ mainwindow.cpp \ pyrun.cpp HEADERS += \ mainwindow.h \ pyrun.h FORMS += \ mainwindow.ui # Default rules for deployment. qnx: target.path = /tmp/$${TARGET}/bin else: unix:!android: target.path = /opt/$${TARGET}/bin !isEmpty(target.path): INSTALLS += target RESOURCES += \ embedpython.qrc INCLUDEPATH += C:\Users\Alexander\Anaconda3\include win32: LIBS += -LC:/Users/Alexander/Anaconda3/libs/ -lpython37 INCLUDEPATH += C:/Users/Alexander/Anaconda3/libs DEPENDPATH += C:/Users/Alexander/Anaconda3/libs win32:!win32-g++: PRE_TARGETDEPS += C:/Users/Alexander/Anaconda3/libs/python37.lib #else:win32-g++: PRE_TARGETDEPS += C:/Users/Alexander/Anaconda3/libs/libpython37.aI feel like I'm missing something obvious here... I hope some of you can help me figure out what's wrong here.
TL;DR: Trying to deploy an app with an embedded Python interpreter works fine in Qt Creator, but even after using windeployqt tool it won't start by double-clicking and has a lot of unresolved dependencies I'm reasonably sure it shouldn't have.
-
@xemnaxeras I'm not familiar with windeployqt, could you please show the output of such tool? i.e. a list of all the files (.exe, .dll, etc, etc) that windeployqt thinks should be deployed
-
This post is deleted! -
This is the cmd output:
Adding Qt5Svg for qsvgicond.dll Direct dependencies: Qt5Core Qt5Gui Qt5Widgets All dependencies : Qt5Core Qt5Gui Qt5Widgets To be deployed : Qt5Core Qt5Gui Qt5Svg Qt5Widgets Warning: Cannot find GCC installation directory. g++.exe must be in the path. Qt5Cored.dll is up to date. Qt5Guid.dll is up to date. Qt5Svgd.dll is up to date. Qt5Widgetsd.dll is up to date. libGLESV2d.dll is up to date. libEGLd.dll is up to date. D3Dcompiler_47.dll is up to date. opengl32sw.dll is up to date. Patching Qt5Cored.dll... qsvgicond.dll is up to date. qgifd.dll is up to date. qicnsd.dll is up to date. qicod.dll is up to date. qjpegd.dll is up to date. qsvgd.dll is up to date. qtgad.dll is up to date. qtiffd.dll is up to date. qwbmpd.dll is up to date. qwebpd.dll is up to date. qwindowsd.dll is up to date. qwindowsvistastyled.dll is up to date. Creating qt_ar.qm... Creating qt_bg.qm... Creating qt_ca.qm... Creating qt_cs.qm... Creating qt_da.qm... Creating qt_de.qm... Creating qt_en.qm... Creating qt_es.qm... Creating qt_fi.qm... Creating qt_fr.qm... Creating qt_gd.qm... Creating qt_he.qm... Creating qt_hu.qm... Creating qt_it.qm... Creating qt_ja.qm... Creating qt_ko.qm... Creating qt_lv.qm... Creating qt_pl.qm... Creating qt_ru.qm... Creating qt_sk.qm... Creating qt_uk.qm... Creating qt_zh_TW.qm...And this is the folder:
-
@xemnaxeras I cannot find python37.dll listed in such output from command; although it might not be listed since it's a 3rd party library, per documentation:
The application may require additional 3rd-party libraries (for example, database libraries), which are not taken into account by windeployqt.
Is it actually deployed to your target PC?
In addition, have you checked the windeployqt documentation?
-
Yeah, have read the Deployment page you linked.
Right now my target PC is the same one where I built the project. After all, if it doesn't run on the same machine where it's been built, I have no hope of ever getting it onto another.
I do believe the main problem is with all the api-ms-win-*.dll dependencies reported by Dependency Walker. I'm not quite sure why the system can't find them as they are part of Windows (located in system32/downlevel). If I go by the tutorial linked in my first post and several other things I found about embedding Python, linking as I did should be enough and python37.dll should be all that's needed.
I did copy a bunch of these api-ms-win-*.dll into the folder to check, but that make Dependency Walker report circular dependencies... -
Hi and welcome to devnet,
You should not need these system dlls even if they are mentioned in Dependency Walker.
Although already suggested, I would start by building the application from scratch (delete the build folder). Next run windeployqt. After that, use Dependency Walker to catch python3.7.dll.
Since like it still not is working, check the dependencies of the python dll. There might be something there that is missing.
-
Thank you for making me go through the whole list in Dependency Walker again. I did finally find the offending DLL. It was libstdc++-6.dll, which was reported as being x86 instead of the expected x64. When I looked at its properties, I found it was trying to load one from a gtksharp install, causing the failure. I copied the proper DLL from the minGW folder into the executable folder and now everything works like a charm. Heh. I figured it was something stupid. Thanks again!
-
You're welcome !
Since you have it working now, please mark the thread as solved using the "Topic Tools" button so that other forum users may know a solution has been found :-)
