Qt 5.1.1: Nie udało się uruchomić aplikacji, ponieważ brakuje wtyczki platformy „windows”

Edycja: Niektórzy ludzie zaczęli oznaczać moje pytanie jako duplikat. Nie zapominaj, że istniało wiele podobnych pytań, kiedy zadawałem to pytanie (patrz np. Lista poniżej). Jednak żadna z tych odpowiedzi nie rozwiązała mojego problemu . Po długich poszukiwaniach znalazłem komentarz, który został zignorowany przez wszystkich użytkowników wskazujących na brakującą bibliotekę. Teraz, wiele miesięcy później, komentarz zmienił się w odpowiedź. Jednak kiedy sam odpowiedziałem na to pytanie, miałem zamiar pomóc innym ludziom poprzez bezpośrednie dostarczenie rozwiązania. Nie należy o tym zapominać i jak dotąd moja odpowiedź pomogła wielu osobom. Dlatego moje pytanie zdecydowanie nie jest powtórzeniem. Przy okazji: zaakceptowana odpowiedź w podanym linku na górze nie rozwiązuje problemu !

Tak, użyłem wyszukiwania:

Nie udało się załadować wtyczki platformy „windows”. Dostępne platformy to: Błąd

Wdrażanie aplikacji Qt C ++ z błędu qwindows.dll programu Visual Studio

nie udało się załadować wtyczki platformy "windows" Dostępne platformy to: windows, minimalne

Jednak w moim przypadku problem nadal występuje. Używam Qt 5.1.1 z Visual Studio 2012 i stworzyłem moją aplikację w systemie Windows 7 z Qt Creator 2.8.1. Aplikacja jest kompilowana w trybie „Release” i może zostać uruchomiona bezpośrednio w programie Qt Creator.

Jednak podczas uruchamiania z folderu „release” -Folder otrzymuję następujący komunikat:

Ta aplikacja nie została uruchomiona, ponieważ nie mogła znaleźć ani załadować wtyczki platformy Qt „windows”. Dostępne wtyczki platformy to: minimal, offscreen, windows.

Struktura folderów wygląda następująco:

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

Platforms to folder bezpośrednio kopiowany z Qt \ Qt5.1.1 \ 5.1.1 \ msvc2012 \ plugins \ platform, w tym np. Qwindows.dll. Nie ma znaczenia, czy zmienię jego nazwę na „platforma”, jak to zrobili niektórzy inni użytkownicy. Qt nadal nie znajduje "okien wtyczek platformy", gdzie jest mój błąd?

W porządku, jak opublikowano tutaj https://stackoverflow.com/a/17271172/1458552 bez większej uwagi innych użytkowników:

Brak pliku libEGL.dll ! Mimo że nie zostało to zgłoszone podczas próby uruchomienia aplikacji (zgłoszono wszystkie inne pliki * .dll, takie jak Qt5Gui.dll).

Utworzyłem katalog platform obok mojej lokalizacji exe i umieściłem w nim qwindows.dll, ale nadal otrzymałem komunikat „Nie udało się załadować wtyczki platformy” okna. Dostępne platformy to: windows.

Skopiowałem plik qwindows.dll z C: \ Qt \ Qt5.1.1 \ Tools \ QtCreator \ bin \ plugins \ platform, co nie jest właściwą lokalizacją. Spojrzałem na dziennik debugowania z uruchamiania w Qt Creator i stwierdziłem, że moja aplikacja szukała w C: \ Qt \ Qt5.1.1 \ 5.1.1 \ mingw48_32 \ plugins \ platform, gdy była uruchomiona w debugerze.

Kiedy skopiowałem z C: \ Qt \ Qt5.1.1 \ 5.1.1 \ mingw48_32 \ plugins \ platform, wszystko działało dobrze.

W wydaniu prawdopodobnie brakuje biblioteki / wtyczki lub biblioteka znajduje się w niewłaściwym katalogu lub z niewłaściwego katalogu.

Zamierzona odpowiedź Qt: Użyj windeployqt . wyjaśnienie znajduje się w ostatnim akapicie

Odpowiedź ręczna:

