help-octave
[Top][All Lists]
Advanced

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

Re: [Octave compilation on macOS 11.2.2 with MacPorts 2.6.4 and GCC 10.2


From: Maxim Abalenkov
Subject: Re: [Octave compilation on macOS 11.2.2 with MacPorts 2.6.4 and GCC 10.2.0]
Date: Thu, 11 Mar 2021 19:57:33 +0200

Dear all,

How are you? All my attempts to compile Octave on a macOS with OpenBLAS fail. I still obtain the same error:

libtool: link: g++ -dynamiclib  -o liboctave/.libs/liboctave.8.dylib  liboctave/.libs/liboctave_la-liboctave-build-info.o liboctave/.libs/liboctave_la-version.o   -Wl,-force_load,liboctave/array/.libs/libarray.a -Wl,-force_load,liboctave/external/blas-xtra/.libs/libxerbla.a -Wl,-force_load,liboctave/external/ranlib/.libs/libranlib.a -Wl,-force_load,liboctave/external/.libs/libexternal.a -Wl,-force_load,liboctave/numeric/.libs/libnumeric.a -Wl,-force_load,liboctave/operators/.libs/liboperators.a -Wl,-force_load,liboctave/system/.libs/libsystem.a -Wl,-force_load,liboctave/util/.libs/libutil.a -Wl,-force_load,liboctave/wrappers/.libs/libwrappers.a -Wl,-force_load,libgnu/.libs/libgnu.a  -L/opt/local/lib -lcurl -larpack -lfftw3_threads -lfftw3 -lfftw3f_threads -lfftw3f -llapack -lblas -lncurses -lpcre -ldl -L/opt/local/lib/gcc10/gcc/x86_64-apple-darwin20/10.2.0 -L/opt/local/lib/gcc10/gcc/x86_64-apple-darwin20/10.2.0/../../.. -lgfortran -lquadmath -liconv -lm  -pthread -fopenmp -g -O2 -Wl,-framework -Wl,CoreFoundation   -pthread -fopenmp -install_name  /opt/octave-6.2.0/lib/octave/7.0.0/liboctave.8.dylib -compatibility_version 9 -current_version 9.0 -Wl,-single_module
Undefined symbols for architecture x86_64:
  "_cgejsv_", referenced from:
      __ZN6octave4math3svdI18FloatComplexMatrixE5gejsvERcS4_S4_S4_S4_S4_iiPSt7complexIfEiPfS7_S7_iRSt6vectorIS6_SaIS6_EERiRS9_IiSaIiEESD_ in libnumeric.a(libnumeric_la-svd.o)
  "_iconv", referenced from:
      _iconv_carefully_1 in libgnu.a(striconveh.o)
      _mem_cd_iconveh_internal in libgnu.a(striconveh.o)
     (maybe you meant: _str_iconveh, _iconveh_close , _octave_iconv_close_wrapper , _octave_iconv_open_wrapper , _mem_iconveh , _mem_cd_iconveh , _str_iconveha , _iconveh_open , _str_cd_iconveh , _mem_iconveha )
  "_iconv_close", referenced from:
      _octave_iconv_close_wrapper in libwrappers.a(libwrappers_la-iconv-wrappers.o)
      _iconveh_open in libgnu.a(striconveh.o)
      _iconveh_close in libgnu.a(striconveh.o)
     (maybe you meant: _octave_iconv_close_wrapper)
  "_iconv_open", referenced from:
      _octave_iconv_open_wrapper in libwrappers.a(libwrappers_la-iconv-wrappers.o)
      _iconveh_open in libgnu.a(striconveh.o)
     (maybe you meant: _octave_iconv_open_wrapper)
  "_zgejsv_", referenced from:
      __ZN6octave4math3svdI13ComplexMatrixE5gejsvERcS4_S4_S4_S4_S4_iiPSt7complexIdEiPdS7_S7_iRSt6vectorIS6_SaIS6_EERiRS9_IiSaIiEESD_ in libnumeric.a(libnumeric_la-svd.o)
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

My configure and make script is as follows:

#!/opt/local/bin/bash

OPENBLAS_PATH=/opt/openblas

export V=1

CC=gcc
CXX=g++
FC=gfortran
CFLAGS="-I/opt/local/include -I${OPENBLAS_PATH}/include"
CXXFLAGS="-I/opt/local/include -I${OPENBLAS_PATH}/include"
FFLAGS="-I/opt/local/include -I${OPENBLAS_PATH}/include"
LDFLAGS="-L${OPENBLAS_PATH}/lib -lopenblas -L/opt/local/lib -liconv"

../configure --prefix=/opt/octave-6.2.0 --disable-readline --without-qt --without-x --with-libiconv-prefix=/opt/local

make -j 4

## @eof octave-install.sh

I also attach the `config.log` file for completeness. It seems to me neither OpenBLAS, not iconv get picked up by the configure script. Maybe I have to modify the makefile directly?

Best wishes,
Maxim

Attachment: config.log
Description: Binary data


Maxim Abalenkov \\ maxim.abalenkov@gmail.com
+44 7 486 486 505 \\ http://mabalenk.gitlab.io

On 11 Mar 2021, at 12:36, Maxim Abalenkov <maxim.abalenkov@gmail.com> wrote:

Dear all,

Please find the `config.log` file attached (Octave with Intel MKL @ the backend). My configure and build script is as follows:

#!/opt/local/bin/bash

export V=1

CC=gcc
CXX=g++
FC=gfortran
CFLAGS="-I/opt/local/include -m64 -I${MKLROOT}/include"
CXXFLAGS="-I/opt/local/include -m64 -I${MKLROOT}/include"
FFLAGS="-I/opt/local/include -m64 -I${MKLROOT}/include"
LDFLAGS="-L${MKLROOT}/lib -Wl,-rpath,${MKLROOT}/lib -lmkl_intel_ilp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm -ldl -L/opt/local/lib -liconv -L/opt/local/lib -lfl"

../configure --prefix=/opt/octave-6.2.0 --disable-readline --without-qt --without-x

make -j 4

Best wishes,
Maxim

<config.log>

Maxim Abalenkov \\ maxim.abalenkov@gmail.com
+44 7 486 486 505 \\ http://mabalenk.gitlab.io

On 11 Mar 2021, at 12:32, Maxim Abalenkov <maxim.abalenkov@gmail.com> wrote:

Dear all,

Thank you for all you help and your suggestions. Now I see, why linking Octave against Intel’s MKL @ macOS was a theoretical debate. I’m failing here right at the configuration stage. Please find my `config.log` file attached. I would be happy to help here and try further if you can provide me with some guidance. I think MKL at the backend would make Octave only stronger.

Regarding of my original issue of compiling Octave from source @ macOS I think for now I will follow an easier route and try to link it against the “standard” OpenBLAS. I need to progress in my project and make my life a little bit easier. I will get back to you once I try the "OpenBLAS compilation”. Thank you for your help and have a good day ahead!

Best wishes,
Maxim

Maxim Abalenkov \\ maxim.abalenkov@gmail.com
+44 7 486 486 505 \\ http://mabalenk.gitlab.io

On 9 Mar 2021, at 17:21, Andrew Janke <floss@apjanke.net> wrote:



On 3/9/21 9:36 AM, Maxim Abalenkov wrote:
Dear all,

Thank you very much for your help and your replies. Please find below
the contents of my configure and build bash script:

As you may see I’m trying to point Octave to Intel’s MKL BLAS and GNU
iconv library located in /opt/local/lib.

You are the only person I'm aware of who has *actually* tried to build
Octave against Intel MKL on Mac; up until now this has just been a
theoretical discussion as far as I'm aware.

Good luck!

Cheers,
Andrew




reply via email to

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