This is I guess a question in a few parts.
I'm working through the documentation on embedding the python interpreter. I've got everything compiling and linking wonderfully, only the application crashes when I run it ( to be specific its unable to load, so it hasn't even begun running).
I'm running windows 7 professional 64 bit. I'm compiling on the most recent nightly build of mingw, with msys ( which was packaged with the installer so no compatibility mismatch there I believe). The same code compiles fine on Ubuntu 10.10 using the default repository python 3.1 and build-essential tools.
So far in my research I'm believing this "might" be an issue between linking a 32 bit application ( as mingw is using 32 bit to my knowledge) with a 64 bit library (the python dll).
I can post code in full, however since this tends to be a linking/running issue I've only included the makefile to begin with. From the makefile below, I have copied the Python3.dll from C:\Python32\DLLs into the directory of my project. Also of note, that I had to create my own .def and then .a from the DLL in order to link ( symbols not found otherwise). Could this be a source of my issues?
Upon running a.exe (from both command line and explorer) I receive a standard alert window with:
Application Error: The application was unable to start correctly (0xc000007b). Click OK to close the application.
Correct me if I'm wrong, but this indicates that my executable is in some way corrupted.
I have tested my compiler/linker to ensure that it isn't a compiler/linker issue. It includes and this does NOT throw any errors on compiling, linking or running when the application does not use python.
Thanks for any assistance or light you can shed on the matter. This has me truly stumped.
pcnerd
Makefile
FILE= main.cpp
LIBS= -lpython3
LIBPATH= -L/c/python32/libs
INCLUDEPATH = -I/c/python32/include
CPP=g++
FLAGS = -g
build:
$(CPP) $(FLAGS) $(FILE) $(LIBS) $(LIBPATH) $(INCLUDEPATH)
If the python3.dll is definitely 64bit and your application is definitely 32bit, then this will not work. You can't link to 64bit dlls from 32bit applications. Pointers just won't be able to work between the two models.
You can't mix 32 and 64 bit images in the same process. End. Of. Story.
Related
I've recently started using Msys2 to install gcc compiler to make some exe for Windows. It works very well, but there's a problem when passing my exe to my brother. His laptop has not msys2 installed and when he tries to run my exe some errors occur. Seems like few dll files are necessary to use my exe (like msys-2.0.dll).
I've found out that those files are used by msys2 to "fake" the OS on the machine pretending it's a POSIX one. Is there a way to compile standalone exe for windows with msys2? I would like my brother to be able to use my exe without installing msys or else.
Here are all the details to understand better my situation:
g++ HelloWord.cpp -o Helloword is the line I use to compile
C:\msys64\mingw64\bin here's the path where g++ is stored
All the exact error messages I receive from windows after double clicking on the exe file that has been generated. Note that these messages do not appear on the CMD, but in a classic Windows error pop-up:
The program can't start because msys-2.0.dll is missing from your computer.
Try reinstalling the program to fix this problem.
The program can't start because libstdc++-6.dll is missing from your computer.
Try reinstalling the program to fix this problem.
The program can't start because libgcc_s_seh-1.dll is missing from your computer.
Try reinstalling the program to fix this problem.
Fixed:
I've resolved the issue just using the g++ parameter -static. Is it an overkill?
My version of MinGW is a bit old ...
C:\example>where g++
C:\misc\mingw810_64\bin\g++.exe
C:\example>g++ --version
g++ (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
But same idea:
C:\example>cat > compile_me.cpp
#include <iostream>
int main () { std::cout << "hi" << std::endl; }
^Z
C:\example>g++ compile_me.cpp -o compiled.exe
C:\example>compiled.exe
hi
C:\example>dumpbin /dependents compiled.exe
...
Image has the following dependencies:
KERNEL32.dll
msvcrt.dll
libstdc++-6.dll
...
In that case (dynamically linked stdlib) you'd deploy libstdc++6.dll with the executable, installing it to the same path as the exe (the other two are generally present in the windows system path).
If you want to drop that dependency, use -static:
C:\example>g++ compile_me.cpp -o compiled.exe -static
C:\example>compiled.exe
hi
C:\example>dumpbin /dependents compiled.exe
...
Image has the following dependencies:
KERNEL32.dll
msvcrt.dll
...
Deploying that .exe alone should be fine.
The file size will be larger but that's not a huge deal these days. Also your MinGW / MSYS install might come with strip:
C:\example>dir compiled.exe
Volume in drive C is Windows
Volume Serial Number is D2BA-C6F0
Directory of C:\example
09/24/2022 06:49 PM 2,389,120 compiled.exe
1 File(s) 2,389,120 bytes
0 Dir(s) 135,945,314,304 bytes free
C:\example>strip compiled.exe
C:\example>dir compiled.exe
Volume in drive C is Windows
Volume Serial Number is D2BA-C6F0
Directory of C:\example
09/24/2022 07:03 PM 838,656 compiled.exe
1 File(s) 838,656 bytes
0 Dir(s) 135,944,765,440 bytes free
C:\example>compiled.exe
hi
If there are other dynamic libraries that your particular executable ends up depending on, and the vendor has chosen not to provide statically linked alternatives, then you'll have to just deploy them with the exe. It's generally easy enough to just throw everything in a zip file or use your favorite scriptable installer.
(Note: dumpbin ships with Visual Studio; and can be found in some appropriate subdirectory in VC\Tools in the vs install path).
MSYS2 compiles native PE32 executables. It does not rely on any magic msys environment or static linking.
Get yourself a dependency walker and look to see what DLLs your app needs to run. Anything not in a Windows subdirectory should be where you focus your attention. Also make sure your app does not require any special Microsoft redistributable dependencies.
Ultimately, you should be creating an installer for your application to handle dependencies. I personally like Inno setup, but plenty of others exist that are well liked also.
The OP has solved their problem but for anyone else who finds this:
Make sure you launch MSYS2 by clicking on mingw64.exe or the equivalent shortcut.
Run which g++ to make sure you are using /mingw64/bin/g++. If it shows some other g++ then run pacman -S mingw-w64-x86_64-toolchain to install the toolchain.
Compile your code with g++ and use the -static option.
Run ntldd yourprogram.exe to check which DLLs your program is using and make sure they are part of Windows, not part of MSYS2.
I am trying to run the example samples/sgemm.cpp from the CLBlast repo on
Windows 10 with a Nvidia graphics card. I have obtained the cl.hpp from the link. The makefile is simply as follows:
a.exe: sgemm.cpp
g++ sgemm.cpp -lopencl -clblast -O0 -g -DCL_TARGET_OPENCL_VERSION=300
I have the Nvidia CUDA toolkit v11.6 installed and the include directory is on the environment variable CPATH so that it is found by g++. Furthermore, the compiler is part of a Mingw-w64 installation on which clblast is installed.
The problem is that the compilation seems to succeed, but as soon as I try executing the a.exe it crashes without any error message. Similarly, attaching gdb does not help either, because the program exits immediatedly and gdb prints
During startup the program exited with code 0xc0000135.
What is the problem?
Update
I have opened an issue on the clblas github. Note that I can compile clinfo from here without problems. A missing library therefore should not be the first thing that comes to my mind.
To answer this, this was not a problem with gdb, a.exe or the CUDA toolkit but rather with the installed library which is build with Visual Studio. The resulting binary seems to be incompatible with g++. Therefore, installing the library from source using g++ fixed this.
I am trying to compile a 32-bit application on 64-bit Debian Stretch. I have compiled several other applications successfully this way, but one app that uses the pcap library is giving me problems. There does not seem to be a 32-bit version of this library anywhere for my platform.
Problem description
When I try to link my application, like this:
g++ (...objectfiles-and-options...) -m32 -o myapp -lpthread -lpcap
I get the error
/usr/bin/ld: cannot find -lpcap
I checked, and there is indeed no libpcap.so (or variant thereof) in /usr/lib32. However, all other libraries I am using is present there (like libpthread). I tried to create soft-links to the 64-bit pcap-libraries in there, just in case they should be multi-platform compatible, but that only resulted in "skipping incompatible /usr/lib32/libpcap.so when searching for -lpcap".
I've installed libpcap-dev, libc6-dev-i386, gcc-multilib and g++-multilib (obviously, since cross-compilation works fine for all applications that does not use libpcap). I would suspect there should be a libpcap-dev-i386 I could install, but there does not seem to be one.
Perhaps I should mention that the application compiles and links successfully as 64 bit.
Does anyone know what I am missing here?
You can compile libpcap yourself. It's probably the better solution than depending on packages.
Use configure for 32bit architecture and than give your compiler LDFLAGS pointing to your lib or install it in /usr/lib32/
EDIT 1
This seems to be related to linking to the mono library, once I remove any kind of reference to mono code and remove the linking to the library from my CMakeList.txt file, debugging works as expected.
EDIT 2
Okay, I've discovered something interesting. This actually might not have anything to do with how I am linking libraries, it appears to be directly related to how I am initialising a class in my unit test. For whatever reason, if I use my normal syntax of TypeDeclaration variableName; the unit test fails immediately with the error code 0xc0000135, but if I change it to read TypeDeclaration variableName(); the code will run. Only problem is that I then get a warning stating empty parenthesis interpreted as a function declaration. I came from linux using g++ to compile my code and there was never an issue, now all of a sudden trying to compile on windows using cygwin or mingw means I can't use the normal standard c++ syntax to actually do work...
Edit 3
I've discovered that this issue is occurring because the libraries I am dependent on aren't actually being copied into the build directory of my unit test project. If I manually copy the required libraries into my build directory debugging works as expected, will need to learn how to express this requirement in CMakeList.txt
More Details
CLion Specifics
CLion 2018.3.1
Build #CL-183.4588.63, built on December 5, 2018
JRE: 1.8.0_152-release-1343-b16 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0
Toolchain Settings
Cygwin 32 bit version 2.11.2
CMake version 3.13.1
Make version 4.2.1
gcc version 7.3.0
Debugger Cygwin GDB version 8.1.1
catch.hpp for unit testing.
Problem
When debugging a unit test, CLion reports the following error:
During startup program exited with code 0xc0000135.
Google returns a lot of Qt and netbeans related results, everyone suggests to add C:\mingw\bin to the system PATH variable. However I am not using mingw I am using cygwin. I tried adding C:\cygwin\bin to my PATH directory but that does not help. I also tried switching toolchain to use mingw to see if that would help. but the same problem occurs with debugging.
Not sure what else I can do to proceed in resolving this one, any ideas would be most welcome.
I've downloaded Qt 4.8.2 library, Qt Creator 2.5.2, and manually installed MingW with w32api version 3.13 and GCC/g++ version 4.7.0.1. My OS is Windows 7 Ultimate x64.
I can create a sample "Plain C++ project" in Qt Creator; compile and run that console application using g++ without any issue.
But I cannot run a Qt application. I used Qt Creator, created a dummy Qt Application using Creator's "Qt Gui Application" template. The project can be compiled successfully, without any error or warning. But the binary keeps crashing when I try to run (both from Qt Creator and Windows Explorer) it. Both debug and release builds crash. It crashes even before showing main window.
MingW is installed in C:\MingW and C:\MingW\bin is in PATH. Qt is installed in C:\Qt\4.8.2 and C:\Qt\4.8.2\bin is in PATH.
I analyzed generated exe of the Qt Gui Application output with Dependency Walker and found that it found all required DLLs:
c:\windows\system32\KERNEL32.DLL
c:\windows\system32\MSVCRT.DLL
c:\mingw\bin\LIBGCC_S_DW2-1.DLL
c:\mingw\bin\LIBSTDC++-6.DLL
c:\qt\4.8.2\bin\QTCORE4.DLL
c:\qt\4.8.2\bin\QTGUI4.DLL
So, what's causing the runtime crash?
EDIT
I also tried Qt's example projects: 2dpainting and addressbook - both crashed when they were launched.
You should build Qt with the MinGW compiler you're using to build your application. GCC is generally less sensitive to binary compatibility issues than MSVC is, but Qt is a big, complex framework library. If anything would expose those kinds of issues, Qt would probably be on the short list.
Building Qt is pretty straightforward, but it takes a lot of time and there always seems to be two or three patches I need to make to get things to build successfully.
The last time I built Qt (4.7.3) with MinGW, I had to make the following patches - I'm not sure whether they will still apply to Qt 4.8:
make sure not to enable C++11 mode in the compiler - there are several macros with concatenated string literals that break under the new C++11 extended literal syntax
there is a problem with how some distributions of MinGW incorporate the Microsoft extensions to float.h - I had to sometimes had to add the line:
#include_next <float.h>
to the end of the MinGW-specific float.h so the generic GCC float.h would get processed properly. I had to do this for nuwen 4.7.0 lib/gcc/i686-pc-mingw32/4.7.0/include/float.h and TDM 4.6.1 32-bit distro lib/gcc/mingw32/4.6.1/include/float.h (the 64-bit distro of TDM didn't need this patch).
patch qmake\Makefile.win32-g++ and qmake\Makefile.win32-g++-sh to remove the -static-libstdc++ option that GCC doesn't recognize (and now errors out on instead of ignores)
patch mkspecs/win32-g++/qmake.conf to move the -Wl, in the QMAKE_LFLAGS_EXCEPTIONS_ON macro to its proper place in QMAKE_FLAGS:
QMAKE_LFLAGS = -Wl,-enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc
QMAKE_LFLAGS_EXCEPTIONS_ON = -mthreads
copy make.exe to mingw32-make.exe in MinGW's bin directory if there's not already a mingw32-make.exe
Then building Qt consists of:
set QTDIR=<location of Qt source directory> # where configure.exe is
set PATH=%QTDIR%\bin;c:\MinGW\bin;%PATH%
set INCLUDE=
set LIB=
cd %QTDIR%
mingw32-make confclean # (this should fail the first time, since there's nothing to clean)
configure.exe -opensource -debug-and-release -nomake examples -nomake demos -nomake tests -platform win32-g++ # and accept the GPL license
mingw32-make
This takes a while... hopefully nothing else will need patching.
I also got this problem. I'm a Qt n00b and tought, when installing Qt-libraries, that "well I already have Mingw installed so I skip installing the Mingw that comes with Qt". That gave me prolems. When installing mingw that came with Qt everything worked ok.
So my advice to anyone googling to this question (like I did) is to instead of using your already installed Mingw, install the one with Qt and use that (otherwise you have to build the Qt libraries within your Mingw, like the answer from Michael Burr)