Utwórz folder o nazwie „platformy” w tym samym katalogu, w którym znajduje się plik application.exe. Skopiuj i wklej plik qwindows.dll, który znajduje się w katalogu / bin dowolnego kompilatora, którego użyłeś do wydania aplikacji, do folderu „platform”. Działa jak magia. Jeśli nie ma pliku .dll, sprawdź wtyczki / platformy / (z wtyczkami / znajdujące się w tym samym katalogu co bin /) <- komentarz PfunnyGuy.

Wydaje się, że częstym problemem jest to, że plik .dll został pobrany z niewłaściwego bin kompilatora. Pamiętaj, aby skopiować plik qwindows.dll z tego samego kompilatora, który został użyty do wydania aplikacji.

Qt zawiera aplikacje konsoli platformy, które dodają wszystkie zależności (w tym takie, jak qwindows.dll i libEGL.dll) do folderu wdrożonego pliku wykonywalnego. Jest to zamierzony sposób wdrażania aplikacji, aby nie przegapić żadnej biblioteki (co jest głównym problemem w przypadku wszystkich tych odpowiedzi). Aplikacja dla systemu Windows nazywa się windeployqt . Prawdopodobnie istnieje aplikacja konsoli wdrażania dla każdego systemu operacyjnego.

Ustawienie QT_QPA_PLATFORM_PLUGIN_PATHzmiennej środowiskowej na% QTDIR% \ plugins \ platform \ działało dla mnie .

Wspomniano o tym również tutaj i tutaj .

Wpadłem na to i żadna z odpowiedzi, które mogłem znaleźć, nie pomogła mi.

Mój kolega ma zainstalowany Qt (5.6.0) na swoim komputerze w: C: \ Qt \ Qt5.6.0 \ 5.6 \ msvc2015 \ plugins.
Mam Qt (5.6.2) zainstalowany w tym samym miejscu.

Dowiedziałem się z tego posta: http://www.tripleboot.org/?p=536 , że Qt5Core.dll ma lokalizację do wtyczek zapisywanych do niego podczas pierwszej instalacji Qt. Ponieważ katalogi mojego współpracownika i mojego Qt były takie same, ale zainstalowano inną wersję Qt, potrzebny jest inny plik qwindows.dll. Kiedy uruchomiłem wdrożony przez niego exe, użyłby mojego pliku C: \ Qt \ Qt5.6.0 \ 5.6 \ msvc2015 \ plugins \ platform \ qwindows.dll zamiast tego znajdującego się obok pliku wykonywalnego w podfolderze. \ Platform.

Aby obejść ten problem, dodałem do aplikacji następujący wiersz kodu, który wydaje się wymuszać na niej wyszukanie obok pliku exe podfolderu „platformy”, zanim spojrzy na ścieżkę w Qt5Core.dll.

QCoreApplication::addLibraryPath(".");

Dodałem powyższą linię do głównej metody przed wywołaniem QApplication w następujący sposób:

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

utwórz dir platforms i skopiuj qwindows.dlldo niego, platformsi app.exesą w tym samym reż

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

Struktura folderów + app.exe + platforms\qwindows.dll

Znalazłem inne rozwiązanie. Utwórz plik qt.conf w folderze aplikacji w następujący sposób:

[Paths]
Prefix = .

A następnie skopiuj folder wtyczek do folderu aplikacji i działa dla mnie.

Większość z tych odpowiedzi zawiera dobre (poprawne) informacje, ale w moim przypadku nadal czegoś brakowało.

Moja aplikacja jest zbudowana jako biblioteka (dll) i wywoływana przez aplikację inną niż Qt. Kiedyś windeployqt.exeustawiałem biblioteki DLL Qt, platformy, wtyczki itp. W katalogu instalacyjnym, ale nadal nie mogłem znaleźć platformy. Po kilku eksperymentach zdałem sobie sprawę, że katalog roboczy aplikacji został ustawiony na inny folder. Więc złapałem katalog, w którym "żyła" biblioteka dll GetModuleHandleExAi dodałem ten katalog do ścieżki biblioteki Qt w czasie wykonywania, używając

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

