mex file execute path
in [Matlab]
|
From: Malcolm McLean on 1 Aug 2010 07:52 I wrote a simple test mex file. It executes perfectly when Matlab is in the same directory, falls over when Matlab is in a different directory (even though the mex is in a directory on the path). However 3rd party toolkits must contain lots of mex files and I never have any problem with them. What's going on?
From: Yi Cao on 1 Aug 2010 08:00 "Malcolm McLean" <malcolm.mclean5(a)btinternet.com> wrote in message <i33n54$6ki$1(a)fred.mathworks.com>... > I wrote a simple test mex file. > > It executes perfectly when Matlab is in the same directory, falls over when Matlab is in a different directory (even though the mex is in a directory on the path). > However 3rd party toolkits must contain lots of mex files and I never have any problem with them. > > What's going on? Assume your mex file name is "abc", try "which abc" to find what is wrong. Yi
From: Rune Allnor on 1 Aug 2010 08:06 On 1 Aug, 13:52, "Malcolm McLean" <malcolm.mcle...(a)btinternet.com> wrote: > I wrote a simple test mex file. > > It executes perfectly when Matlab is in the same directory, falls over when Matlab is in a different directory (even though the mex is in a directory on the path). > However 3rd party toolkits must contain lots of mex files and I never have any problem with them. > > What's going on? What 'path' is this? Matlab's file access has nothing to do with any path variables of the OS, but is totally internal to matlab. Make sure you use ADDPATH from whitin matlab (e.g. in startup.m) before you attempt to call the MEX file. Rune
From: Malcolm McLean on 1 Aug 2010 08:24 The problem seems to have gone away. I was writing a complicated function in a subdirectory. It was full of bugs, and segfaults. Eventually I got it running with a test .m file driver in the subdirectory. I then ran it from the main directory in real code, and it fell over. I spent the whole morning looking at why, and finally worked out that when I reduced it to a stub (print hello world) it would still fall over. However when I moved it to the main directory, it worked fine. So I commented the function back in, and simply called mex from the main directory, to create a mexw32 file. It then worked fine. However I can't replicate the problem. Exactly the same code now seems to run from the subdirectory, as it ought to.
From: Rune Allnor on 1 Aug 2010 08:49
On 1 Aug, 14:24, "Malcolm McLean" <malcolm.mcle...(a)btinternet.com> wrote: > The problem seems to have gone away. > > I was writing a complicated function in a subdirectory. It was full of bugs, and segfaults. Eventually I got it running with a test .m file driver in the subdirectory. I then ran it from the main directory in real code, and it fell over. > I spent the whole morning looking at why, and finally worked out that when I reduced it to a stub (print hello world) it would still fall over. However when I moved it to the main directory, it worked fine. So I commented the function back in, and simply called mex from the main directory, to create a mexw32 file. It then worked fine. > > However I can't replicate the problem. Exactly the same code now seems to run from the subdirectory, as it ought to. These are several problems: Seg faulting code and path problems. The seg faults might well have messed up the internals of matlab such that what ought to work, doesn't. To isolate the path problem, write a "hello world" MEX file, compile it and leave the executable in the subdirectory (make sure *all* similarly named executables are deleted first!) and attempt to run from the main directory. Rune |