Adding "[...]/mingw73_32/bin" to PATH worked! Thank you

Are you trying to move things around in the folder where you are currently doing the application deployment ?

Hi @wimschuiteman, Peak does not distinguish between 32 and 64 bit, the library is called pcanbasic.dll in both cases. So you need to use the correct one, 32 or 64 bit, depending on your Qt architecture.

Glad you found out and thanks for sharing !

@JonB well, I thought it just creates a new build file for the new compiler (which it does), but I have to admit my understanding for compilers is not very deep.

@A-Trujillo si tu problema está solucionado, por favor no te olvides de marcar tu pregunta como tal. Muchas gracias.

@koahnig: thanks for sharing. The clean is definitely faster with jom, but apparently it looses later on time when starting for the different projects. All checks are with compilation on ram disk with 8 cores Interesting. As said, I'll do some more tests the next says and see how it behaves. For now jom is my winner. jom was not happy my environment settings MAKEFLAGS=-j8 ... but it does not need it on the other hand ;)

@Hjortronsylt Well libraries are simply not interchangable. Each library does hold a couple of objects defining typically the functionality given in the general naming. Some namings may have changed between Qt4 and Qt5, but not network to anything. Also when your application is requiring network functionality, but is missing it in the link process, you should see somewhere error messages. I would suggest that it is best when you are checking out examples from the tutorials. There are the network examples and there is the testlib functionality however, Qt offers more different aspects and it may make sense for you to check out those as well.

IIRC, the two builds are not using the same backend.

@Vagabond please don't forget to mark your post as solved... thanks.

I tried to investigate the issue further and figured out the following: it seems to be a problem with gdb and its disassembler when I start gdb in the console, it doesn't show me where the crash occurs, too in the debugger log, I get an error message "Disassembler failed" I tried also on another VM (Win 10, also) and a Win 7 Desktop and it works on the VM, however not on the Desktop and my first VM. I have no clue what the differences between these installations are :-( Is anyone aware of any Windows/Qt/MinGW settings that could make the disassembler fail? Thanks for any ideas, Sebastian

@JKSH said in MinGW Makefile project in QtCreator: Qt Creator does not call the compiler directly. It simply calls mingw32-make.exe and tells it which Makefile to use. mingw32-make.exe is the one that calls the compiler (g++.exe). The Makefile does not contain the absolute path to the compiler, so it searches your system environment to find g++.exe. Ah ok, it makes sense. So far, the only way might be QtCreator should add to the sys env of the shell the path of the selected compiler. But perhaps they rely on the knowledge of the users :)

@Technologist Which python and mingw version do you use?

Hi and welcome to devnet, AFAIK, the recent version of the QtWebView module uses the QtWebEngine module for Windows. Module that is not available for MinGW currently. Also you are are using a relatively old version of Qt so first thing you should update if possible to at least 5.8.

@CAD_coding form the official document, I think you can do it

@koahnig said in set<int> in Qt creator and debugger: E.g. are there conflicts through the various files holding settings? There might be, you will probably at least need to reconfigure the project's kits (i.e. deleting the *.pro.user files). I'd try to load them directly first though, it might work fine. @koahnig said in set<int> in Qt creator and debugger: The same problem there. It's the same data structure, so no surprise at all, indeed.

@yigene To add to @mrjj : does your app need that amount of memory? If not and it does not have memory leaks than there is no real reason to have it as 64bit.

@Chris-Kawa Sometimes you forget to update deploy dlls, in that case runtime vs compiletime versions in "about window" would be helpful. Even if you use auto windeployqt command, you'll still need to copy other dlls (OpenSSL, etc) by hand, there you'll forget.

I can only second what @ambershark says. Using a virtual machine is far less pain than what you are trying.

Hi, Did you also install Qt for MSVC2013 ?

@raven-worx @jsulm And therefore I am looking for the way how to mangle the VCRT library into my project, it's mandatory.

I did install the one coming with the Qt package, there is no other version installed.

Did you try to run your application through debugger to see why it crashes? Any error messages?