To zadziałało dla mnie.

Dla mnie rozwiązaniem była korekta PATHzmiennej. Miał Anaconda3 \ Library \ bin jako jedną z pierwszych ścieżek. Ten katalog zawiera niektóre biblioteki Qt, ale nie wszystkie. Najwyraźniej to jest problem. Przeniesienie C: \ Programs \ Qt \ 5.12.3 \ msvc2017_64 \ bin na początek PATHrozwiązało problem.

Miałem ten problem podczas korzystania z QT 5.6, Anaconda 4.3.23, python 3.5.2 i pyinstaller 3.3. Stworzyłem program w języku Python z interfejsem opracowanym przy użyciu QTcreator, ale musiałem wdrożyć go na innych komputerach, dlatego musiałem stworzyć plik wykonywalny, używając pyinstaller.

Stwierdziłem, że problem został rozwiązany na moim komputerze, jeśli ustawię następujące zmienne środowiskowe:

QT_QPA_PLATFORM_PLUGIN_PATH:% QTDIR% \ plugins \ platform \

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

Ale to rozwiązanie działało tylko na moim komputerze, który miał zainstalowane conda i qt w tych folderach.

Aby rozwiązać ten problem i sprawić, by plik wykonywalny działał na dowolnym komputerze, musiałem edytować plik „.spec” (plik najpierw wygenerowany przez pyinstaller), aby zawierał następujący wiersz:

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

To rozwiązanie jest oparte na odpowiedziach Jima G. i CrippledTable

Miałem ten sam problem i rozwiązałem go, stosując kilka rzeczy. Pierwsza, jeśli jest to program, który zrobiłeś z Qt.

W folderze (w moim przypadku) „C: \ Qt \ Qt5.10.0 \ 5.10.0 \ msvc2017_64 \ plugins” znajdują się inne foldery, jednym z nich są „platformy”. Ten folder „platformy” zostanie skopiowany obok pliku wykonywalnego .exe. Teraz, jeśli pojawi się błąd 0xc000007d, oznacza to, że nie skopiowałeś wersji, która była, ponieważ może to być 32 bity lub 64.

Jeśli będziesz kontynuować z błędami, oznacza to, że brakuje Ci większej liczby bibliotek. Za pomocą programu „Dependency Walker” możesz wykryć niektóre brakujące foldery. Z pewnością wskaże ci, że potrzebujesz pliku NVIDIA .dll i wskaże ci lokalizację.

Innym sposobem, zamiast używania „Dependency Walker”, jest skopiowanie całego pliku .dll z folderu „C: \ Windows \ System32” obok pliku wykonywalnego. Uruchom plik .exe i jeśli wszystko ładuje się dobrze, więc nie masz miejsca zajętego w bibliotekach dll, których nie potrzebujesz lub nie używasz, użyj programu .exe ze wszystkimi opcjami i bez zamykania pliku .exe, który wykonujesz, wymaż wszystkie pliki. dll, który właśnie skopiowałeś obok .exe, więc jeśli te pliki .dll są używane przez twój program, system nie pozwoli ci skasować, usuwając tylko te, które nie są konieczne.

Mam nadzieję, że to rozwiązanie Ci służy.

Pamiętaj, że jeśli twój system operacyjny ma 64 bity, biblioteki będą znajdować się w folderze System32, a jeśli twój system operacyjny ma 32 bity, będą one również znajdować się w folderze System32. Dzieje się tak, że nie ma problemów ze zgodnością z programami 32-bitowymi na komputerze 64-bitowym. Folder SysWOW64 zawiera 32-bitowe pliki jako kopię zapasową.

W przypadku platformy MinGW i jeśli kompilujesz element docelowy debugowania za pomocą ręcznie utworzonego pliku CMakeLists.txt napisanego ad hoc, musisz również dodać qwindows.dll do katalogu platformy. Plik wykonywalny windeployqt działa dobrze, ale wydaje się, że z jakiegoś dziwnego powodu kompilacja CMake również potrzebuje wersji wydania. Podsumowując, lepiej będzie mieć zarówno qwindows.dll, jak i qwindowsd.dll w katalogu swojej platformy. Nie zauważyłem tego samego dziwnego wyniku podczas importowania projektu CMake w QtCreator, a następnie uruchamiania procedury kompilacji. Kompilowanie w wierszu poleceń projektu CMake wydaje się wyzwalać zależność qwindows.dll, jeśli ustawiono prawidłowy element docelowy debugowania (qwindowsd.dll)

