Wed 05 Feb 2014 01:18:40 AM UTC, original submission:
I observed this when using the stable branch here with the mkoctfile executable.
Attempting to compile a very simple MEX file (with no dependencies on external libraries save the system) returned this:
The verbose output is this:
Adding either '-L/opt/X11/lib' or '-L/usr/X11/lib' does the trick. It would seem that somehow the configure/build system isn't picking up that mkoctfile needs to provide this flag by default.
But I must ask: why should it be trying to link to X11 at all? And more generally, why should mex/oct files link to all of Octave's dependencies? It seems to me that this is going to make it nearly impossible for me to distribute binaries to other Octave users, because I have no way to ensure that 1) they have installed the same dependencies I have; and 2) they have installed in them in the same locations I have. (That assumes we can figure out the relative library path issue on all platforms as well.)
Matlab, by contrast, links its mex files only to its own internal libraries (libmx/libmex/libmat) and the system libraries by default. If you want a direct connection to BLAS or LAPACK or any other library it uses internally, you need to add -lblas or -llapack yourself. Combined with an effective relative path strategy, this has the nice effect of allowing MEX files to be compatible across installations and different versions.
It does seem that the fact that Octave depends on so many external libraries makes this approach more problematic. I could see two solutions: 1) implement custom linker-style "-l" flags that add those dependencies on demand; for example, '-lfftw' automatically brings in the local installation of FFTW; or 2) provide an option '--minimal-dependencies' or somesuch that strips all but the truly essential libraries.
I think I'll be able to accomplish my goal by bypassing mkoctfile and compiling the functions by hand. But it does seem wise to provide this facility more generally.
|