Qt 5.1.1: Impossibile avviare l'applicazione perché manca il plug-in della piattaforma "Windows"

Modifica: alcune persone hanno iniziato a contrassegnare la mia domanda come duplicata. Non dimenticare che molte domande simili esistevano quando le ho posto questa (vedi ad esempio la lista qui sotto). Tuttavia, nessuna di queste risposte ha risolto il mio problema . Dopo una lunga ricerca ho trovato un commento che era stato ignorato da tutti gli utenti che puntavano alla lib mancante. Ora, molti mesi dopo, il commento è stato cambiato in una risposta. Tuttavia, quando ho risposto a questa domanda da solo intendevo aiutare gli altri fornendo direttamente la soluzione. Questo non dovrebbe essere dimenticato e finora la mia risposta ha aiutato molte persone. Pertanto la mia domanda non è assolutamente un duplicato. A proposito: la risposta accettata all'interno del link fornito in alto non risolve il problema !

Sì, ho usato la ricerca:

Caricamento del plug-in della piattaforma "Windows" non riuscito. Le piattaforme disponibili sono: Errore

Distribuzione dell'applicazione Qt C ++ dall'errore qwindows.dll di Visual Studio

impossibile caricare il plug-in della piattaforma "windows" Le piattaforme disponibili sono: windows, minimal

Tuttavia, nel mio caso il problema persiste ancora. Sto usando Qt 5.1.1 con Visual Studio 2012 e ho sviluppato la mia applicazione su Windows 7 con Qt Creator 2.8.1. L'applicazione viene compilata in modalità "Rilascio" e può essere eseguita se avviata direttamente con Qt Creator.

Tuttavia, a partire dalla cartella "release", ricevo il seguente messaggio:

Impossibile avviare questa applicazione perché non è stato possibile trovare o caricare il plug-in della piattaforma Qt "Windows". I plugin disponibili per la piattaforma sono: minimal, offscreen, windows.

La struttura delle cartelle è simile alla seguente:

release
+ gui.exe
+ icudt51.dll
+ icuin51.dll
+ icuuc51.dll
+ libGLESv2.dll
+ Qt5Core.dll
+ Qt5Gui.dll
+ Qt5Widgets.dll
+ platforms

Platforms è la cartella copiata direttamente dalle piattaforme Qt \ Qt5.1.1 \ 5.1.1 \ msvc2012 \ plugins \, incluso ad esempio qwindows.dll. Non importa se lo rinomino in "piattaforma" come hanno fatto altri utenti. Qt non sta ancora trovando la "finestra del plugin della piattaforma", dov'è il mio errore?

Ok, come pubblicato qui https://stackoverflow.com/a/17271172/1458552 senza molta attenzione da parte di altri utenti:

Il libEGL.dll mancava! Anche se questo non è stato segnalato durante il tentativo di avviare l'applicazione (erano stati segnalati tutti gli altri * .dll come Qt5Gui.dll).

Ho creato una directory di piattaforme vicino alla mia posizione exe e ho inserito qwindows.dll all'interno, ma ho ancora ricevuto l'errore "Impossibile caricare il plug-in della piattaforma" Windows ". Le piattaforme disponibili sono: windows".

Avevo copiato qwindows.dll da piattaforme C: \ Qt \ Qt5.1.1 \ Tools \ QtCreator \ bin \ plugins \, che non è la posizione giusta. Ho esaminato il registro di debug in esecuzione in Qt Creator e ho scoperto che la mia app stava cercando nelle piattaforme C: \ Qt \ Qt5.1.1 \ 5.1.1 \ mingw48_32 \ plugins \ quando era in esecuzione nel debugger.

Quando ho copiato dalle piattaforme C: \ Qt \ Qt5.1.1 \ 5.1.1 \ mingw48_32 \ plugins \, tutto ha funzionato bene.

Probabilmente nella versione manca una libreria / plug-in oppure la libreria si trova nella directory errata e / o nella directory errata.

Qt risposta prevista: utilizzare windeployqt . vedere l'ultimo paragrafo per una spiegazione

Risposta manuale:

Creare una cartella denominata "piattaforme" nella stessa directory del file application.exe. Copia e incolla il qwindows.dll, che si trova nel / bin di qualsiasi compilatore che hai usato per rilasciare la tua applicazione, nella cartella "piattaforme". Funziona come per magia. Se il .dll non è presente, controlla plugin / piattaforme / (con plugin / trovandosi nella stessa directory di bin /) <- Commento di PfunnyGuy.

Sembra che un problema comune sia che il .dll è stato preso dal cestino del compilatore sbagliato. Assicurati di copiare il qwindows.dll dallo stesso compilatore di quello utilizzato per rilasciare la tua app.

