Available platform plugins are windows. Hoping there is something because I can't access any games 'This application failed to start because it could not find or load the Qt platform plugin 'windows' in ''. Available platform plugins are minimal, windows Reinstalling the app may fix this problem creating a restore point didn't work microsoft help didn't help reinstalling didn't help. (Want to skip the tourist talk? Jump to the rest of the post.)How to fix 'Could not find the Qt platform plugin Windows in ' when implementing qgis in custom Python3 application Ask Question Asked 2 years, 9 months agoThis app failed to start because it could not find or load the Qt platform plugin 'windows' in'. 'This application failed to start because it could not find or load the Qt platform plugin 'windows'.' due to an AdskLicensingAgent issue appears when launching or updating any Autodesk software 'Failed to create OpenGL context for format QSurfaceFormat' when launching Autodesk products(Same here, Finder only says “App quit unexpectedly”, launch your app in Terminal to see this)If the Pycharm console or debugger are showing Could not find or load the Qt platform plugin windows, the Python EXE file may be located at a different.Repair or update the 'Single Sign On Component' (AdSSO) following the solution in 'This application failed to start because it could not find or load the Qt platform plugin 'windows'.' dialogue appears when launching or updating any Autodesk software (It may be required to delete C:Program FilesAutodeskAutodesk AdSSO folder completely after.
H files that are designed this way (a humongous file like Windows.h is frowned upon) to the delegation of. But deployment problems are more or less nonexistent.Qt has (as you’ve probably discovered) the complete opposite design. People sometimes complain though, because even a simple ‘Hello World’ app weighs in to an approx. EXE file with minimal dependencies on the DLLs, in Windows for example it’s just the usual suspects like KERNEL32.DLL etc. After you’ve written and debugged a Go program, you issue the go build command.
To simplify this blog post, let’s focus on the online installer. You can use the online or the offline installer. In some environments that makes sense or is required (like when deplyoing Qt apps to iOS/iPhone) but let’s begin with the simple version: distributing Qt using DLLs/shared files.First let’s look at the stuff you get when you download and install Qt. For example, the MaintenanceTool app included in your Qt’s root directory is built that way (as well as Qt’s online/offline installer programs). Exe could constitute a career-limiting move) but probably mostly because it supports so many different architectures and OS’es.Now, to simplify deployment of Qt apps to other PCs, you can build your app together with Qt statically. Partially this stems from the early 90’s when Qt was initially designed (in those days, deploying a 2MB.
Inside that directory will be a couple of subdirectories, like Examples, Docs and Licenses. The files installed will be the same anyway, let’s assume you go with the online installer and accept the default directory name Qt. The offline installer instead will default to a version specific directory, for Qt 5.5.1 it will prompt you with something like C:\Qt\Qt5.5 for MinGW on Windows.
Click through and accept all the default choices. In Qt Creator, select a new Project, Applications and a Qt Widgets application. (And inside it are the important bin, lib and plugins subdirectories, more on that later.)So let’s start by looking at deployment of an absolute bare bones app, let’s call it HelloQt. I’ll be referring to that one as the compiler directory in this blog post. Instead, look in the other directory created, for Qt 5.5.1 it’s 5.5 it contains a subdirectory named after the compiler you selected, like clang_64, gcc_64, mingw492_32, msvc2013 etc., that’s where you’ll find the compiler specific Qt files which can be distributed safely to other computers.
Could Not Find Qt Platform Plugin Windows .Dll And Msvcp120
The HelloQt app should now run equally well on the other computer.Again: note that the 32-bit MSVC DLL files are in SysWOW64 and the 64-bit files are in System32. Let’s not forget the 2 compiler specific files msvcr120.dll and msvcp120.dll, I usually copy them from C:\Windows\SysWOW64 on my development PC.For 64-bit app deployment the file setup above is identical, but beware: the 2 compiler files msvcr120.dll and msvcp120.dll you instead find in C:\Windows\System32. Depending on your OS and compiler, the files you then need to copy vary slightly:Bare bones 32-bit and 64-bit platforms directoryThe qwindows.dll file is in compiler directory \plugins\platforms and the other files you’ll find in compiler directory \bin. Just build our fancy app in Qt Creator, then make a test directory on another computer without any Qt installed. DLLs to another computer.Right now don’t edit or add any code, for our purposes an empty app window will do just fine. This is to simplify deployment, and if you’re using Visual Studio as your compiler, Microsoft disallows copying any of the debug.
Succumbing to this fear, it was decided that for all 64-bit Windows releases, System32 was to be the home for the 64-bit infrastructure and the old (32-bit) content of System32 was instead to be ignominiously shuffled away into a new subdirectory called SysWOW64. The belief was that the necessary migration to System64 would cause intolerable pain and suffering and perhaps taint the perceived quality of the Windows product. But alas, it was not to be 🙁 Because a fear had spread upon the land, a fear that System32 had become too popular and too ingrained. The naive among us expected the creation of a 3rd subdirectory called System64, for housing the new fancy 64-bit Windows infrastructure. All was well again and rejoicing resumed.A new century and 64-bit computing arrived. Solution: put those files in another System subdirectory and call that (surprise!) System32.
Usually this is because you copied msvcr120.dll and/or msvcp120.dll from the wrong directory (either C:\Windows\System32 or C:\Windows\SysWOW64, also see my rant above).Q: “I copied everything ok, but when I try to launch I get a dialog box: “not a valid Win32 application” why?”If the other computer has Windows XP or Windows Server 2003 you’ll get this error. A 32-bit app loads by mistake a 64-bit DLL. Q: “I copied the msvcr120.dll and msvcp120.dll files as you said, why do I get error 0xc000007b when I try to launch my app on the other computer?”This error occurs when a 64-bit app requests a DLL and a 32-bit version of it is incorrectly loaded, or the other way around, i.e. If a System64 directory had been created there would be less confusion. Until all 32-bit Windows installations are gone, every day some developer will have to think and spend extra time deciding which directory is correct for picking up the compiler files and similar stuff. (BTW, a similar kind of decision was also taken for C:\Program Files, so that it would contain the 64-bit apps and 32-bit apps would instead be stored in C:\Program Files (x86).) And that’s the story how we ended up with 32-bit DLLs in SysWOW64 and 64-bit DLLs in System32.Today, more than 10 years later, I think giving in to that fear was a humongous mistake.
The libc.so, libgcc_s.so etc files. So files, it’s assumed the Linux system you’re targeting is up to scratch re. There are no compiler specific. The other files are in the compiler directory /lib directory (note: not the bin directory as on Windows above). Visual Studio 2013 32-bit and 64-bit OpenGL compilers:Debian/Ubuntu GCC bare bones deployment, platform directoryHere the platform file is called libqxcb.so, it can be found in compiler directory /plugins/platforms.
(That’s why it’s only one of each above in the screen dumps.) This keeps the no. 5, when I copy the files I also rename the real McCoy file from xxx.5.4.0 to xxx.5 and toss the 3 symbolic chaps. So files are suffixed with just. LibQt5Core.so, libQt5Core.so.5 and libQt5Core.so.5.4 are symbolic links to the “real” file libQt5Core.so.5.4.0.However, when you list HelloQt’s DLL dependencies, for example typing "ldd HelloQt" in Terminal, you’ll see that the requested. So files in the /lib subdirectories are installed by the Qt installer in 4 incarnations: 3 symbolic links and 1 real McCoy, e.g.
Even though we’ve copied all the needed. So files assuming the same library path to them as on your development machine. Exe/ELF file is built to look for Qt’s. So we’re applying the same algorithm here, copied and renamed the 3 real files and skipped the symbolic links.When you copy the files shown above to another Linux computer, if you try to launch the HelloQt app you’ll most likely get this error:(On Ubuntu systems the app might run anyway because a fairly recent Qt is included in their distro, more on that below.)The reason for this is that the. But you can of course equally well go ahead and copy all 4 of them.Update: in Qt 5.4, I noticed that the 3 libicu*.so Unicode files now are installed in 2 incarnations, one *.so.53 which is the symbolic link (the one HelloQt looks for) and the *.so.53.1 which is the real thing.
So files are ignored in Linux.
0 kommentar(er)
