public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* An issue with Matlab for a mex file compiled with GNU CYGWIN g++
@ 2013-07-01  2:27 Emad Gad
  2013-07-01  4:35 ` David Billinghurst
  2013-07-01 11:23 ` Tim Prince
  0 siblings, 2 replies; 5+ messages in thread
From: Emad Gad @ 2013-07-01  2:27 UTC (permalink / raw)
  To: cygwin

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?





--
View this message in context: http://cygwin.1069669.n5.nabble.com/An-issue-with-Matlab-for-a-mex-file-compiled-with-GNU-CYGWIN-g-tp100307.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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: An issue with Matlab for a mex file compiled with GNU CYGWIN g++
  2013-07-01  2:27 An issue with Matlab for a mex file compiled with GNU CYGWIN g++ Emad Gad
@ 2013-07-01  4:35 ` David Billinghurst
  2013-07-01 11:23 ` Tim Prince
  1 sibling, 0 replies; 5+ messages in thread
From: David Billinghurst @ 2013-07-01  4:35 UTC (permalink / raw)
  To: cygwin, egad

On 1/07/2013 12:27 PM, Emad Gad wrote:
> 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.

Try one of the supported compilers for your version of Matlab.  Getting 
an unsupported compiler to work could be difficult, and may be impossible.

See http://www.mathworks.com.au/support/compilers/R2013a/index.html
and http://www.mathworks.com.au/support/sysreq/previous_releases.html

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: An issue with Matlab for a mex file compiled with GNU CYGWIN g++
  2013-07-01  2:27 An issue with Matlab for a mex file compiled with GNU CYGWIN g++ Emad Gad
  2013-07-01  4:35 ` David Billinghurst
@ 2013-07-01 11:23 ` Tim Prince
  2013-07-12  4:51   ` Emad Gad
  1 sibling, 1 reply; 5+ messages in thread
From: Tim Prince @ 2013-07-01 11:23 UTC (permalink / raw)
  To: cygwin

On 6/30/2013 10:27 PM, Emad Gad wrote:
>
> Is there a way to make the CYGWIN g++ linker choose the Windows 64 bit
> system libraries instead of the 32 bit?
>
cygwin64.  If you mean to link against Microsoft X64 libraries in place 
of cygwin ones, x86_64-w64-mingw32.

-- 
Tim Prince


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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: An issue with Matlab for a mex file compiled with GNU CYGWIN g++
  2013-07-01 11:23 ` Tim Prince
@ 2013-07-12  4:51   ` Emad Gad
  2013-07-12  8:28     ` Csaba Raduly
  0 siblings, 1 reply; 5+ messages in thread
From: Emad Gad @ 2013-07-12  4:51 UTC (permalink / raw)
  To: cygwin


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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: An issue with Matlab for a mex file compiled with GNU CYGWIN g++
  2013-07-12  4:51   ` Emad Gad
@ 2013-07-12  8:28     ` Csaba Raduly
  0 siblings, 0 replies; 5+ messages in thread
From: Csaba Raduly @ 2013-07-12  8:28 UTC (permalink / raw)
  To: cygwin

Hi Emad,

On Fri, Jul 12, 2013 at 5:17 AM, Emad Gad  wrote:
(snip)
> And that led me to conclude that the i686-w64-mingw32-g++ is the way to go
(snip)

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

The problem is that /cygdrive/c/MinGW64/mingw64/i686-w64-mingw32-g++
is not a Cygwin program, so it interprets
/home/usrername/path/to/the/file/testCCompile.c differently from
Cygwin's cmake : as a path on the current drive, starting with a
directory named "home". However, Cygwin's /home is Windows'
C:\cygwin\home

Cygwin contains a utility called "cygpath" which can convert between
POSIX paths and Windows paths:

$ cygpath -w /home/usrername/path/to/the/file/testCCompile.c
C:\cygwin\home\usrername\path\to\the\file\testCCompile.c

Unfortunately, I don't think you can force cmake to pass all paths through it.

> 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++?

It may be possible to force cmake to accept the compiler you specify
without checking, e.g. in the environment, like this:

CXX=/cygdrive/c/MinGW64/mingw64/i686-w64-mingw32-g++  cmake
--trust-the-compiler --the-compiler-is-your-friend path/to/sources

But it's likely that the makefiles it generates would also use POSIX
paths, and i686-w64-mingw32-g++ will not understand them unless you
hack the makefiles to use cygpath to translate filenames before make
passes them to i686-w64-mingw32-g++

I suspect it would be easier to use the native Windows version of
cmake with the mingw compiler.

Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2013-07-12  7:37 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-01  2:27 An issue with Matlab for a mex file compiled with GNU CYGWIN g++ Emad Gad
2013-07-01  4:35 ` David Billinghurst
2013-07-01 11:23 ` Tim Prince
2013-07-12  4:51   ` Emad Gad
2013-07-12  8:28     ` Csaba Raduly

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).