Qt viene fornito con le applicazioni della console della piattaforma che aggiungeranno tutte le dipendenze (comprese quelle come qwindows.dll e libEGL.dll) nella cartella del file eseguibile distribuito. Questo è il modo previsto per distribuire la tua applicazione, quindi non perdere nessuna libreria (che è il problema principale con tutte queste risposte). L'applicazione per Windows si chiama windeployqt . Probabilmente esiste un'app console di distribuzione per ciascun sistema operativo.

L'impostazione della QT_QPA_PLATFORM_PLUGIN_PATHvariabile di ambiente su% QTDIR% \ plugins \ platform \ ha funzionato per me .

È stato anche menzionato qui e qui .

Mi sono imbattuto in questo e nessuna delle risposte che ho potuto trovare risolto per me.

Il mio collega ha Qt (5.6.0) installato sulla sua macchina in: C: \ Qt \ Qt5.6.0 \ 5.6 \ msvc2015 \ plugins
Ho Qt (5.6.2) installato nella stessa posizione.

Ho imparato da questo post: http://www.tripleboot.org/?p=536 , che Qt5Core.dll ha una posizione per i plugin scritti su di esso quando Qt viene installato per la prima volta. Poiché le directory dei miei colleghi e Qt erano uguali, ma erano installate versioni diverse di Qt, è necessario un diverso file qwindows.dll. Quando eseguivo un exe da lui distribuito, utilizzava il mio file C: \ Qt \ Qt5.6.0 \ 5.6 \ msvc2015 \ plugins \ platform \ qwindows.dll invece di quello che si trova accanto all'eseguibile nella sottocartella. \ Platform.

Per ovviare a questo, ho aggiunto la seguente riga di codice all'applicazione che sembra costringerlo a cercare nell'exe la sottocartella 'piattaforme' prima che guardi il percorso in Qt5Core.dll.

QCoreApplication::addLibraryPath(".");

Ho aggiunto la riga precedente al metodo principale prima della chiamata QApplication in questo modo:

int main( int argc, char *argv[] )
{
    QCoreApplication::addLibraryPath(".");
    QApplication app( argc, argv );
    ...
    return app.exec();
}

crea dir platforms e copia qwindows.dllsu di esso, platformse app.exesono nella stessa dir

cd app_dir mkdir platforms xcopy qwindows.dll platforms\qwindows.dll

Struttura delle cartelle + app.exe + platforms\qwindows.dll

Ho trovato un'altra soluzione. Crea qt.conf nella cartella dell'app come tale:

[Paths]
Prefix = .

Quindi copia la cartella dei plugin nella cartella dell'app e funziona per me.

La maggior parte di queste risposte contiene buone informazioni (corrette), ma nel mio caso mancava ancora qualcosa.

La mia app è costruita come libreria (dll) e chiamata da un'applicazione non Qt. In passato windeployqt.exeinstallavo le dll, le piattaforme, i plug-in di Qt nella directory di installazione, ma non riuscivo ancora a trovare la piattaforma. Dopo alcuni esperimenti, mi sono reso conto che la directory di lavoro dell'applicazione era impostata su una cartella diversa. Quindi, ho preso la directory in cui la dll "viveva" usando GetModuleHandleExAe ho aggiunto quella directory al percorso della libreria Qt in fase di runtime usando

QCoreApplication::addLibraryPath(<result of GetModuleHandleExA>);

Questo ha funzionato per me.

Per me la soluzione era correggere la PATHvariabile. Aveva Anaconda3 \ Library \ bin come uno dei primi percorsi. Questa directory contiene alcune librerie Qt, ma non tutte. Apparentemente, questo è un problema. Spostando C: \ Programmi \ Qt \ 5.12.3 \ msvc2017_64 \ bin in primo PATHpiano ho risolto il problema per me.

Ho avuto questo problema durante l'utilizzo di QT 5.6, Anaconda 4.3.23, python 3.5.2 e pyinstaller 3.3. Avevo creato un programma Python con un'interfaccia sviluppata usando QTcreator, ma dovevo distribuirlo su altri computer, quindi dovevo creare un eseguibile, usando pyinstaller.

Ho scoperto che il problema è stato risolto sul mio computer se ho impostato le seguenti variabili di ambiente:

QT_QPA_PLATFORM_PLUGIN_PATH:% QTDIR% \ plugins \ platform \

QTDIR: C: \ Miniconda3 \ pkgs \ qt-5.6.2-vc14_3 \ Library

Ma questa soluzione ha funzionato solo sul mio PC con conda e qt installati in quelle cartelle.

Per risolvere questo problema e far funzionare il file eseguibile su qualsiasi computer, ho dovuto modificare il ".spec" (file generato per primo da pyinstaller) per includere la seguente riga:

