Re: Towards more portable MEX compilations (with focus on the Mac)

[Michael C. Grant]

Perhaps my more voluminous mkoctfile output is due to the fact I'm forced to 
use --enable-link-all-dependencies during configuration. But that is *not* 
because I technically need that, it is due to the limitations of libtool, and 
its ability to handle the Mac's framework system.

What I do know is that manually stripping those extra dependencies from 
mkoctfile produces MEX files that work just fine.

As for whether linking to liboctave is necessary: linking would be required 
only if someone tries to call liboctave functions directly. If you use only the 
standard MEX interface, then there is no reason to link to liboctave, I suppose.

On Feb 12, 2014, at 2:25 AM, John W. Eaton <address@hidden> wrote:

> When I build a mex file on my Debian system with 3.8.0, I see this:
> 
>  $ /usr/local/octave/3.8.0/bin/mkoctfile --mex -v myfeval.c
>  gcc -c -fPIC -I/usr/local/octave/3.8.0/include/octave-3.8.0/octave/.. 
> -I/usr/local/octave/3.8.0/include/octave-3.8.0/octave 
> -I/usr/local/octave/3.8.0/include -g -O2 -pthread -I. myfeval.c -o myfeval.o
>  g++ -shared -Wl,-Bsymbolic -o myfeval.mex myfeval.o 
> -L/usr/local/octave/3.8.0/lib/octave/3.8.0 -L/usr/local/octave/3.8.0/lib 
> -loctinterp -loctave
> 
> So that is only linking directly with liboctinterp and liboctave.  I
> was under the impression that it was necessary to link shared
> libraries on OS X with all the dependencies.  If that's not true, then
> I agree that it should be fixed.
> 
> Also, since liboctinterp is already linked with liboctave, is it
> really necessary to link it directly?
> 
> jwe