Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error message could be improved when eigen isn't available #183

Open
sylvestre opened this issue Jan 12, 2019 · 13 comments
Open

error message could be improved when eigen isn't available #183

sylvestre opened this issue Jan 12, 2019 · 13 comments

Comments

@sylvestre
Copy link
Contributor

sylvestre commented Jan 12, 2019

./configure: line 25605: syntax error near unexpected token EIGEN3,' ./configure: line 25605: PKG_CHECK_MODULES(EIGEN3, eigen3 >= 3.2)'
tail -v -n +0 config.log
==> config.log <==

@turboencabulator
Copy link
Contributor

What version of pkgconfig do you have? The PKG_CHECK_MODULES macro generates a default error message if you don't provide one and it can't find the package. Mine looks like this:

configure: error: Package requirements (eigen3 >= 3.2) were not met:

No package 'eigen3' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables EIGEN3_CFLAGS
and EIGEN3_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

The syntax error makes me think there's something else wrong.

@fghoussen
Copy link
Collaborator

I have the same kind of errors when a package is not found.

~>pkg-config --version
0.29

turboencabulator added a commit to turboencabulator/arpack-ng that referenced this issue Mar 24, 2020
The original issue (opencollab#183) appears to be some sort of syntax error,
likely from not having pkg-config installed at the time of generating
the configure script.  Specifying our own error text won't improve that
problem.

This reverts commit ad9f74b.
turboencabulator added a commit to turboencabulator/arpack-ng that referenced this issue Nov 24, 2020
The original issue (opencollab#183) appears to be some sort of syntax error,
likely from not having pkg-config installed at the time of generating
the configure script.  Specifying our own error text won't improve that
problem.

This reverts commit ad9f74b.
@wshuai294
Copy link

could I ask how to solve the problem? I met the same error

./configure: line 26353: syntax error near unexpected token `EIGEN3,'
./configure: line 26353: `      PKG_CHECK_MODULES(EIGEN3, eigen3 >= 3.3)'

and I have installed pkg-config 0.29.2, it did not solve the problem.

@fghoussen
Copy link
Collaborator

If you bootstrapped before installing pkg-config 0.29.2, try

>> make distclean
>> ./bootstrap
>> ./configure

@MacroUniverse
Copy link

I also got an error for the latest version 3.8.0 on ubuntu 22.04
My command is just sh bootstrap, then ./configure. As provided in README

./configure: line 26616: syntax error near unexpected token `EIGEN3,'
./configure: line 26616: `	PKG_CHECK_MODULES(EIGEN3, eigen3 >= 3.3)'

Does arpack-ng require Eigen? If so, when I run ./configure --help, there is no option for providing the path to Eigen, what should I do to set the path?

My temporary solution is to simply delete the line 26616 of ./configure file. And everything seems to be fine, make check passed all tests.

@fghoussen
Copy link
Collaborator

fghoussen commented Nov 16, 2022

Does arpack-ng require Eigen?

No, arpack-ng needs eigen only when asking for exmm option (matrix market examples using C/C++ bindings allowing direct use of fortran).

Can you print with AC_MSG_RESULT what $enable_icb_exmm contains (before if test) and report here? (I do not reproduce the problem)

if test x"$enable_icb_exmm" != x"no"; then

PKG_CHECK_MODULES([EIGEN3], [eigen3 >= 3.3])

./configure --help, there is no option for providing the path to Eigen

with --enable-exmm, no need to provide eigen path: pkg-config is supposed to find it!

@MacroUniverse
Copy link

I added a line AC_MSG_RESULT($enable_icb_exmm), then ran ./configure again. It shows,

syntax error near unexpected token `$enable_icb_exmm'

@MacroUniverse
Copy link

MacroUniverse commented Nov 17, 2022

This will definitely reproduce the problem, the following is a simplified version of my Dockerfile. The build command I use is sudo docker build -t test -f tmp.dockerfile .

FROM ubuntu:22.04

ARG DEBIAN_FRONTEND=noninteractive

RUN apt -y update && \
	apt -y upgrade && \
	apt install -y git vim time libsqlite3-dev libboost-filesystem-dev \
	wget mlocate automake libtool lzip

RUN apt install -y g++ gfortran make

# ======== New User ========
# create `docker` as sudoer, use bash by default
# no password required for sudo command

RUN apt install -y sudo
ARG DOCKER_UID=1000
ARG DOCKER_USER=docker
ARG DOCKER_PASSWD=docker
RUN useradd -u $DOCKER_UID -m $DOCKER_USER --shell /bin/bash && echo "$DOCKER_USER:$DOCKER_PASSWD" | chpasswd && echo "$DOCKER_USER ALL=(ALL) ALL" >> /etc/sudoers

USER ${DOCKER_USER}
SHELL ["/bin/bash", "-c"] # --shell /bin/bash didn't work

ARG INSTALL_DIR=/home/$DOCKER_USER/libs
RUN mkdir -p $INSTALL_DIR

# ======== CMake ========
RUN cd ~/ && \
	wget -q https://github.com/Kitware/CMake/releases/download/v3.25.0-rc4/cmake-3.25.0-rc4-linux-x86_64.tar.gz && \
	tar -xzf cmake-3.25.0-rc4-linux-x86_64.tar.gz && \
	ln -s ~/cmake-3.25.0-rc4-linux-x86_64/bin/cmake ~ && \
	rm cmake-3.25.0-rc4-linux-x86_64.tar.gz

# ======== (C)BLAS and LAPACK(E) 32bit dynamic (reference) ========
RUN cd ~/ && wget -q https://github.com/Reference-LAPACK/lapack/archive/refs/tags/v3.10.1.tar.gz && \
	tar -xzf v3.10.1.tar.gz && \
	mkdir lapack-build && cd lapack-build && \
	mkdir $INSTALL_DIR/lapack32-so && \
	~/cmake -DCMAKE_INSTALL_PREFIX=$INSTALL_DIR/lapack32-so -DBUILD_INDEX64=OFF -DBUILD_SHARED_LIBS=ON -DLAPACKE=ON -DCBLAS=ON  ../lapack-3.10.1/ && \
	cd ~/lapack-build && make -j12 && make install

# ======== Arpack-NG ========
# --with-blas --with-lapack will not work
RUN cd ~/ && \
 	wget -q https://github.com/opencollab/arpack-ng/archive/refs/tags/3.8.0.tar.gz && \
 	tar -xzf 3.8.0.tar.gz && cd arpack-ng-3.8.0 && \
	mkdir $INSTALL_DIR/arpack && \
	sh bootstrap

# delete line 26616d to prevent an error about Eigen, `make check` will be ok
RUN cd ~/arpack-ng-3.8.0 && \
	export LIBRARY_PATH=$LIBRARY_PATH:$INSTALL_DIR/lapack32-so/lib/ && \
	export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$INSTALL_DIR/lapack32-so/lib/ && \
	# sed -i '26616d' ./configure && \
	./configure --prefix=$INSTALL_DIR/arpack && \
	make -j12 && make check -j12 && make install

Also, in here, I installed blas and lapack in a custom directory, but ./configure --with-blas option didn't work, after some experimenting, I added the custom directories to LIBRARY_PATH and LD_LIBRARY_PATH. Why is that necessary?

@fghoussen
Copy link
Collaborator

I added a line AC_MSG_RESULT($enable_icb_exmm), then ran ./configure again.

Modifying ./configure will not help: you need to regenerate it. Follow this steps, what are your traces?

>> git diff
diff --git a/configure.ac b/configure.ac
index 52e0a87..b239715 100644
--- a/configure.ac
+++ b/configure.ac
@@ -417,6 +417,7 @@ LAPACK              : $LAPACK_LIBS
 EIGEN               : $EIGEN3_CFLAGS
 LIBS                : $LIBS
 LDADD               : $LDADD
+enable_icb_exmm     : $enable_icb_exmm
 --------------------------------------------------
 Configuration OK
 --------------------------------------------------

>> make distclean # Clean all autotools machinery if needed
>> ./bootstrap # Re-generate configure from configure.ac
>> ./configure

@MacroUniverse
Copy link

ok, my git diff now shows the same, here is the complete output of ./configure

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
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 the compiler supports GNU Fortran... yes
checking whether gfortran accepts -g... yes
checking for gcc... gcc
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of gcc... gcc3
checking for g++... g++
checking whether the compiler supports GNU C++... yes
checking whether g++ accepts -g... yes
checking for g++ option to enable C++11 features... none needed
checking dependency style of g++... gcc3
./configure: line 5827: PKG_PROG_PKG_CONFIG: command not found
checking for g77... no
checking for xlf... no
checking for f77... f77
checking whether the compiler supports GNU Fortran 77... yes
checking whether f77 accepts -g... yes
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to get verbose linking output from f77... -v
checking for Fortran 77 libraries of f77...  -L/opt/intel/oneapi/mpi/2021.6.0//libfabric/lib/../lib -L/opt/intel/oneapi/mpi/2021.6.0//lib/../lib -L/opt/intel/oneapi/compiler/2022.1.0/linux/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/11 -L/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/11/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/opt/intel/oneapi/tbb/2021.6.0/env/../lib/intel64/gcc4.8 -L/opt/intel/oneapi/mpi/2021.6.0//libfabric/lib -L/opt/intel/oneapi/mpi/2021.6.0//lib/release -L/opt/intel/oneapi/mpi/2021.6.0//lib -L/opt/intel/oneapi/mkl/2022.1.0/lib/intel64 -L/opt/intel/oneapi/compiler/2022.1.0/linux/compiler/lib/intel64_lin -L/opt/intel/oneapi/compiler/2022.1.0/linux/lib -L/usr/lib/gcc/x86_64-linux-gnu/11/../../.. -lgfortran -lm -lquadmath
checking for dummy main to link with Fortran 77 libraries... none
checking for Fortran 77 name-mangling scheme... lower case, underscore, no extra underscore
checking if sgemm_ is being linked in already... no
checking for sgemm_ in -lopenblas... no
checking for ATL_xerbla in -latlas... no
checking for sgemm_ in -lblas... yes
checking for dgemm_ in -ldgemm... no
checking for sgemm_ in -lmkl_gf_lp64... yes
checking for cheev_... yes
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/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... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-pc-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 ar... ar
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 a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for mt... mt
checking if mt is a manifest tool... no
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.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... yes
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... yes
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 if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for f77 option to produce PIC... -fPIC
checking if f77 PIC flag -fPIC works... yes
checking if f77 static flag -static works... yes
checking if f77 supports -c -o file.o... yes
checking if f77 supports -c -o file.o... (cached) yes
checking whether the f77 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 if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for gfortran option to produce PIC... -fPIC
checking if gfortran PIC flag -fPIC works... yes
checking if gfortran static flag -static works... yes
checking if gfortran supports -c -o file.o... yes
checking if gfortran supports -c -o file.o... (cached) yes
checking whether the gfortran 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
./configure: line 26616: syntax error near unexpected token `EIGEN3,'
./configure: line 26616: `	PKG_CHECK_MODULES(EIGEN3, eigen3 >= 3.3)'

@fghoussen
Copy link
Collaborator

Put the AC_MSG_RESULT before

if test x"$enable_icb_exmm" != x"no"; then

@turboencabulator
Copy link
Contributor

I think autoconf isn't expanding the PKG_CHECK_MODULES macro for some reason, and just places it directly into configure. Are there any errors/warnings during ./bootstrap?

@turboencabulator
Copy link
Contributor

I can reproduce this by deleting /usr/share/aclocal/pkg.m4. This is the file that provides the macro definitions for PKG_PROG_PKG_CONFIG, PKG_CHECK_MODULES, etc. When it's missing, the macros don't get expanded in the configure script and it dies with these same syntax errors.

So I think the root of the problem is that pkg.m4 is either missing, too old, not installed in the right location, etc. Make sure your pkg-config package is installed and contains that file, and if not, find and install the package that does contain it.

We could ship a copy of it in the m4 directory. I don't know whether that's worth it or not, maybe we just need better instructions for what packages need to be installed prior to building.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants