Error
Currently using this to compile my C++ program:
x86_64-w64-mingw32-g++ -std=c++11 -c main.cpp -o main.o -I../include x86_64-w64-mingw32-g++ main.o -o mainWin.exe -L/usr/lib/x86_64-linux-gnu/ -L/usr/local/lib -lopengl32 -lglfw32 -lGLEW -lX11 -lXxf86vm -lXrandr -lpthread -lXi -DGLEW_STATIC
I am using Mingw to compile my C++ program from Linux (Ubuntu) to a Windows executable. I am relatively new to compiling via command line, but I would like to switch my work environment completely over to Linux.
When I attempt to compile the program, I get the following error:
*** Error in `/usr/bin/x86_64-w64-mingw32-ld`: free(): invalid pointer: [removed]*** ld terminated with signal 6 [Aborted], core dumped
I believe this is because of my build of GLEW. Whenever I make it, it wants to use a mingw32msvc version of mingw. I think I need it to use x86_64-w64-mingw32-gcc. I cannot figure out how to make it do this (if even possible).
Extra
It’s also worth noting that I only get this error with GLEW_STATIC defined at the top of main.cpp. Without it, I get undefined references to GLEW.
Advertisement
Answer
It seems that you were using the -lGLEW flag when you’re supposed to use -lglew32s/lglew32! Make sure to #define GLEW STATIC if you are statically linking…and get the appropriate binaries from their website.
If the loader (or any program) is crashing, then check to see whether you are using the most recent version. If not, get hold of the newest version and try again. If that doesn’t resolve it, can you find an older version and use that? If you can’t easily find a version that works, you need to report the bug to the relevant team — at MinGW or the bin-utils team at GNU. Is 32-bit compilation an option? If so, try that. You’re in a hole; it will probably take some digging to get yourself out.
This problem seems to occur in 2016, even though the question is from 2014. It is a little surprising that the problem has not been fixed yet — assuming that the flawed free being run into in 2016 is the same as the one that occurred in 2014. If the loader now in use dates from (say) 2013-early 2015, then there’s probably an update and you should investigate it. If the loader now in use dates from mid-2015 onwards, it is more likely (or, if that’s too aggressive, then it is at least possible) that it is a different bug that manifests itself similarly.
The advice to “try an upgrade if there is one available; if that doesn’t work, see whether you can find a working downgrade” remains valid. It would be worth trying to create an MCVE (Minimal, Complete, and Verifiable Example) and reporting the bug to the maintenance teams — as was suggested by nodakai in 2014. The smaller the code you use, and the fewer libraries you need, the easier it will be for the maintenance teams to discover the problem and fix it. If it is a cross-compiler running on Linux for MinGW, then you still need to minimize the code and report the issue.
Note that if you can find a ‘known-to-work’ version, that will probably be of interest to the maintainers. It localizes where they need to look a bit.
I should note that even if the library in use is the wrong library, the loader still shouldn’t crash with the free error. It can report a problem and stop under control. It should not crash. It may still be worth reporting that it does crash.
In many ways, this is just generic advice on what to do when you encounter a bug in software.