|
OK, now I tried this, just to check the number of input arguments:
#include "fintrf.h"
subroutine mexfunction(nlhs,plhs,nrhs,prhs)
c Required declarations for MATLAB
mwPointer plhs(*),prhs(*)
integer nlhs,nrhs
c Prototype the return types of these functions
mwPointer mxGetPr
mwSize mxGetM, mxGetN, nx, nz
real*8 mxGetScalar
mwPointer mxCreateDoubleMatrix
integer mxIsDouble, mxIsComplex
c Pointer to classid used to create MATLAB single matrices
integer*4 classid
C Check for proper number of input and output arguments
if (nrhs .ne. 1) then
call mexErrMsgTxt('One input arguments required.')
end if
return
end
When I run this in Matlab:
dx=0.25;
dy=0.5;
p = testmx(dx);
It complained
??? One or more output arguments not assigned during call to "testmx".
Error in ==> test_advxmx at 3
p = testmx(dx);
If I do this:
dx=0.25;
dy=0.5;
testmx(dx);
Nothing happens so no crash.
But if I do this
dx=0.25;
dy=0.5;
testmx(dx,dy);
That crashed Matlab again. It seems just by calling mexErrMsgTxt would crash.
BTW, I complied this mx program without any options:
/Applications/MATLAB_R2010b.app/bin/mex testmx.F
And the only thing I changed in my mexopts.sh file is in the maci64 section, on the path to gfortran. I changed it to:
/usr/local/gfortran/bin/gfortran'
Christopher Hulbert <cchgroupmail@gmail.com> wrote in message <inneb5$djn$1@dont-email.me>...
> On 4/8/11 12:28 PM, Alan wrote:
> > Brian,
> >
> > This for the answer. I downloaded a 64-bit version of gfortran and now the
> > compliation went smoothly. However when I run the program it crashes Matlab. To
> > isolate the problem, I stripped down my program to the minimum that still
> > causing the crash, and here it is:
> >
> > #include "fintrf.h"
> > subroutine mexfunction(nlhs,plhs,nrhs,prhs)
> >
> > c Required declarations for MATLAB
> > mwPointer plhs(*),prhs(*)
> > integer nlhs,nrhs
> > c Prototype the return types of these functions
> > mwPointer mxGetPr
> > mwSize mxGetM, mxGetN
> > real*8 mxGetScalar
> > mwPointer mxCreateDoubleMatrix
> >
> > integer mxIsDouble, mxIsComplex
> >
> > c Pointer to classid used to create MATLAB single matrices
> > mwPointer classid
> >
> > c Associate classid with double precision (FORTRAN real*8)
> > classid = mxClassIDFromClassName('double')
>
> mxClassIDFromClassName does not return an mwPointer, but an integer. See
> http://www.mathworks.com/help/techdoc/apiref/mxclassidfromclassname.html.
>
> >
> > c Get variables passed from MATLAB, properly typed
> > dx = mxGetPr(prhs(1))
> >
> > c Create MATLAB return matrices
> > plhs(1) = mxCreateDoubleMatrix(10,10,classid,0)
>
> mxCreateDoubleMatrix takes mwSize arguments. Unless you are compiling with
> 8-byte integers with your compiler, this is likely the cause of your crashing.
> You need either provide an explicit interface so the compiler can do the cast,
> or store the dimensions in variables of the appropriate type.
>
> Chris
>
> >
> > return
> > end
> >
> > With the above program, when I call it inside Matlab with:
> >
> > dt=0.25;
> > testmx(dx);
> >
> >
> > It crashed Matlab. Where is the problem?
> >
> >
> > ~
> > Brian Arnold <Brian.Arnold@mathworks.com> wrote in message
> > <4D9E05C7.9020702@mathworks.com>...
> >> Hi Alan,
> >>
> >> The problem is with the architecture of the gfortran compiler you installed
> >> under /sw/, its libraries are 32-bit (i386). MATLAB needs to link 64-bit
> >> (x86_64). You'll need to find a working 64-bit gfortran compiler whose
> >> libraries are 64-bit and ABI-compatible with Apple's gcc.
> >>
> >> If you are building gcc yourself under /sw/ yourself, try rebuilding with the
> >> -m64 option in CFLAGS, CXXFLAGS, and LDFLAGS.
> >>
> >> Brian
> >>
> >> Alan wrote:
> >> > I am running MATLAB 2010b on MacOS 10.6.7. I wrote a simple mex file. > When
> >> compiling it using mex command, I got the following error:
> >> > > $ /Applications/MATLAB_R2010b.app/bin/mex advxmx.F ld: warning: in >
> >> /sw/lib/gcc4.5/lib/libgfortran.dylib, file was built for i386 which is > not
> >> the architecture being linked (x86_64)
> >> > ld: warning: in >
> >> /sw/lib/gcc4.5/lib/gcc/i386-apple-darwin10.6.0/4.5.0/libgfortranbegin.a, >
> >> file was built for unsupported file format which is not the architecture >
> >> being linked (x86_64)
> >> > ld: warning: in >
> >> /sw/lib/gcc4.5/lib/gcc/i386-apple-darwin10.6.0/4.5.0/libgcc.a, file was >
> >> built for unsupported file format which is not the architecture being > linked
> >> (x86_64)
> >> > Undefined symbols:
> >> > "_advx_", referenced from:
> >> > _mexfunction_ in advxmx.o
> >> > ld: symbol(s) not found
> >> > collect2: ld returned 1 exit status
> >> > > mex: link of ' "advxmx.mexmaci64"' failed.
> >> > > My 'computer' says MACI64. And I listed this:
> >> > $ ls /sw/lib/gcc4.5/lib/gcc/i386-apple-darwin10.6.0/4.5.0/
> >> > crt3.o crtprec64.o include/ > install-tools/ libgcov.a plugin/ >
> >> crtfastmath.o crtprec80.o include-fixed/ > libgcc.a libgfortranbegin.a x86_64/
> >> > crtprec32.o finclude/ include-gnu-runtime/ > libgcc_eh.a libgfortranbegin.la
> >> > Somehow the mex wants to link to library files in this directory, not > the
> >> 'x86_64' directory inside it.
> >> > > This happens to me with both MATLAB 2010a and 2010b, and on both an iMac >
> >> and a MB Air. The gcc was installed using fink. My XCode version is > 3.2.5
> >> 64-bit on one and 3.2.6 64-bit on another.
> >> > > I also noticed that in the mexopts.sh file under my .matlab directory, >
> >> in the maci64 section I have this:
> >> > SDKROOT='/Developer/SDKs/MacOSX10.5.sdk'
> >> > I am wondering why this root is not >
> >> SDKROOT='/Developer/SDKs/MacOSX10.6.sdk' even though I already have both >
> >> MacOSX10.5.sdk and MacOSX10.6.sdk under /Developer/SDKs/. This > mexopts.sh
> >> was generated by mex -setup and is not changed.
|
Feed for this Thread