mingw-w64

问题 On Windows, if I start c:\msys64\mingw64.exe , it opens a shell, where I can build my project, let's say by calling a release bash script (to simplify). Everything works fine. Now, I would like to execute my release script on mingw64 directly, without interaction. I tried: c:\msys64\mingw64.exe /c/the/full/path/release A window opens and closes, it does not work. I attempted to use bash directly, but it seems the environment is not correctly set: > c:\msys64\usr\bin\bash -c ls /usr/bin/bash:

问题 I need to use some symbols from the main executable in a plugin. Linking against the executable causes the following linker errors: i686-w64-mingw32-g++ example.cpp -shared -I.. -std=c++11 -o test.dll ../../test.exe -static-libgcc -static-libstdc++ -fvisibility=hidden [..]/test.exe:cygming-crtbegin.c:(.text+0x500): multiple definition of `__gcc_register_frame' /usr/lib/gcc/i686-w64-mingw32/5.1.0/crtbegin.o:cygming-crtbegin.c:(.text+0x0): first defined here [..]/test.exe:cygming-crtbegin.c:(

问题 I'm porting a Linux script to Windows & MinGW, which accesses the Android phone through ADB. Sometime I need to pass the Android's file path as ADB command line option. However, when invoking the ADB.exe, MinGW translates it to Windows' path. For example, adb shell cat /proc/version Is translated as follows, resulting "No such file or directory" error in Android. adb shell cat C:/Program Files (x86)/Git/proc/version I found double-quotation helps to prevent that. adb shell "cat /proc/version"

问题 I have a union that looks like this union bareVec8f { __m256 m256; //avx 8x float vector float floats[8]; int ints[8]; inline bareVec8f(){ } inline bareVec8f(__m256 vec){ this->m256 = vec; } inline bareVec8f &operator=(__m256 m256) { this->m256 = m256; return *this; } inline operator __m256 &() { return m256; } } the __m256 needs to be aligned on 32 byte boundary to be used with SSE functions, and should be automatically, even within the union. And when I do this bareVec8f test = _mm256_set1

问题 I compiled a Linux software in MinGW64 (MSYS2) on Windows with gcc-6.3.0 and gcc-gnat-6.3.0. I would like to assemble an installer package or zip file, that contains all necessary files. What parts of MinGW are required at a destination machine? I don't want to ship a complete MSYS2/MinGW64, because it has 3 GiB! The executable has only 10 MiB. I also won't demand a user to install MSYS2 and MinGW64, because it's a nightmare to install it on a Windows machine. The package manager (pacman) is

问题 I'd like to use Eclipse IDE for C++ dev but these is one little prob. First, a little boiler plate: mingw 64bit C++ compiler (Custom compilation A) mingw 64bit C++ compiler (Custom compilation B) windows host The problem I can not get it to work with multiple toolchains. All info I could find suggested that eclipse requires mingw dir to be at C:\mingw\ that does not work for my use case. For one, I have multiple custom compiled mingw compiler tools. I can at most put one at C:\mingw\

问题 I am trying to create multiple streams in portaudio. This is what it requires for opening a stream PaError Pa_OpenDefaultStream( PaStream** stream, int numInputChannels, int numOutputChannels, PaSampleFormat sampleFormat, double sampleRate, unsigned long framesPerBuffer, PaStreamCallback *streamCallback, void *userData ); and this is the PaStreamCallback function. typedef int PaStreamCallback( const void *input, void *output, unsigned long frameCount, const PaStreamCallbackTimeInfo* timeInfo,

问题 After reading a lot of literature on the internet, it seems that recent GCC versions definitely support the -std=c++11 command line option. But for some crazy reason, I get the "unrecognized command line option" even when using GCC 4.8.1 which doesn't make any sense. C:\newmingw\mingw32\bin>g++ -v Using built-in specs. COLLECT_GCC=g++ Target: i686-w64-mingw32 Configured with: [trimmed] Thread model: win32 gcc version 4.8.1 (rev5, Built by MinGW-W64 project) C:\newmingw\mingw32\bin>g++ -std=c+

问题 I'm trying to compile C library for python on Windows7 (64-bit) using mingw-x64. It all worked like a charm with 32-bit versions. I used to compile my library with gcc -shared -IC:\Python27\include -LC:\Python27\libs myModule.c -lpython27 -o myModule.pyd and it worked with 32-bit versions. The same procedure is working with 64-bit linux. But on 64-bit windows7 (using 64-bit x86_64-w64-mingw32 and 64-bit python 2.7.5) I have a problem: C:\Users\sergej\AppData\Local\Temp\cci8TbXw.o:myModule.c:(

问题 Intuitively: MinGW-w64 is a Windows port of the GNU compiler tools (GCC, etc.). Pre-compiled binaries for Windows are .dll (dynamic linking) / .lib (static linking). However, MinGW-w64 uses the GNU compiler tools, it would follow that .so / .a binaries are required. What I've Found: According to Red Hat Enterprise Linux documentation, seems that MinGW/MinGW-w64/Cygwin linkers look for .dlls and .as According to this tutorial, you should dynamically link to .so and statically link to .a . One