Then it's rather QNetworkAccessManager that should be of interest.

@cemaldemir07 said: I think the solution is using x64 for more stable but not exact solution. No. If you have a bug in the 32 bit version, switching to 64 bits will not change that. You need to apply yourself, find the problem and ultimately fix it.

finally i deleted import QtGraphicalEffects 1.0 import QtMultimedia 5.0 now it worked and built successfully . and apk file that i created. http://www.mediafire.com/download/1zcylimkzj2idu2/spiralmyappcompiled4android.apk thanks for attention

Use the "Topic Tool" button :)

Did you activate any kind of compiler optimization?

You're welcome ! Don't forget to remove the "not answered" from the title ;)

I did delete the build directory after it installed, so I'll do it again, and see if it works that time. I wrote a small batch file so I wouldn't have to keep retyping things: @set /p sourcedir= "Enter the source directory " @set /p mingwpath= "Enter the mingw installation path " @set /p builddir= "Enter the build directory " @set /p finaldir= "Enter the final directory " cd %builddir% call %sourcedir%\configure -prefix %finaldir% -debug-and-release -opensource -confirm-license -nomake examples -no-icu -skip webengine -opengl desktop @echo configuration finished pause call mingw32-make @echo making finished pause call mingw32-make install @echo installing finished pause I removed the bit which added to the path after I'd done that once so that I didn't end up with duplicates in my path. EDIT: Okay, it's finished making again, and it's produced exactly the same thing in the install directory (unsurprisingly). There is a qmake.exe in the build directory however, in fact the contents of the two are completely different. The install directory has the following folders: bin (4 exes and 24 dlls, nothing that has qmake in the name) include (one folder per module) lib (two folders and a load of prl files and a files) mkspec (a modules folder which contains lots of pri files) plugins (three folders, each full of dlls) The build folder has qtbase, which contains the above as well as a few other folders including a qmake folder. It also has a qmake exe in the bin folder.

You could also try with system

Hi koahnig its all working now but i get this warning: <dump of C:\QT\Qt5.5.0\5.5\mingw492_32\qml>:1:24: Reading only version 1.1 parts. <dump of C:\QT\Qt5.5.0\5.5\mingw492_32\qml>:10:5: Expected only Component and ModuleApi object definitions.

Sorry, I'm not expert in licensing issues and others bureaucracies.

After different tests and building processes I'm able to build and run an application with WebKit on Windows 10 with MinGW. I simply replaced original shipped WebKit with a fresh one from git repository. Working software versions are: MinGW-w64 5.2.0 i686 posix dwarf OpenSSL 1.0.2d zlib 1.2.8 ICU4c 55.1 Qt 5.5.0 (with fresh qtwebkit module from git) I'm using Windows 10 64bit with both Windows SDK installed and DirectX SDK (installed with DXSDK_Jun10.exe), but I think that it's possible to disable angle and force OpenGL to desktop in order to avoid installing MSVC and DirectX. I'm trying to compile the same environment on 64bit. I'll update this thread on finish.

I have the same problem with Qt 5.8 and MinGW64 6.3: C:/Program Files/mingw-w64/x86_64-6.3.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../x86_64-w64-mingw32/bin/as.exe: .obj\debug\IFCReaderGen1.o: too many sections (40453) {standard input}: Assembler messages: {standard input}: Fatal error: can't write 169 bytes to section .text of .obj\debug\IFCReaderGen1.o because: 'File too big' ~/> as.exe --version GNU assembler (GNU Binutils) 2.27 This assembler was configured for a target of `x86_64-w64-mingw32'.

Great ! I forgot that usual suspect… It's a tricky one… Thanks for sharing ! Since you have it working now, please update the thread title prepending [solved] so other forum users may know a solution has been found :)

I was thinking about an update to the dependencies from MinGW but indeed, it doesn't look like it happened.

This function is only for desktop applications. It may not exist for embedded systems. I would check if the function exist before doing anything else. If you list the exported functions from USER32 and don't see it then this explains the linker error.