[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Towards more portable MEX compilations (with focus on the Mac)
From: |
Michael C. Grant |
Subject: |
Re: Towards more portable MEX compilations (with focus on the Mac) |
Date: |
Wed, 12 Feb 2014 23:42:26 +0000 |
I just reworked my Mac-specific configure.ac patch so that it does a "gui-only"
version of --enable-link-all-dependencies. With this fix, octave-gui still
links properly on the Mac, but mkoctfile no longer tries to link to everything
under the sun. I'll upload a changeset.
On Feb 12, 2014, at 7:20 AM, Michael C. Grant <address@hidden> wrote:
> 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
>