问题
I had a (previously working and compiling for months) set of MEX files. I updated my 3-month-old packages (which worked fine before with GCC/G++) with a pacman -Syu, and now here are my results:
For GCC/G++:
- O0 - MEX file is "invalid"
- O1-O2 - works
- O3 - "optimizes" away the entire program. A simple mexPrintf() in the right spot fixes this by forcing it not to optimize it away
For Clang:
- Nothing works, all optimization levels result in invalid mexfile
For TDM-GCC:
- Works flawlessly regardless of the optimization level
OS: Win 10, latest updates
Language: C++03
MATLAB Version: R2016B (without Update 7, though tested with, didn't help)
(Changing C++ or MATLAB versions is not an option, it's a client requirement)
MINGW64 GCC version: 9.2.0
TDM GCC version: 5.1.0-2
Compiling with mex isn't an option at the moment. (I made a new post about it here)
Here's what it looks like when the c++ object files are made:
g++ -c -IC:/Progra~1/MATLAB/R2016b/extern/include -I(some library we made) -g3 -O0 -m64 -DFLIP_MEX_DEBUG=1 -DFLIP_C -ansi -Wshadow -Wall -DMX_COMPAT_32 -DMATLAB_MEX_FILE -fexceptions -fno-omit-frame-pointer -D__WIN32__ myFile.cpp -o myFile.o
Here's what the C object files look like:
gcc -c -IC:/Progra~1/MATLAB/R2016b/extern/include -I(some library we made) -g3 -O0 -m64 -DFLIP_MEX_DEBUG=1 -DFLIP_C -ansi -Wshadow -Wall -DMX_COMPAT_32 -DMATLAB_MEX_FILE -fexceptions -fno-omit-frame-pointer -D__WIN32__ myFile2.c -o myFile2.o
Here's what it looks like when the MEX files are made from that object file:
g++ -m64 -shared -Wl,-Bsymbolic -Wl,--no-undefined -Wl,C:/Progra~1/MATLAB/R2016b/extern/lib/win64/mingw64/exportsmexfileversion.def -o myFile.mexw64 myFile.o (various .o files linked in here) -pthread -LC:/Progra~1/MATLAB/R2016b/bin/win64 -LC:/Progra~1/MATLAB/R2016b/extern/lib/win64/mingw64 -lmex -lmx
I noticed the following differences in what the mex command attempts and what we do:
Differences for the object file:
- We're using mingw G++ compiler, they use TDM
(swapping didn't fix it) - They include simulink/include, we do not. (adding didn't fix it)
- They use -O. Does that mean -O1? -O2? -O3? Unclear.
Differences for the mex file:
- We're using mingw G++ compiler, they use TDM
(swapping didn't fix it) - They had -s, we did not (Tried adding it, didn't fix anything)
- They had -llibmx -llibmex -llibmat -lm -llibmwlapack -llibmwblas, we did not. (Tried adding them, did not fix anything)
- They did NOT have -lmex -lmx (removing didn't fix it)
- We have -Wl,-Bsymbolic they do not (removing it didn't fix anything)
Obscure compiler issue is not my specialty. Anyone have any suggestions as to what might be the issue here?
回答1:
Switching to TDM-GCC fixed the issue with mex files being invalid when compiled with -O0. Nothing else (despite the other differences I noticed) apparently mattered.
My mistake (I think) is that I swapped out G++ for TDM-G++, but did not also do so for GCC, and there are several C files in the repo.
As for compiling with MEX, that issue is also solved in the linked question, so it's an option as well.
EDIT: The issue seems to lie with GCC being updated over time. In any case, with -o0 it still creates an invalid mex file. With -o1-2 it's fine, with -o3 it omits important parts of the code unless a dummy print statement is added. I've found that the best balance is to set it to compile DEBUG with TDM-GCC/G++, and use GCC's latest for all else.
来源：https://stackoverflow.com/questions/57577372/updated-packages-now-mex-files-compiled-with-o0-are-invalid-mex-file