bugGNU Octave - Bugs: bug #41460, mkoctfile issues on Mac: can't...

 
 

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

Submitter:  Michael C. Grant <mcgrant>
Submitted:  Wed 05 Feb 2014 01:18:40 AM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Duplicate Assigned to:  None
Originator Name:  Michael C. Grant Open/Closed:  * Closed
Release:  * dev Operating System:  * Mac OS
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 28 Mar 2014 01:52:33 AM UTC, comment #2: 

Thanks, marking as duplicate and closing this bug.

Mike Miller <mtmiller>
Group Member
Fri 28 Mar 2014 01:31:10 AM UTC, comment #1: 

This can probably be closed as a duplicate of bug 41574.
https://savannah.gnu.org/bugs/?func=detailitem&item_id=41574

Michael C. Grant <mcgrant>
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:


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.

Michael C. Grant <mcgrant>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by mcgrant (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-03-28 mtmiller StatusNone Duplicate
        Open/ClosedOpen Closed
        Dependencies- Depends on bugs #41574

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code