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

[Michael C. Grant]

I've submitted Patch #8314 as an attempt to address this issue in the build 
system.

It's not *quite* perfect: it hardcodes the library directory in the 
executable's RPATH, instead of making it relative to @executable_path, which I 
would prefer. This means that the installed libraries can't be moved to a 
different location without breaking the RPATH. (The executable, on the other 
hand, can be moved anywhere.) Computing the relative path from the the absolute 
paths is not something I know how to do easily in shell script and sed. 

But this fixes the most important aspect of the OCT/MEX dynamic linker path 
issue on Macs. In particular, if we *do* get a relative path version of this 
working, it won't break existing MEX/OCT files that are compiled with this 
absolute version. (And who knows, maybe there are good arguments for sticking 
with the absolute path.)

The patch is designed to engage only on the Mac, only when shared libraries are 
built, and only when 'install_name_tool' is present.

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

>>    On the Mac, dynamic library path resolution is a bit tricky. For a
>>    package like Octave, the best way to go is to use @rpath constructs
>>    in the dynamic libraries (liboctave/libinterp), and then give the
>>    executable an rpath (likely using an @executable_path construct)
>>    that points all dynamically loaded objects to the library install
>>    directory. Unfortunately, GNU libtool provides no way to insert
>>    these constructs into the library and/or executable. (I've submitted
>>    a patch, but I'm not optimistic.) I don't think Linux really has an
>>    issue here; I don't yet know about Windows.