Re: package "optim" compilation oddity

[Olaf Till]

On Fri, Aug 31, 2012 at 07:48:08AM -0700, CdeMills wrote:
> 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 last line ("libf77blas.a(xerbla.o)") seems to mean that a static
link is attempted. I can't guess why this is so (or is libf77blas.so
lacking for some reason?), but I'd guess this is the problem. In a
dynamic link, I think the linker (or at least the runtime linker)
should be able to locate the libraries resolving the indirect
dependencies without them being explicitely included into the
commandline.

Olaf

> 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.

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc
Description: Digital signature