[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
package "optim" compilation oddity
From: |
CdeMills |
Subject: |
package "optim" compilation oddity |
Date: |
Fri, 31 Aug 2012 07:48:08 -0700 (PDT) |
Hello,
I've got a version of octave which is somewhat functional on Mac OS X 10.5
(it crashes at exit). I compiled a few packages from octave-forge, and the
compilation failed for optim-1.2.0. From its Makefile:
LFLAGS := $(shell $(MKOCTFILE) -p LFLAGS)
OCTAVE_LFLAGS := $(LFLAGS)
LFLAGS += $(LAPACK_LIBS)
LFLAGS += $(BLAS_LIBS)
OCTAVE_LFLAGS += $(OCTAVE_LAPACK_LIBS)
OCTAVE_LFLAGS += $(OCTAVE_BLAS_LIBS)
# __disna_optim__ should be linked to the same Lapack library as used by
Octave
__disna_optim__.oct: __disna_optim__.cc
LFLAGS="$(OCTAVE_LFLAGS)" $(MKOCTFILE) -s __disna_optim__.cc
The resulting invocation is:
LFLAGS="-L/opt/local/lib/octave/3.7.0+ -L/opt/local/lib -llapack -lcblas
-lf77blas -latlas" mkoctfile -s __disna_optim__.cc
mkoctfile: stripping disabled on this platform
Undefined symbols for architecture i386:
"__gfortran_st_write", referenced from:
_xerbla_ in libf77blas.a(xerbla.o)
The trouble is that we are adding fortran code which itself requires fortran
library. The cure is to compile with
LFLAGS="-L/opt/local/lib/octave/3.7.0+ -L/opt/local/lib -llapack -lcblas
-lf77blas -latlas -L/opt/local/lib/gcc47 -lgfortran"
/opt/local/bin/mkoctfile-3.7.0+ -s __disna_optim__.cc
The added components are
- the used compiler path for internal libs
- the fortran library
This should not have been required if the base thing had be compiled with
the fortran compiler. I don't know if this is a linker problem (missing
dependency between f77blas and gfortran), a compiler problem (f77blas should
include the few required routines of gfortran), a platform problem, ... Ben,
do you see this issue ?
Regards
Pascal
--
View this message in context:
http://octave.1599824.n4.nabble.com/package-optim-compilation-oddity-tp4643564.html
Sent from the Octave - Maintainers mailing list archive at Nabble.com.
- package "optim" compilation oddity,
CdeMills <=