datas = [('' C: \ Miniconda3 \ pkgs \ qt-5.6.2-vc14_3 \ Library \ plugins \ platform * .dll ',' platform '),]

Questa soluzione si basa sulle risposte di Jim G. e CrippledTable

Ho avuto lo stesso problema e l'ho risolto applicando diverse cose. Il primo, se è un programma che hai fatto con Qt.

Nella cartella (nel mio caso) di "C: \ Qt \ Qt5.10.0 \ 5.10.0 \ msvc2017_64 \ plugins" trovi altre cartelle, una di queste è "piattaforme". La cartella "piattaforme" verrà copiata accanto all'eseguibile .exe. Ora, se ricevi l'errore 0xc000007d è che non hai copiato la versione che era, dal momento che può essere 32 bit o 64.

Se si continua con gli errori è che mancano più librerie. Con il programma "Dependency Walker" è possibile rilevare alcune delle cartelle mancanti. Sicuramente ti indicherà che hai bisogno di una NVIDIA .dll e ti dice la posizione.

Un altro modo, invece di utilizzare "Dependency Walker" è copiare tutti i file DLL dalla cartella "C: \ Windows \ System32" accanto al file eseguibile. Esegui il tuo .exe e se tutto si carica bene, quindi non hai spazio occupato nelle librerie DLL che non ti servono o non usi, usa il programma .exe con tutte le tue opzioni e senza chiudere il file .exe che fai cancella tutto. dll che hai appena copiato accanto a .exe, quindi se quei .dll vengono utilizzati dal tuo programma, il sistema non ti permetterà di cancellare, rimuovendo solo quelli che non sono necessari.

Spero che questa soluzione ti serva.

Ricorda che se il tuo sistema operativo è a 64 bit, le librerie saranno nella cartella System32 e se il tuo sistema operativo è a 32 bit, saranno anche nella cartella System32. Ciò accade in modo che non vi siano problemi di compatibilità con programmi a 32 bit in un computer a 64 bit. La cartella SysWOW64 contiene i file a 32 bit come backup.

Per una piattaforma MinGW e se si sta compilando un target di debug da un CMakeLists.txt scritto ad hoc, è necessario aggiungere anche qwindows.dll alla directory della piattaforma. L'eseguibile windeployqt funziona bene ma sembra che per qualche strana ragione anche la build CMake abbia bisogno della variante di rilascio. In breve, sarà meglio avere sia qwindows.dll che qwindowsd.dll nella directory della piattaforma. Non ho notato lo stesso strano risultato durante l'importazione del progetto CMake in QtCreator e durante l'esecuzione della procedura di compilazione. Compilando dalla riga di comando il progetto CMake sembra attivare la dipendenza qwindows.dll o se è impostata quella corretta per la destinazione Debug (qwindowsd.dll)

Utilizzare questo file batch: RunWithQt.bat

@echo off
set QTDIR=C:\Qt\Qt5.1.1\5.1.1\msvc2012\bin
set QT_QPA_PLATFORM_PLUGIN_PATH=%QTDIR%\plugins\platforms\
start %1

• per usarlo, trascina il tuo file gui.exe e rilascialo su RunWithQt.bat in explorer,
• o chiama RunWithQt gui.exedalla riga di comando

Se hai installato Anaconda, ti consiglio di disinstallarlo e provare a installare il pacchetto python dalla fonte, ho risolto questo problema in questo modo

L'applicazione qtbase / bin / windeployqt.exe distribuisce automaticamente l'applicazione. Se si avvia un prompt con envirenmentvariables impostato correttamente, viene distribuito nella directory corrente. Trovi un esempio di script:

@echo off
set QTDIR=E:\QT\5110\vc2017

set INCLUDE=S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\ATLMFC\include;S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\include;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um;C:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\ucrt;C:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\shared;C:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\um;C:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\winrt;C:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\cppwinrt

set LIB=S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\ATLMFC\lib\x86;S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\lib\x86;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\lib\um\x86;C:\Program Files (x86)\Windows Kits\10\lib\10.0.14393.0\ucrt\x86;C:\Program Files (x86)\Windows Kits\10\lib\10.0.14393.0\um\x86;

set LIBPATH=S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\ATLMFC\lib\x86;S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\lib\x86;S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\lib\x86\store\references;C:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.17134.0;C:\ProgramFiles (x86)\Windows Kits\10\References\10.0.17134.0;C:\Windows\Microsoft.NET\Framework\v4.0.30319;

Path=%QTDIR%\qtbase\bin;%PATH%
set VCIDEInstallDir=S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\VC\
set VCINSTALLDIR=S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\
set VCToolsInstallDir=S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.11.25503\
set VisualStudioVersion=15.0
set VS100COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\
set VS110COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools\
set VS120COMNTOOLS=S:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\
set VS150COMNTOOLS=S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\Tools\
set VS80COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\Tools\
set VS90COMNTOOLS=c:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\
set VSINSTALLDIR=S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\
set VSSDK110Install=C:\Program Files (x86)\Microsoft Visual Studio 11.0\VSSDK\
set VSSDK150INSTALL=S:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VSSDK
set WindowsLibPath=C:\Program Files (x86)\Windows Kits\10\UnionMetadata;C:\Program Files (x86)\Windows Kits\10\References
set WindowsSdkBinPath=C:\Program Files (x86)\Windows Kits\10\bin\
set WindowsSdkDir=C:\Program Files (x86)\Windows Kits\10\
set WindowsSDKLibVersion=10.0.14393.0\
set WindowsSdkVerBinPath=C:\Program Files (x86)\Windows Kits\10\bin\10.0.14393.0\
set WindowsSDKVersion=10.0.14393.0\
set WindowsSDK_ExecutablePath_x64=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\x64\
set WindowsSDK_ExecutablePath_x86=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\

mkdir C:\VCProjects\Application\Build\VS2017_QT5_11_32-Release\setup
cd C:\VCProjects\Application\Build\VS2017_QT5_11_32-Release\setup
copy /Y ..\Release\application.exe .
windeployqt application.exe
pause

Diciamo, volevi avere alcune demo CGAL portatili. Quindi avresti una cartella "CGAL", e in essa una sottocartella chiamata "lib": tutte le (comuni) support-dll per tutti i programmi nella cartella CGAL vanno qui. Nel nostro esempio, questo sarebbe il Dll-Download : decomprimere semplicemente nella directory "lib". Più scorri verso il basso sulla pagina delle demo , più il contenuto è impressionante. Nel mio caso, la demo dei poliedri sembrava a posto. Se questo funziona sul mio notebook da 10+ anni, sono impressionato. Così ho creato una cartella "demo" nella directory "CGAL", insieme a "lib". Ora crea un file .cmd in quella cartella. Ho chiamato il mio "Polyhedron.cmd". Quindi abbiamo una struttura di directory come questa:

 CGAL - the bag for all the goodies
  lib - all libraries for all CGAL-packages
 demo - all the demos I'm interested in
[...] - certainly some other collections, several apps per folder...
Polyhedron.cmd - and a little script for every Qt-exe to make it truly portable.

In questo piccolo esempio, "Polyhedron.cmd" contiene il seguente testo:

@echo off
set "me=%~dp0"
set PATH=%me%lib
set "QT_PLUGIN_PATH=%me%lib\plugins"
start /b "CGAL Polyhedron Demo" "%me%demo\polyhedron\polyhedron_3.exe"

Tutti gli script possono essere uguali a parte l'ultima riga, ovviamente. L'unica avvertenza è: la "finestra DOS" rimane aperta per tutto il tempo in cui si utilizza il programma attuale. Chiudi la finestra della shell e uccidi anche * .exe. Ovunque copiate la cartella "CGAL", poiché la strana "% ~ dp0" -wriggle rappresenta il percorso completo del file * .cmd che abbiamo iniziato, con "\" finale. Quindi "% me% lib" è sempre il percorso completo della libreria effettiva ("CGAL \ lib" nel mio caso). Le successive 2 righe indicano a Qt dove sono i suoi file "runtime". Questo sarà almeno il file "qwindows.dll" per i programmi Windows-Qt più un numero qualsiasi di * .dlls. Se ricordo bene, la libreria Dll (almeno quando l'ho scaricata) aveva un piccolo "bug" poiché conteneva la directory "piattaforme" con qwindows.dll.passare a "plugin". Se un'app Qt, qualsiasi app Qt, non trova "qwindows.dll", non riesce a trovare "windows". E lo aspetta in una directory denominata "piattaforme" nella directory "plugins", che deve essere comunicato al sistema operativo in esecuzione ... e se "QT_PLUGIN_PATH" non punta esattamente a tutte le helper-dll necessità, alcuni programmi Qt funzioneranno ancora senza probi. E alcuni si lamentano della mancanza di * .dll che non hai mai sentito dire ...

Per chiunque provenga dalla versione QT 5.14.0, mi ci sono voluti 2 giorni per trovare questo pezzo di bug bug:

windeployqt non funziona per MinGW QTBUG-80763 Sarà risolto in 5.14.1

https://wiki.qt.io/Qt_5.14.0_Known_Issues

Quindi attenzione. L'uso di windeployqt con MinGW darà lo stesso errore indicato qui.