[Octave-bug-tracker] [bug #41460] mkoctfile issues on Mac: can't find X11 libs (and side question: why link with all dependencies)?

[Michael C. Grant]

URL:
  <http://savannah.gnu.org/bugs/?41460>

                 Summary: mkoctfile issues on Mac: can't find X11 libs (and
side question: why link with all dependencies)?
                 Project: GNU Octave
            Submitted by: mcgrant
            Submitted on: Wed 05 Feb 2014 01:18:40 AM GMT
                Category: Octave Function
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Incorrect Result
                  Status: None
             Assigned to: None
         Originator Name: Michael C. Grant
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: dev
        Operating System: Mac OS

    _______________________________________________________

Details:

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:


mkoctfile ../cvx_bcompress_mex.c
ld: library not found for -lX11
clang: error: linker command failed with exit code 1 (use -v to see
invocation)


The verbose output is this:

>> mkoctfile -v ../cvx_bcompress_mex.c
ld: library not found for -lX11
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
clang -c  -fPIC
-I/usr/local/Cellar/octave/3.8.1/include/octave-3.8.0/octave/..
-I/usr/local/Cellar/octave/3.8.1/include/octave-3.8.0/octave
-I/usr/local/Cellar/octave/3.8.1/include  -D_THREAD_SAFE -pthread   
../cvx_bcompress_mex.c -o cvx_bcompress_mex.o
clang++ -bundle -bundle_loader /usr/local/Cellar/octave/3.8.1/bin/octave-3.8.0
 -o cvx_bcompress_mex.oct  cvx_bcompress_mex.o  
-L/usr/local/Cellar/octave/3.8.1/lib/octave/3.8.0
-L/usr/local/Cellar/octave/3.8.1/lib -loctinterp -loctave -framework JavaVM 
-L/usr/local/Cellar/freetype/2.5.2/lib -lfreetype  -lhdf5 -lz -lfftw3_threads
-lfftw3 -lfftw3f_threads -lfftw3f -L/usr/local/Cellar/freetype/2.5.2/lib
-L/usr/local/Cellar/fontconfig/2.11.0/lib -lfontconfig -lfreetype 
-Wl,-framework -Wl,OpenGL -lX11 -Wl,-framework -Wl,Carbon -lgl2ps  -framework
JavaVM -L/usr/local/opt/openblas/lib -lopenblas              -lcurl -lcholmod
-lumfpack -lsuitesparseconfig -lamd -lcamd -lcolamd -lccolamd -lcxsparse
-larpack -lqrupdate -lfftw3_threads -lfftw3 -lfftw3f_threads -lfftw3f
-L/usr/local/opt/openblas/lib -lopenblas -L/usr/local/opt/openblas/lib
-lopenblas -lreadline -lncurses  -L/usr/local/Cellar/pcre/8.34/lib -lpcre -ldl
 
-L/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2
-L/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2/../../..
-lgfortran -lquadmath -lm -lm


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.





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?41460>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/