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

[Emad Gad <egad at eecs dot uottawa dot ca>]

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, 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 
 

 



--
View this message in context: http://cygwin.1069669.n5.nabble.com/An-issue-with-Matlab-for-a-mex-file-compiled-with-GNU-CYGWIN-g-tp100307p100686.html
Sent from the Cygwin list mailing list archive at Nabble.com.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple