How to force ./configure to use intel oneAPI compilers? - configuration

I recently installed IntelĀ® oneAPI Base Toolkit and IntelĀ® oneAPI HPC Toolkit using the cimmands:
sudo yum install intel-basekit
sudo yum install intel-hpckit
The packages are installed in /opt/intel/oneapi
but when I run ./configure it usually specifies other compilers:
directory QEHeat/src : ok okkokCI : ok
directory ACFDT/src : not present in /rhome/pkgs/QE/qe-7.1/install
directory KCW/PP : okk
all dependencies updated successfully
checking build system type... x86_64-pc-linux-gnu
checking ARCH... x86_64
checking setting AR... ... ar
checking setting ARFLAGS... ... ruv
checking for gfortran... gfortran
checking whether the Fortran compiler works... yes
checking for Fortran compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU Fortran compiler... yes
checking whether gfortran accepts -g... yes
checking for mpiifort... no
checking for mpif90... no
checking for ifort... no
checking for nvfortran... no
checking for pgf90... no
checking for nagfor... no
checking for gfortran... gfortran
checking whether we are using the GNU Fortran compiler... yes
checking whether gfortran accepts -g... yes
checking version of gfortran... gfortran 4.8
checking for Fortran flag to compile .f90 files... none
setting F90... gfortran
setting MPIF90... gfortran
checking for cc... cc
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
setting CC... cc
setting CFLAGS... -O3
using F90... gfortran
setting FFLAGS... -O3 -g
setting F90FLAGS... $(FFLAGS) -cpp
setting FFLAGS_NOOPT... -O0 -g
setting CPP... cpp
setting CPPFLAGS... -P -traditional -Uvector
setting LD... gfortran
setting LDFLAGS... -g
checking whether make sets $(MAKE)... yes
checking whether Fortran files must be preprocessed... no
checking whether we are using the GNU Fortran 77 compiler... yes
checking whether gfortran accepts -g... yes
checking for library containing dgemm... no
MKL not found
in /opt/intel/mkl/lib/intel64: checking for library containing dgemm... no
MKL not found
checking for library containing dgemm... no
in /usr/local/lib: checking for library containing dgemm... no
checking for library containing dgemm... -lblas
setting BLAS_LIBS... -lblas
checking for library containing dspev... -llapack
in /usr/local/lib: checking for library containing dspev... -llapack
checking FFT... checking for library containing dfftw_execute_dft... no
in /usr/local/lib: checking for library containing dfftw_execute_dft... no
using internal copy of FFTW
checking MASS...
checking for library containing mpi_init... no
checking ELPA...
checking for Environ... not used
checking for ranlib... ranlib
checking for wget... wget -O
setting WGET... wget -O
checking for git... git
setting DFLAGS... -D__FFTW
setting IFLAGS... -I. -I$(TOPDIR)/include -I$(TOPDIR)/FoX/finclude
configure: creating ./config.status
config.status: creating install/make_lapack.inc
config.status: creating include/configure.h
config.status: creating make.inc
config.status: creating configure.msg
config.status: creating install/make_wannier90.inc
config.status: creating include/qe_cdefs.h
--------------------------------------------------------------------
ESPRESSO can take advantage of several optimized numerical libraries
(essl, fftw, mkl...). This configure script attempts to find them,
but may fail if they have been installed in non-standard locations.
If a required library is not found, the local copy will be compiled.
The following libraries have been found:
BLAS_LIBS= -lblas
LAPACK_LIBS=-L/usr/local/lib -llapack -lblas
FFT_LIBS=
Please check if this is what you expect.
If any libraries are missing, you may specify a list of directories
to search and retry, as follows:
./configure LIBDIRS="list of directories, separated by spaces"
Parallel environment not detected \(is this a parallel machine?\).\
Configured for compilation of serial executables.
For more info, read the ESPRESSO User's Guide (Doc/users-guide.tex).
--------------------------------------------------------------------
configure: success
How to force ./configure to choose intel oneAPI compilers?

