Re: Building Octave Statically (and without graphics)

[John W. Eaton]

On 30-Oct-2009, Raymond at SDSU wrote:

| Thanks (both) for the help.  The potential of a limited features version of
| Octave for use on computing clusters seems meritorious.  The Octave
| configure without all of the packages:
| 
| ./configure --prefix=/home/raymond --without-framework-carbon --without-zlib
| --
| without-hdf5 --without-fftw --without-glpk --without-curl
| --without-framework-op
| engl --without-qrupdate --without-amd     --without-umfpack --without-colamd 
| --
| without-ccolamd     --without-cholmod    --without-cxsparse 
| --without-arpack   
| 
| allows the "make" to proceed further, but the make still fails at a linking
| step:
| 
| g++  -I. -I.. -I../liboctave -I../src -I../libcruft/misc  -DHAVE_CONFIG_H
| -mieee-fp -Wall -W -Wshadow -Wold-style-cast -Wformat -g -O2 -rdynamic -L.. 
| -fPIC  -o octave main.o  -L../liboctave -L../libcruft -L../src -Wl,-rpath
| -Wl,/home/raymond/lib/octave-3.2.3 -loctinterp -loctave  -lcruft  
| -lreadline  -lncurses -ldl -lm  -L/usr/lib/gcc/i386-redhat-linux/4.1.2
| -L/usr/lib/gcc/i386-redhat-linux/4.1.2/../../.. -lgfortranbegin -lgfortran
| -lm
| 
| ../liboctave/liboctave.so: undefined reference to
| `pthread_mutexattr_destroy'
| ../src/liboctinterp.so: undefined reference to `XOpenDisplay'
| ../liboctave/liboctave.so: undefined reference to `pthread_mutexattr_init'
| ../liboctave/liboctave.so: undefined reference to
| `pthread_mutexattr_settype'
| ../src/liboctinterp.so: undefined reference to `XScreenNumberOfScreen'
| collect2: ld returned 1 exit status

I understand wanting to build without graphics, but I don't understand
why you would want to discard all these other numerical tools.  What
does that have to do with running on a cluster?

I would expect --without-x to help, but I just tried a build with that
and X was still enabled.  That should probably be fixed, but it is not
a high priority item for me, so I will probably just wait for someone
to contribute patches.

The -lpthread problem is known, and I think fixed in the current
development sources (I haven't checked the 3.2.x release branch).

If you are interested in contributing patches, please note that the
configuration scripts are undergoing some major changes right now as
we switch to automake and libtool.  So it might be best to wait until
after that transition is finished.

Also, the maintainers list is probably a better place for this
discussion.

jwe