Użyj tego pliku wsadowego: 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

• aby go użyć, przeciągnij plik gui.exe i upuść go na RunWithQt.bat w eksploratorze,
• lub zadzwoń RunWithQt gui.exez wiersza poleceń

Jeśli masz zainstalowaną Anacondę, radzę odinstalować ją i spróbować zainstalować pakiet Pythona ze źródła, naprawiłem ten problem w ten sposób

Aplikacja qtbase / bin / windeployqt.exe automatycznie wdraża Twoją aplikację. Jeśli uruchomisz monit z prawidłowo ustawionymi zmiennymi środowiska, zostanie on wdrożony w bieżącym katalogu. Znajdziesz przykład skryptu:

@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

Powiedzmy, że chciałeś mieć przenośne wersje CGAL-Demos . Miałbyś więc folder „CGAL”, a w nim 1 podfolder o nazwie „lib”: wszystkie (wspólne) pliki dll obsługujące dowolne programy w folderze CGAL znajdują się tutaj. W naszym przykładzie byłby to plik Dll-Download : po prostu rozpakuj do katalogu „lib”. Im dalej przewijasz stronę demonstracyjną , tym bardziej imponująca jest zawartość. W moim przypadku demo z wielościanem wydawało się właściwe. Jeśli to działa na moim 10+ letnim notebooku, jestem pod wrażeniem. Utworzyłem więc folder „demo” w katalogu „CGAL”, obok „lib”. Teraz utwórz plik .cmd w tym folderze. Nazwałem mój „Polyhedron.cmd”. Mamy więc taką strukturę katalogów:

 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.

W tym małym przykładzie „Polyhedron.cmd” zawiera następujący tekst:

@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"

Oczywiście wszystkie skrypty mogą być takie same, z wyjątkiem ostatniej linii. Jedynym zastrzeżeniem jest to, że "okno DOS" pozostaje otwarte tak długo, jak używasz właściwego programu. Zamknij okno powłoki i zabij również plik * .exe. Gdziekolwiek skopiujesz folder "CGAL", jako że dziwny "% ~ dp0" -wriggle reprezentuje pełną ścieżkę do pliku * .cmd, który rozpoczęliśmy, z końcowym "\". Zatem „% me% lib” jest zawsze pełną ścieżką do aktualnej biblioteki (w moim przypadku „CGAL \ lib”). Następne 2 wiersze mówią Qt, gdzie znajdują się jego pliki „runtime”. Będzie to przynajmniej plik „qwindows.dll” dla programów Windows-Qt oraz dowolna liczba plików * .dll. Jeśli dobrze pamiętam, biblioteka Dll (przynajmniej kiedy ją ściągnąłem) miała mały "błąd", ponieważ zawiera katalog "platform" z qwindows.dll w nim.przejść do „wtyczek”. Jeśli aplikacja Qt, żadna aplikacja Qt nie znajdzie „qwindows.dll”, nie może znaleźć „windows”. I oczekuje go w katalogu o nazwie „platform” w katalogu „wtyczki”, o którym musi otrzymać informację od systemu operacyjnego, na którym działa… i jeśli „QT_PLUGIN_PATH” nie wskazuje dokładnie na wszystkie biblioteki DLL pomocnicze potrzeby, niektóre programy Qt będą nadal działać bez problemów. Niektórzy narzekają na brakujące pliki * .dll, o których nigdy nie słyszałeś ...

Każdemu, kto pochodzi z QT w wersji 5.14.0, zajęło mi 2 dni znalezienie tej informacji o błędzie:

windeployqt nie działa dla MinGW QTBUG-80763 Zostanie naprawione w 5.14.1

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

Więc bądź świadomy. Użycie windeployqt z MinGW da ten sam błąd, co tutaj.