更新了软件包，现在用-O0编译的Mex文件是“无效的mex文件"? [英] Updated packages, now Mex files compiled with -O0 are "invalid mex file"?

问题描述

我有一组(以前工作和编译了几个月)的MEX文件.我用pacman -Syu更新了3个月大的软件包(在GCC/G ++之前可以正常工作)，现在是我的结果:

对于 GCC/G ++ :

• O0-MEX文件无效"
• O1-O2-起作用
• O3-优化"整个程序.正确位置处的一个简单的mexPrintf()通过强制它不要对其进行优化来解决此问题

对于 Clang :

• 没有任何效果，所有优化级别都会导致无效的mexfile

对于 TDM-GCC :

• 无论优化级别如何，都能完美工作

操作系统:Win 10，最新更新

语言:C ++ 03

MATLAB版本:R2016B(未经更新7，尽管经过测试，但无济于事)

(不能更改C ++或MATLAB版本，这是客户要求)

MINGW64 GCC版本:9.2.0

TDM GCC版本:5.1.0-2

当前无法使用mex进行编译. (我在此处上发布了一篇新文章) >

这是制作c ++对象文件时的样子:

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

这是C对象文件的样子:

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

这是从该目标文件生成MEX文件时的样子:

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

我注意到mex命令尝试执行的操作与我们所做的操作存在以下差异:

目标文件的区别:

• 我们使用的是mingw G ++编译器，他们使用的是TDM (交换并不能解决问题)
• 它们包含simulink/include，但我们不包含. (添加并不能解决问题)
• 他们使用-O.这是否意味着-O1? -O2? -O3?不清楚.

mex文件的区别:

• 我们使用的是mingw G ++编译器，他们使用的是TDM (交换并不能解决问题)
• 他们有-s，我们没有(尝试添加，没有解决任何问题)
• 他们有-llibmx -llibmex -llibmat -lm -llibmwlapack -llibmwblas，我们没有. (尝试添加它们，但未解决任何问题)
• 他们没有-lmex -lmx(删除没有解决该问题)
• 我们有-Wl，-Bsymbolic他们没有(删除它没有解决任何问题)

晦涩的编译器问题不是我的专长.任何人对这里可能出现的问题有任何建议吗?

解决方案

切换到 TDM-GCC 解决了使用-O0编译时mex文件无效的问题.显然没什么(尽管我注意到其他差异).

我的错误(我认为)是我将G ++换成TDM-G ++，但也没有换成GCC，并且仓库中有几个C文件.

对于使用MEX进行编译，该问题也在链接的问题中得到了解决，因此也是一种选择.

问题似乎在于随着时间的推移更新了GCC.无论如何，使用-o0仍会创建无效的mex文件.使用-o1-2很好，使用-o3可以省略代码的重要部分，除非添加了伪打印语句.我发现最好的平衡是将其设置为使用TDM-GCC/G ++编译DEBUG，并将GCC的最新版本用于所有其他方面.

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?

解决方案

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.

这篇关于更新了软件包，现在用-O0编译的Mex文件是“无效的mex文件"?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！