Here is a solution to your issue!
The key env vars to set
using F90... gfortran
setting FFLAGS... -O3 -g
setting F90FLAGS... $(FFLAGS) -cpp
setting FFLAGS_NOOPT... -O0 -g
so
export F90=ifort
export FFLAGS='-O3 -xhost -g'
export FFLAGS_NOOPT='-O0 -g'

Related

Octave forge packages installation

I'm trying to install image-2.6.1 package to GNU Octave, version 4.0.0. I downloaded image-2.6.1.tar.gz and tried to install it with
pkg install /home/vladimirmatveev/Downloads/image-2.6.1.tar.gz
but get an error.
configure: error: in `/tmp/oct-BAtlFb/image-2.6.1/src':
configure: error: C++ compiler cannot create executables
See `config.log' for more details
checking for a sed that does not truncate output... /bin/sed
checking for octave... /usr/bin/octave
checking for mkoctfile... /usr/bin/mkoctfile
checking whether the C++ compiler works... no
pkg: error running the configure script for image.
error: called from 'configure_make' in file /usr/share/octave/4.0.0/m/pkg/private/configure_make.m near line 79, column 9
I am sure I have C/C++ compilers, they are gcc and g++ (when I am trying to install them with apt-get it says I already have a newest version and I am sure it is true).
I tried to set c/c++ compilers to system variables with
export CC=/usr/bin/gcc-4.8
export CXX=/usr/bin/g++-4.8
or
export CC=/usr/bin/gcc-5
export CXX=/usr/bin/g++-5
(I have both versions) but it didn't helped. It usually works for me when cmake can not find a compiler.
I found im-config.log file, but it contains only
Script for ibus started at run_im.
Script for auto started at run_im.
Script for default started at run_im.
I am not sure this is that config file which was mentioned in error message, but it is the only file which has suitable modification date.
I am working at ubuntu 16.04.
I unpackaged .tar.gz, cd to it and to src/, then run ./configure and there was no troubles found while checking compiler, here is the console log.
checking for a sed that does not truncate output... /bin/sed
checking for octave... /usr/bin/octave
checking for mkoctfile... /usr/bin/mkoctfile
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether /usr/bin/g++-5 accepts -g... yes
checking for /usr/bin/g++-5 option to enable C++11 features... -std=gnu++11
checking whether xmin is in the octave::math namespace... no
checking whether templated lambda functions accept '&const int'... yes
configure: creating ./config.status
config.status: creating im2double.m
config.status: creating Makefile
config.status: creating config.h
Here is full config log http://pastebin.com/u6MNSqCB

configure: WARNING: FFTW3F library not found. The slower FFTPACK library will be used instead

