|
"Ben Abbott" <bpabbott@yahoo.com> wrote in message <fl5g79$jn2$1@fred.mathworks.com>...
> Correction, I misinterpreted another post. I have no idea what fortran
> compiler works for mexing on Leopard.
>
> I've tried both g95 0.90 compiled on TIger and gfortran. Although each mex
> without error, each produce a crash when the result is run.
>
> I'll try to follow up a new posts containing the detail.
>
> btw, I've only tried mexing on Leopard with an Intel mac.
>
> "Ben Abbott" <bpabbott@yahoo.com> wrote in message
> <fl34ev$s28$1@fred.mathworks.com>...
> > How might I use gfortran to successfully produce mexmaci files?
> >
> > I'd use g95, but as I use Fink to manage my installations of g95 and
> gfortran and
> > their g95 is only at v0.9 (Matlab requires g95 0.91), I'm hopeful I can use
> > gfortran instead.
> >
> > Anyone have any success with gfortran?
>
I tried to produce a mex for the yprimef.f example.
mex yprimef.F yprimefg.F
/sw/lib/odcctools590/bin/ld: /usr/lib///libm.dylib unknown flags (type) of section 6
(__TEXT,__dof_plockstat) in load command 0
/sw/lib/odcctools590/bin/ld: /usr/lib///libSystem.dylib unknown flags (type) of section 6
(__TEXT,__dof_plockstat) in load command 0
/sw/lib/odcctools590/bin/ld: /usr/lib/libstdc++.6.dylib load command 8 unknown cmd field
/sw/lib/odcctools590/bin/ld: /usr/lib/libgcc_s.1.dylib load command 8 unknown cmd field
/sw/lib/odcctools590/bin/ld: /usr/lib/libSystem.B.dylib unknown flags (type) of section 6
(__TEXT,__dof_plockstat) in load command 0
mex: link of 'yprimef.mexmaci' failed.
My g95 and odcctools were built under Tiger prior to my upgrade to Leopard. Unfortunately, I did not
try to use the Intel versions to produce a mex file under Tiger.
Running 2006a/b on Tiger on my PPC mac, I had switched to producing mexmac files using a
makefile that optionally choose between g95 and gfortran.
Unfortunately, running 2007b on Leopard, and on Intel I am able to build a mexmaci, but it crashes
when run.
To see what was wrong, I created an alias for Matlab.
alias
matlab="/Applications/MATLAB_R2007b/bin/maci/StartMATLAB.app/Contents/MacOS/StartMATLAB"
and started matlab from the Terminal.app. From the matlab console I tried running the mexmaci file.
Below is what shows up in the Terminal window.
------------------------------
matlab
Sun Dec 30 16:03:02 bens-macbook.local MATLAB[8415] <Error>: CGContextGetBaseCTM: invalid
context
Sun Dec 30 16:03:02 bens-macbook.local MATLAB[8415] <Error>:
CGContextConvertSizeToDeviceSpace: invalid context
Sun Dec 30 16:03:02 bens-macbook.local MATLAB[8415] <Error>:
CGContextConvertSizeToUserSpace: invalid context
bens-macbook:~ bpabbott$ dyld: lazy symbol binding failed: Symbol not found:
_mxgetnumberofelements_
Referenced from: /Users/bpabbott/Desktop/TQNT Matlab
Toolbox/ha_g77/opm_HarmAdmitOL95v3.mexmaci
Expected in: flat namespace
dyld: Symbol not found: _mxgetnumberofelements_
Referenced from: /Users/bpabbott/Desktop/TQNT Matlab
Toolbox/ha_g77/opm_HarmAdmitOL95v3.mexmaci
Expected in: flat namespace
------------------------------
My fortran *source* code respects the case of the library, meaning that I call
"mxGetNumberOfElements". However, the object code is all lower case and has *added* a trailing
underscore. Thus, the object code refers to "_mxgetnumberofelements_" while the equivalent in
Matlab's library is "_mxGetNumberOfElements".
Checking the symbols in my gateway routine gives (same for gfortran and g95)
nm ha_lay_obl_v3g.o
[...]
U _mxgetnumberofelements_
[...]
While doing the same for libmex gives
nm /Applications/MATLAB_R2007b/bin/maci/libmex.dylib
[...]
U _mxGetNumberOfElements
[...]
Does anyone have an idea how to reconcile the difference in symbols?
Ben
|
Feed for this Thread