[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: package "optim" compilation oddity
From: |
Olaf Till |
Subject: |
Re: package "optim" compilation oddity |
Date: |
Fri, 31 Aug 2012 22:19:16 +0200 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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