I'm compiling octave on my LFS - Linux from scratch - system.
While configuring octave, I receive a warning:
configure: WARNING: FFTW3F library not found. The slower FFTPACK library will be used instead.
I compiled and installed FFTW 3.3.4, and then reconfigured octave, however I still receive the following messages:
checking fftw3.h usability... yes
checking fftw3.h presence... yes
checking for fftw3.h... yes
checking for fftw_plan_dft_1d in -lfftw3... yes
checking for fftw3.h... (cached) yes
checking for fftwf_plan_dft_1d in -lfftw3f... no
configure: WARNING: FFTW3F library not found. The slower FFTPACK library will be used instead.
I notice that FFTW 3.3.4 installs libfftw3.so but NOT libfftw3f.so, that's why even after installing FFTW 3.3.4, octave cannot find FFTW3F library. Now, I wonder how I can install libfftw3f.so.
It looks like you have the double precision FFTW libraries (libfftw3) but not the single precision versions (libfftw3f). Build it again with:
./configure --enable-float --enable-sse && make install
(assuming we're talking x86 here).
This should then install the libfftw3f libraries next to the existing libfftw3 libs.

configure: error: libtool configure failed

I gave ./configure in tclreadline for tclreadline2.1.0 and got this error
loading cache ./config.cache
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking whether make sets ${MAKE}... (cached) yes
checking host system type... Invalid configuration `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized
checking for gcc... (cached) gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for Cygwin environment... (cached) no
checking for mingw32 environment... (cached) no
checking for executable suffix... (cached) no
checking build system type... Invalid configuration `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized
checking for ranlib... (cached) ranlib
checking for ld used by GCC... (cached) /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... (cached) yes
checking for BSD-compatible nm... (cached) /usr/bin/nm -B
checking whether ln -s works... (cached) yes
loading cache ./config.cache within ltconfig
checking host system type... Invalid configuration `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized
configure: error: libtool configure failed
Please suggest what to done to compile properly
Thanks for the help in advance
Found the answer here. To get old configure scripts working, you can update the config.sub file:
curl 'http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD' > config.sub
This will replace the config.sub script with the latest version.
The package looks like it hasn't been maintained in a long time. Consequently, the autotools used to build the configure script and auxiliary files probably aren't even aware of x86-64.
Assuming you have the autotools installed - autoconf, automake, libtool, etc. - you could try running autoreconf -ivf, and then attempting ./configure again. You'll probably get a lot of warnings about out-of-date macros, etc. But it might work.

Mesa3D install can't find libdrm

I'm currently trying to manually install Mesa (version 10.2.3) on a server for which I do not have root access. After downloading the source, I run the configure file with .\configure --prefix=$HOME/.../PATH/TO/MESA. I get the following readout:
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking how to run the C preprocessor... gcc -E
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking dependency style of gcc... gcc3
checking for gmake... gmake
checking for python2... python2
checking for a sed that does not truncate output... /bin/sed
checking how to print strings... printf
checking for a sed that does not truncate output... (cached) /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 3458764513820540925
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for archiver #FILE support... #
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for mt... no
checking if : is a manifest tool... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... no
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for bison... bison -y
checking if bison is the parser generator... yes
checking for flex... flex
checking lex output file root... lex.yy
checking lex library... -lfl
checking whether yytext is a pointer... yes
checking if flex is the lexer generator... yes
checking for perl... /usr/bin/perl
checking for indent... cat
checking if compiling with clang... no
checking whether gcc version is sufficient... yes
checking for __builtin_bswap32... yes
checking for __builtin_bswap64... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking whether gcc supports -Werror=missing-prototypes... yes
checking whether gcc supports -fvisibility=hidden... yes
checking whether g++ supports -fvisibility=hidden... yes
checking whether C compiler accepts -msse4.1... yes
checking whether ld supports --gc-sections... yes
checking whether to enable assembly... yes, x86_64
checking for dlopen... no
checking for dlopen in -ldl... yes
checking for dladdr... yes
checking for clock_gettime... no
checking for clock_gettime in -lrt... yes
checking for posix_memalign... yes
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... no
checking for LIBDRM... no
checking for LIBUDEV... no
checking for GLPROTO... yes
configure: error: Direct rendering requires libdrm >= 2.4.38
However, when I use locate libdrm, I get the following:
/install/rocks-dist/x86_64/RedHat/RPMS/libdrm-2.4.45-2.el6.x86_64.rpm
/usr/lib64/libdrm.so.2
/usr/lib64/libdrm.so.2.4.0
/usr/lib64/libdrm_intel.so.1
/usr/lib64/libdrm_intel.so.1.0.0
/usr/lib64/libdrm_nouveau.so.1
/usr/lib64/libdrm_nouveau.so.1.0.0
/usr/lib64/libdrm_nouveau2.so.2
/usr/lib64/libdrm_nouveau2.so.2.0.0
/usr/lib64/libdrm_radeon.so.1
/usr/lib64/libdrm_radeon.so.1.0.1
/usr/share/doc/libdrm-2.4.45
/usr/share/doc/libdrm-2.4.45/README
/var/lib/yum/yumdb/l/093e922ee5fe0bcee6c2de28500239d06027be18-libdrm-2.4.45-2.el6-x86_64
/var/lib/yum/yumdb/l/093e922ee5fe0bcee6c2de28500239d06027be18-libdrm-2.4.45-2.el6-x86_64/checksum_data
/var/lib/yum/yumdb/l/093e922ee5fe0bcee6c2de28500239d06027be18-libdrm-2.4.45-2.el6-x86_64/checksum_type
/var/lib/yum/yumdb/l/093e922ee5fe0bcee6c2de28500239d06027be18-libdrm-2.4.45-2.el6-x86_64/from_repo
/var/lib/yum/yumdb/l/093e922ee5fe0bcee6c2de28500239d06027be18-libdrm-2.4.45-2.el6-x86_64/from_repo_revision
/var/lib/yum/yumdb/l/093e922ee5fe0bcee6c2de28500239d06027be18-libdrm-2.4.45-2.el6-x86_64/from_repo_timestamp
/var/lib/yum/yumdb/l/093e922ee5fe0bcee6c2de28500239d06027be18-libdrm-2.4.45-2.el6-x86_64/installed_by
/var/lib/yum/yumdb/l/093e922ee5fe0bcee6c2de28500239d06027be18-libdrm-2.4.45-2.el6-x86_64/reason
/var/lib/yum/yumdb/l/093e922ee5fe0bcee6c2de28500239d06027be18-libdrm-2.4.45-2.el6-x86_64/releasever
This seems to indicate to me that libdrm version 2.4.45 is already installed on the system, so why am I still getting an error? I tried running the configure file again with the default prefix and the same error occurs.
UPDATE: The problem is moot for me now as the server admin added OpenGL to the system. Feel free to write an answer, though, as it might help someone having similar issues.
Installing the libdrm-dev package solved this problem for me.
just set the following variables:
export LIBDRM_CFLAGS="-I${LIBDRM_ROOT} -I${LIBDRM_ROOT}/libdrm"
export LIBDRM_LIBS="-L${LIBDRM_ROOT}/lib -ldrm"
as LIBDRM_ROOT have the path for the installed LIBDRM package.

Can't get libpcap to compile under Dell SUSE Enterprise

We are using Dell SUSE Enterprise. No choice.
SUSE doesn't have libpcap-devel or anything similar in the zypper repositories.
I've downloaded and installed libpcap from the GIT repository. libpcap requires both flex and bison to be compiled. flex version 2.5.35 is in the repo, as is bison.
However, I can't get any problem that uses libpcap-devel to compile. The autoconf script fails on attempts to link in libpcap.so:
configure:3633: $? = 1
configure:3636: checking whether we are using the GNU C++ compiler
configure:3665: g++ -c conftest.cpp >&5
configure:3672: $? = 0
configure:3689: result: yes
configure:3698: checking whether g++ accepts -g
configure:3728: g++ -c -g conftest.cpp >&5
configure:3735: $? = 0
configure:3836: result: yes
configure:3861: checking dependency style of g++
configure:3952: result: gcc3
configure:3981: checking for a BSD-compatible install
configure:4049: result: /usr/bin/install -c
configure:4067: checking for pcap_lookupdev in -lpcap
configure:4102: gcc -o conftest -g -O2 conftest.c -lpcap >&5
/usr/local/lib/libpcap.so: undefined reference to `pcap_lex'
collect2: ld returned 1 exit status
configure:4109: $? = 1
configure: failed program was:
Running nm on the archive, I find:
$ nm /usr/local/lib/libpcap.so | grep pcap_lex
U pcap_lex
of course, pcap_lex is really a #define from yylex.
I'm not in over my head here. I'm trying to figure out why none of this stuff compiles properly on Suse. Does anybody have a clue?
Somehow, whatever you did to compile libpcap caused it not to build correctly.
Without:
the config.log file from the libpcap directory;
the Makefile from the libpcap directory;
the output of the build in the libpcap directory;
it will be impossible to determine what that was, and thus it will be impossible to fix the process so that libpcap builds correctly. I have never seen a problem with libpcaps built on Linux, so I cannot determine what's happening here.
(If you supply this information, you will be helping not only yourself but all the people who have reported similar problems but have refused to respond to similar questions and thus have not supplied any of the information in question.)