An issue with Matlab for a mex file compiled with GNU CYGWIN g++

[Emad Gad]

Hello

I apologize that this message is a long one. But you may skip to the question at the end, if you wish to know the troubles I am having.

I have been using LINUX for a very long time.
I decided to compile my work on CYGWIN. Furthermore, I wanted to compile a Matlab interface to be able to use it from Matlab under Windows.

I succeeded, after plodding for a whole weekend, in compiling everything, without errors.

The problem came when I tried to run the matlab interface, which is the usual .mexw64 (on the recent versions of Matlab) file that is produced by the mex uttility in Matlab. At that moment, Matlab complained of “Invalid mex file: [the file name].mexw64 is not a valid Win32 application”

I know that, up until now, the problem does not seem even remotely related to CYGWIN.

However, investigating and reading around the web about this issue further has led me to conclude that Matlab will generate this error if the .mexw64 the dll in question refers or uses other 32 bit dll. Matlab presumably cannot run a hybrid dll, that is a dll with 64 and 32 bits components.

I then used the “Dependency Walker” tool to examine the components of my .mexw64. And I found out that my “.mexw64” file is linked to the following library C:\Windows\system32\kernel32.dll, which is a flagrantly 32 bit Windows system dll. So I assumed that this must be the reason that Matlab failed to run the mex file, and wanted to know why this library got linked in the first place.

That brings me to the CYGWIN connection: The CYGWIN linker that I invoked to finish the job is the g++-4, which has added the library kernel32.dll, with the linker flag –lkernel32.dll. Notice that this linker flag has been aded by the linker, and not by me. It also added the 32-bit Windows path on the Library paths, and that is how I ended up putting a 32-bit dll in the structure of 64 bit mex file.

And that finally brings me to the main point of my post, and my question.

Is there a way to make the CYGWIN g++ linker choose the Windows 64 bit system libraries instead of the 32 bit?

[David Billinghurst]

CONTENTS DELETED

The author has deleted this message.

[Tim Prince-4]

CONTENTS DELETED

The author has deleted this message.

[Emad Gad]

I do really appreciate your help.
At least it put me on the right path.

So I decided just to test the basic idea: I used the compiler i686-w64-mingw32-g++ to compile a simple C file with mexFunction, and see to it being run, or called, from the Matlab command line and return the expected value without errors. Of course I put a small mexopt.bat file to guide the compilation process, etc.

And it happened!
And that led me to conclude that the i686-w64-mingw32-g++ is the way to go when it comes to Matlab, and that it is one of those approved compilers that the Windows-based Matlab can invoke to compile a mex-based C function, and will not complain of any missing library etc.

Now I shifted my strategy, where I decided to port my LINUX project to Windows. The goal was to compile this project using i686-w64-mingw32-g++ so that I can link it with the Matlab interface. As I said before, I succeeded in doing just that (I mean building my cmake-based project), but with the cygwin g++ compiler. Now, having been enlightened to the differences between cygwin and MinGW, I tried to restart compiling everything with mingw species.
I am still using the cygwin shell to accomplish my scheme.

The troubles I am having now is how to build the cmake-based project with i686-w64-mingw32-g++ compiler, through the cygwin shell? Somehow, I feel that this may be a contradiction in terms, but let me first report my observations.

The main issue here is that the cmake that comes with cygwin will not accept the compiler i686-w64-mingw32-g++. It will complain that that compiler "cannot compile a simple file" which is a lie, because I know that it does. I actually tested, and Matlab used successfully. So how come cmake found out that it fails to compile?

I found out the reason by invoking cmake with the option --debug-trycompile, and there I saw what cmake is trying to do and how it failed.

cmake tests the compiler by requesting it to compile a very small file, called textCCompile.c, that it creates on the fly. However, its uses the absolute path of this file. To be more precise, here is the literal command that the cygwinish cmake issues

/cygdrive/c/MinGW64/mingw64/i686-w64-mingw32-g++ -o cmTryxxxxxxxx/testCCompile.c.o -c /home/usrername/path/to/the/file/build/CMakeFiles/CMakeTmp/testCCompile.c.

The main problem here is that i686-w64-mingw32-g++ will not take the absolute path of the C file /home/usrername/path/to/the/file/testCCompile.c. Instead, it returns a "file not found" kind of error. If I invoke the same command that cmake did invoke, it returns the same error. However, if I use the relative path, say like the following

/cygdrive/c/MinGW64/mingw64/i686-w64-mingw32-g++ -o cmTryxxxxxxxx/testCCompile.c.o -c ../CMakeFiles/CMakeTmp/testCCompile.c.

then the command is executed without any troubles.
So I feel now that the main problem is that mingw compiler, which worked with Matlab, the i686-w64-mingw32-g++, does not like UNIX-style absolute paths, and will not be able to grab any file specified using this mode.

So my question is am I in the right place? Is it normal to use a cygwin-based cmake to compile a project with i686-w64-mingw32-g++?

Your help is indeed appreciated.

Thanks
 

 

[Csaba Ráduly]

CONTENTS DELETED

The author has deleted this message.