help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Building Octave Statically (and without graphics)


From: John W. Eaton
Subject: Building Octave Statically (and without graphics)
Date: Fri, 6 Mar 2009 14:05:06 -0500

On 25-Feb-2009, Tim Currie wrote:

|   I'm trying to build a static Octave binary on Fedora 9. In building 
| all the deps as static libs, I ran into trouble with the requirement for 
| libGL. It seems (according to comments in the Mesa configure script) 
| that Mesa cannot be built statically, as the DRI requires that the 
| drivers be dynamic, which seems to conflict with the explicit assertion 
| in the documentation that Octave can, in fact, be built as a static 
| binary on Linux.
| 
|   This might be beside the point if I can figure out how to build Octave 
| *without any graphical capability*, as the Octave configure script 
| suggests is possible, because this build is going to be run on a large 
| cluster. But alas, this doesn't work any better than building Mesa, 
| which is to say that following the instructions in the README, as well 
| as the comments in the configure script and the Makefile, doesn't 
| produce the predicted results.

The configure script could probably use a --without-opengl option.

Until someone adds that, if you want to build without OpenGL on a
system that has OpenGLL libraries installed, you can do the following:

  * run configure

  * edit the generated config.h file and comment out the lines

      #define HAVE_OPENGL 1
      #define HAVE_FLTK

  * edit the generated Makeconf file and comment out the line

     GRAPHICS_LIBS = ...
     OPENGL_LIBS = ...

To build a statically linked binary, I think you'll probably want to
configure with

  --disable-dl --disable-dynamic --enable-static LDFLAGS=-static

and you'll need to make the following change to the genrated src/Makefile:

--- Makefile~   2009-03-06 10:59:38.000000000 -0500
+++ Makefile    2009-03-06 11:33:55.000000000 -0500
@@ -374,7 +374,8 @@
        $(LEXLIB) $(UMFPACK_LIBS) $(AMD_LIBS) $(CAMD_LIBS) $(COLAMD_LIBS) \
        $(CHOLMOD_LIBS) $(CCOLAMD_LIBS) $(CXSPARSE_LIBS) $(BLAS_LIBS) \
        $(FFTW_LIBS) $(QRUPDATE_LIBS) $(ARPACK_LIBS) $(OPENGL_LIBS) \
-       $(X11_LIBS) $(CARBON_LIBS) $(LIBS) $(FLIBS)
+       $(QHULL_LIBS) $(REGEX_LIBS) $(CURL_LIBS) $(GLPK_LIBS) \
+       $(GRAPHICS_LIBS) $(FT2_LIBS) $(X11_LIBS) $(CARBON_LIBS) $(LIBS) $(FLIBS)
 
 stmp-pic: pic
        @if [ -f stmp-pic ]; then \

(i.e., add $(QHULL_LIBS) $(REGEX_LIBS) $(CURL_LIBS) $(GLPK_LIBS)
$(GRAPHICS_LIBS) $(FT2_LIBS) to the command used for linking Octave).

Finally, you may also need to generate a modified version of your
systems' libblas.a file so that Octave can override the xerbla
function it probably includes.  Copying /usr/lib/libblas.a to the src
directory in the build tree and then running

  ar -d libblas.a xerbla.o

might work.

Building static binaries isn't normal usage these days, so it is not
surprising to me that some things don't work correctly.  Maybe we can
fix some of the problems (add a --disable-opengl option for the
configure script, add the proper libraries to the link command for a
static build) but I don't see a good general way of avoiding the
libblas xerbla problem.  If I understand correctly, the intent is that
users should be able to replace that function with their own.

On my system, I also had some trouble with things like libcurl,
libX11, and libglpk, as these apparently depend on additional
libraries.  But I'm not sure which additional libraries to link.
So maybe disabling these features would be the quick fix (unless you
need them, in which case, you'll need to figure out which libraries
are needed to make linking possible).

I also see a problem with some pthread functions required by libhdf5,
so you might either disable HDF5 or add the pthread library to the
link command.

But ultimately, if it turns out that there are some necessary system
libraries can't be linked statically on your system, then I'm not sure
there are any changes we could make to Octave to overcome that
problem.

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]