fatal error: Eigen/Core: No such file or directory compilation terminated - gcc

I recently change my OS to the last mint cinamon. Compiling one of the library I need (and that I used to used without problem), I get this message:
fatal error: Eigen/Core: No such file or directory compilation terminated.
I don't know what to do.
Thanks for the help.

Including directory /usr/local/include/eigen3/ solved this for me.
Like this, for example:
g++ -I/usr/local/include/eigen3/ CODE.cpp -o EXECUTABLE

Try to install eigen3 library,
on Ubuntu it would be
sudo apt-get install libeigen3-dev

Related

Compiling Elmer FEM on macOS Mojave causes the fatal error: 'string.h' file not found

I'm trying to follow these instructions to compile Elmer FEM on macOS Mojave Version 10.14.6. However, when running the make install I get the error message:
.../elmerfem/umfpack/src/umfpack/include/umf_internal.h:29:10: fatal error: 'string.h' file not found
#include <string.h>
^~~~~~~~~~
1 error generated.
make[2]: *** [umfpack/src/umfpack/umfpack_zl_save_symbolic.c] Error 1
make[2]: *** Deleting file `umfpack/src/umfpack/umfpack_zl_save_symbolic.c'
make[1]: *** [umfpack/src/umfpack/CMakeFiles/umfpack.dir/all] Error 2
make: *** [all] Error 2
searching the internet this post suggests
xcode-select --install
sudo xcode-select --switch /Library/Developer/CommandLineTools/
which had already been done before in my case and have no effect on the above error. This and this post suggest
sudo installer -pkg /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg -target / -allowUntrusted
which leads to the error message
installer: The install failed (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.)
I would appreciate it if you could help me know what is the problem and how I can resolve it. Thanks for your kind support in advance.
P.S.1. As was asked here, my make version is GNU Make 3.81.
P.S.2. the list of string.h files on my hard drive here.
P.S.3. the output of CMake is pasted here.
OK, I think I solved the problem. From here, I ran
cmake -DCMAKE_C_COMPILER=/usr/bin/gcc -DCMAKE_CXX_COMPILER=/usr/bin/g++ ..
while being inside the build folder. and then make . worked fine except some warning. I'm still not sure what was the problem or if this is the optimal/canonical solution. So I will not mark this as the accepted solution until others provide better ones.
P.S.1. I sent a pull request here on Elmer's HomeBrew formula as well.
P.S.2. To compile with OpenMP and MPI:
cmake -DCMAKE_C_COMPILER=/usr/local/Cellar/gcc/9.2.0_3/bin/gcc-9 -DCMAKE_CXX_COMPILER=/usr/local/Cellar/gcc/9.2.0_3/bin/g++-9 -DWITH_Mumps=FALSE -DWITH_MPI=TRUE -DWITH_OpenMP=TRUE -DWITH_MKL=FALSE -DWITH_ELMERGUI=TRUE -DWITH_ELMERPOST=FALSE -DWITH_ELMERGUITESTER=FALSE ..
I have GNU GCC and OpenMPI installed via HomeBrew brew install gcc open-mpi.
P.S.3. If you want the ElmerGUI also installed:
install qt4 with brew install cartr/qt4/qt#4 from here
install qwt with brew install cartr/qt4/qwt-qt4
then cmake -DCMAKE_C_COMPILER=/usr/local/Cellar/gcc/9.2.0_3/bin/gcc-9 -DCMAKE_CXX_COMPILER=/usr/local/Cellar/gcc/9.2.0_3/bin/g++-9 -DWITH_Mumps=FALSE -DWITH_MPI=TRUE -DWITH_OpenMP=TRUE -DWITH_MKL=FALSE -DWITH_ELMERGUI=TRUE -DWITH_ELMERPOST=TRUE -DWITH_ELMERGUITESTER=TRUE -DQWT_INCLUDE_DIR=/usr/local/Cellar/qwt-qt4/6.1.3_1/lib/qwt.framework/Versions/6/Headers/ ..

g++ error libboost on centos 7

I am trying to install the program my_mead_2.3.4 on my CentOS system.
I run
./configure --prefix=`pwd` --boostdir=/usr
and then make where I get these errors:
g++: error: /usr/lib64/lib/libboost_regex.a: No such file or directory
g++: error: /usr/lib64/lib/libboost_filesystem.a: No such file or directory
g++: error: /usr/lib64/lib/libboost_system.a: No such file or directory
g++: error: /usr/lib64/lib/libboost_serialization.a: No such file or directory
I ran yum install boost-devel, but still these files are missing.
I am new to Linux and CentOS, could you please tell me what to do here? Let me know if I should provide any additional Info.
Edit: apparently the program appends /lib to my boostdir. I don't know if this comes from the configure or the make step.

error: linking with `cc` failed: exit code: 1

I have a single .rs file. When I compile it by rustc test1.rs, I get an error:
error: linking with `cc` failed: exit code: 1
note: cc '-m64' '-L' '/usr/local/Cellar/rust/1.0.0-alpha/lib/rustlib/x86_64-apple-darwin/lib' '-o' 'test1' 'test1.o' '-Wl,-force_load,/usr/local/Cellar/rust/1.0.0-alpha/lib/rustlib/x86_64-apple-darwin/lib/libmorestack.a' '-Wl,-dead_strip' '-nodefaultlibs' '/usr/local/Cellar/rust/1.0.0-alpha/lib/rustlib/x86_64-apple-darwin/lib/libstd-4e7c5e5c.rlib' '/usr/local/Cellar/rust/1.0.0-alpha/lib/rustlib/x86_64-apple-darwin/lib/libcollections-4e7c5e5c.rlib' '/usr/local/Cellar/rust/1.0.0-alpha/lib/rustlib/x86_64-apple-darwin/lib/libunicode-4e7c5e5c.rlib' '/usr/local/Cellar/rust/1.0.0-alpha/lib/rustlib/x86_64-apple-darwin/lib/librand-4e7c5e5c.rlib' '/usr/local/Cellar/rust/1.0.0-alpha/lib/rustlib/x86_64-apple-darwin/lib/liballoc-4e7c5e5c.rlib' '/usr/local/Cellar/rust/1.0.0-alpha/lib/rustlib/x86_64-apple-darwin/lib/liblibc-4e7c5e5c.rlib' '/usr/local/Cellar/rust/1.0.0-alpha/lib/rustlib/x86_64-apple-darwin/lib/libcore-4e7c5e5c.rlib' '-L' '/usr/local/Cellar/rust/1.0.0-alpha/lib/rustlib/x86_64-apple-darwin/lib' '-L' '/Users/alex/Documents/projects/rust/.rust/lib/x86_64-apple-darwin' '-L' '/Users/alex/Documents/projects/rust/lib/x86_64-apple-darwin' '-lSystem' '-lpthread' '-lc' '-lm' '-lcompiler-rt'
note: ld: warning: directory not found for option '-L/Users/alex/Documents/projects/rust/.rust/lib/x86_64-apple-darwin'
ld: warning: directory not found for option '-L/Users/alex/Documents/projects/rust/lib/x86_64-apple-darwin'
ld: can't open output file for writing: test1, errno=21 for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
error: aborting due to previous error
$ rustc --version
rustc 1.0.0-dev
I've seen some topic related to this one but none of them helped me to solve the problem.
I was faced with three problems on Mac compiling Rust:
First: If you have any issue with writing files/dirs by ld just remove that files and try to recompile. I don't know why, but on Mac this issue happens time to time.
Second: If you have other ld errors (not about file access): try to add the following sections to your ~/.cargo/config (if you don't have this file feel free to create):
[target.x86_64-apple-darwin]
rustflags = [
"-C", "link-arg=-undefined",
"-C", "link-arg=dynamic_lookup",
]
[target.aarch64-apple-darwin]
rustflags = [
"-C", "link-arg=-undefined",
"-C", "link-arg=dynamic_lookup",
]
Third: Sometimes your Mac lack of some dev tools/dependencies. Install the most important of them automatically with the command:
xcode-select --install
From your command rustc test1.rs the compiler infers the name of the executable should be test1. The linker tries to open this file so it can write the executable but fails with errno=21 whose stringified version is "Is a directory".
This suggests you have a directory in your working directory called test1 which is causing a conflict.
if you have "note: /usr/bin/ld: cannot find -lsqlite3"
then install libsqlite3-dev: $ sudo apt install libsqlite3-dev
This works on Rust 1.53.0, Linux Mint 20.2(based on Ubuntu 20.04 LTS)
If you have a MacBook M1(x) with ARM processor you need to install rust from rustup https://sourabhbajaj.com/mac-setup/Rust/
When you run rustup-init, use the customize option to change aarch64-apple-darwin to x86_64-apple-darwin
Then you can add the following to .cargo/config.toml or .cargo/config (either is fine)
[target.x86_64-apple-darwin]
rustflags = [
"-C", "link-arg=-undefined",
"-C", "link-arg=dynamic_lookup",
]
This solution was tested with Rust 1.54 and MacBook M1
I was able to do a cargo build --release and generate a dylib file from this tutorial https://www.youtube.com/watch?v=yqLD22sIYMo
My rust project stopped building after updating my MacOS so this command fixed it for me
xcode-select --install
I had the same issue recently and I found out this solution that worked for me:
https://www.docker.com/blog/cross-compiling-rust-code-for-multiple-architectures/
On Running Rust on aarch64 I found out that libc6-dev-arm64-cross is need in order to compile rust successfully on aarch64.

cross-compiling with gcc, got storage size of ... isn't known error when it is defined in an include file under sysroot

I have a question very simliar to Cross compiler default include path setup but there wasn't the answer I was looking for.
I built a cross-compiler for openrisc. I have it in ~/openrisck/toolchain/
under there, I have bin(or32-linux-* excutables are here), include, lib, lib64, libexec, or32-linux, share.
under or32-linux, I have bin, include, lib, sys-root.
When I build busybox, I gave CONFIG_CROSS_COMPILER_PREFIX as "or32-linux-".
and CONFIG_SYSROOT as "$SYSROOT" which is ~/openrisk/toolchain/or32-linux/sys-root.
then I run 'make install' in buxybox source. Since the path includes the cross-compiler directory, it compiles for or32-linux-. But I have an error below
ckim : srctree = /home/ckim/openrisc/busybox
CC applets/applets.o
In file included from /home/ckim/openrisc/toolchain/bin/../lib/gcc/or32-linux/4.5.1-or32-1.0rc1/include-fixed/syslimits.h:7:0,
from /home/ckim/openrisc/toolchain/bin/../lib/gcc/or32-linux/4.5.1-or32-1.0rc1/include-fixed/limits.h:34,
from include/platform.h:141,
from include/libbb.h:13,
from include/busybox.h:8,
from applets/applets.c:9:
/home/ckim/openrisc/toolchain/bin/../lib/gcc/or32-linux/4.5.1-or32-1.0rc1/include-fixed/limits.h:169:61: fatal error: limits.h: No such file or directory
compilation terminated.
make[1]: *** [applets/applets.o] Error 1
make: *** [applets_dir] Error 2
which makes me thinks that Ah! the cross-compiler uses the include path relative to the executable. (see above bin/../lib/gcc/or32-linux/version/include-fixed)
So the include limits.h goes to the gcc's limits.h correctly. The last file syslimits.h has #include_next when the limits.h file have already been included. and the compiler complains that the file cannot be found.
Can somebody tell me how to solve this problem? (limits.h includes syslimits.h and syslimits.h includes limits.h .. )
EDIT : I ran 'make CROSS_COMPILE=or32-linux- CONFIG_PREFIX=$SYSROOT install'
then I got 'lutimes undeclared in coreutil/touch.c' error. Assuming the limit.h problem is gone, this means I should give these command line arguments because CROSS_COMPILE for make is different from CONFIG_CROSS_COMPILER_PREFIX in busybox configuration and make's CONFIG_PREFIX is different from CONFIG_SYSROOT for busybox configuration. so to remove the lutimes error, I ran 'make menuconfig' and removed CONFIG_TOUCH. Then I reran the make(make CROSS_COMPILE=or32-linux- CONFIG_PREFIX=$SYSROOT install), and this time got
procps/free.c: In function 'free_main':
procps/free.c:51:17: error: storage size of 'info' isn't known
procps/free.c:77:2: warning: implicit declaration of function 'sysinfo'
I found that in $SYSROOT/usr/include/sys/sysinfo.h, struct sysinfo is defined. I don't know why it says it's not defined. Any help would be deeply appreciated. Thanks!
For anyone who might be facing the same problem I had..
I tried about 3 times with the old toolchain but failed.
Yesterday, I got help from IRC (openrisc) and someone told me there is an updated toolchain for or1k. (not or32 which is old. I should have read the opencore page first..)
The page is
http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Linux_.28uClibc.29_toolchain_.28or1k-linux-uclibc.29 (read from Linux (uClibc) toolchain (or1k-linux-uclibc))

error compiling gcc: undefined reference to libc_name_p

When compiling GCC it is possible to get very far in the build process only to hiccup on an error complaining about the lack of gperf installed. After installing gperf and running, I hit an "undefined reference to libc_name_p." I've looked at the solutions here and here but they weren't helpful.
When gperf wasn't installed, the compilation script ran the command anyway but generated a blank ./gcc/cp/cfns.h. Since this file was newer than the source (./gcc/cp/cfns.gperf) the makefile left it alone and never regenerated the 'real' file when you actually had gperf. To continue, run rm ./gcc/cp/cfns.h and try again.

Resources