embedding mono sample: error while loading shared libraries: libmonoboehm-2.0.so.1 - mono

i've installed mono on centos 6 via make && make install from source
when i tried this sample:
https://github.com/mono/mono/blob/master/samples/embed/teste.c
no error occured during the compilation, but when i run i got this:
[root#WOH_Test t01]# gcc -o teste teste.c `pkg-config --cflags --libs mono-2` -lm
[root#WOH_Test t01]# mcs test.cs
[root#WOH_Test t01]# ./teste test.exe
./teste: error while loading shared libraries: libmonoboehm-2.0.so.1: cannot open shared object file: No such file or directory
i can't figure where the problem is, any clue?

What do you have in /usr/local/lib? If you didn't use the --prefix option while running autogen.sh before the command make the libraries should be localed in /usr/local/lib. You should see in that directory something like this:
me#mypc:/usr/local/lib$ ls -lah libmono-2.0.*
lrwxrwxrwx. 1 me me 18 dic 19 00:38 libmono-2.0.a -> libmonoboehm-2.0.a
lrwxrwxrwx. 1 me me 19 dic 19 00:38 libmono-2.0.la -> libmonoboehm-2.0.la
lrwxrwxrwx. 1 me me 19 dic 19 00:38 libmono-2.0.so -> libmonoboehm-2.0.so
lrwxrwxrwx. 1 me me 21 dic 19 00:38 libmono-2.0.so.1 -> libmonoboehm-2.0.so.1
lrwxrwxrwx. 1 me me 25 dic 19 00:38 libmono-2.0.so.1.0.0 -> libmonoboehm-2.0.so.1.0.0
If you can see the above libraries in /usr/local/lib your problem is related to where is ld searching for libraries. From this question: CentOS /usr/local/lib system wide $LD_LIBRARY_PATH I guess Centos6 does not have by default configuration for /usr/local/lib. If it is your case, just use the provided solutions in that question (any of them) and your program should work fine.
EDIT
From your comment if you want libmonoboehm-2.0.so.1 in the same path as the teste program and you do not want to touch anything else in your Centos6 you could do something like the following:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/teste/binary
./teste test.exe
But I wonder what output do you have when you run this command: pkg-config --cflags --libs mono-2 (it seems as if you already had a mono installation in your Centos6)
Anyhow, if you can modify your Centos6 the best is this answer: CentOS /usr/local/lib system wide $LD_LIBRARY_PATH. You do that once and you will be able to run any mono program without having to mess with the LD_LIBRARY_PATH environment variable. In your case you should do the following:
1. Edit /etc/ld.so.conf
2. Write this: /opt/mono/lib
3. Run ldconfig -v as root
4. Your Centos6 is ready to run your mono programs whenever you wish (even if you restart your Centos6 machine)
END EDIT

Related

Intel OneAPI 2022 - libimf.so No such file or directory - during openMPI compilation

trying to compile openmpi with intel oneapi 2022.0.1 compilers
OS is 5.4.0-26-generic #30-Ubuntu SMP Mon Apr 20 16:58:30 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
I got the intel compilers as follows (just to make sure I didn't mess anything up at that step)
sudo add-apt-repository "deb https://apt.repos.intel.com/oneapi all main"
sudo apt install intel-basekit
sudo apt install intel-hpckit
Configuring openmpi with:
./configure --prefix=${HPCX_HOME}/ompi-icc CC=/opt/intel/oneapi/compiler/2022.0.1/linux/bin/intel64/icc CXX=/opt/intel/oneapi/compiler/2022.0.1/linux/bin/intel64/icpc F77=/opt/intel/oneapi/compiler/2022.0.1/linux/bin/intel64/ifort FC=/opt/intel/oneapi/compiler/2022.0.1/linux/bin/intel64/ifort --with-ucx=/usr --with-platform=contrib/platform/mellanox/optimized
my .bashrc has (root has the same .bashrc)
source /opt/intel/oneapi/setvars.sh
export LD_LIBRARY_PATH=/opt/intel/oneapi/compiler/2022.0.1/linux/compiler/lib/intel64_lin
After configure I do : sudo make all install and get the following error:
ld: /opt/intel/oneapi/compiler/2022.0.1/linux/bin/intel64/../../bin/intel64/../../lib/icx-lto.so: error loading plugin: libimf.so: cannot open shared object file: No such file or directory
There is no ifortvars.sh with this new version of oneAPI which seems to have solved similar issues for others in the past.
libimf.so is in:
/opt/intel/oneapi/itac/2021.5.0/bin/rtlib/libimf.so
/opt/intel/oneapi/compiler/2022.0.1/linux/compiler/lib/intel64_lin/libimf.so
/opt/intel/oneapi/intelpython/python3.9/pkgs/intel-cmplr-lib-rt-2022.0.1-intel_3633/lib/libimf.so
/opt/intel/oneapi/intelpython/python3.9/lib/libimf.so
/opt/intel/oneapi/intelpython/python3.9/envs/2022.0.1/lib/libimf.so
Any help and/or advice regarding compiling openmpi with recent intel compilers would be appreciated.
Here is the solution I found but doubt that this is the most elegant way of doing this:
OS is 5.4.0-26-generic #30-Ubuntu SMP Mon Apr 20 16:58:30 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
my .bashrc has (root has the same .bashrc)
source /opt/intel/oneapi/setvars.sh
created intel_libs.conf in
/etc/ld.so.conf.d/ and added the line /opt/intel/oneapi/compiler/2022.0.1/linux/compiler/lib/intel64_lin this is where the libimf.so lives.
sudo ldconfig
compiled openmpi with intel compilers fine after that using:
./configure --prefix={HPCX_HOME}/ompi-icc CC=/opt/intel/oneapi/compiler/2022.0.1/linux/bin/intel64/icc CXX=/opt/intel/oneapi/compiler/2022.0.1/linux/bin/intel64/icpc F77=/opt/intel/oneapi/compiler/2022.0.1/linux/bin/intel64/ifort FC=/opt/intel/oneapi/compiler/2022.0.1/linux/bin/intel64/ifort --with-ucx=/usr --with-platform=contrib/platform/mellanox/optimized
sudo make all
sudo make install
I hope this helps someone else and please let me know if there is a better way of doing this. Cheers
I am also facing similar issue not exactly. I installed the new ifort using the following command lines:
wget https://registrationcenter-download.intel.com/akdlm/irc_nas/18236/l_BaseKit_p_2021.4.0.3422.sh
sudo bash l_BaseKit_p_2021.4.0.3422.sh
wget https://registrationcenter-download.intel.com/akdlm/irc_nas/18211/l_HPCKit_p_2021.4.0.3347.sh
sudo bash l_HPCKit_p_2021.4.0.3347.sh
There is no file called setvars.sh inside the source /opt/intel/oneapi/, also while compiling any mpiifort file it is throwing me an error saying:
error loading plugin: libimf.so: cannot open shared object file: No such file or directory
Not even sure, if this is related to this thread or not, but any further guidance would be very helpful, thanks in advance.

CMake: Not to use /usr/lib64/libXmu.so

I am new to CMake and Geant4. I am trying to build a project using them.
Also, I am working in a remote cluster. When I cmake, there's no error. But when I do make the error I am getting is,
make[2]: *** No rule to make target '/usr/lib64/libXmu.so', needed by 'PRO_simulation'. Stop.
make[1]: *** [CMakeFiles/PRO_simulation.dir/all] Error 2
make: *** [all] Error 2
however,
ls -rt /usr/lib64/libXmu*
gives:
lrwxrwxrwx. 1 root root 15 Jan 11 2016 /usr/lib64/libXmu.so.6 -> libXmu.so.6.2.0
-rwxr-xr-x. 1 root root 109552 Nov 20 2015 /usr/lib64/libXmu.so.6.2.0
lrwxrwxrwx. 1 root root 16 Jan 11 2016 /usr/lib64/libXmuu.so.1 -> libXmuu.so.1.0.0
-rwxr-xr-x. 1 root root 19440 Nov 20 2015 /usr/lib64/libXmuu.so.1.0.0
Since its a remote cluster I cannot do a link with the name "libXmu.so" (After requesting the cluster authorities, still there's no use), but I can do the link to my local directory.
Now my question is what should I do in cmake such that, it will look for libXmu.so in my local directory instead of /usr/lib64/libXmu.so
First of all, this is a hack and by no means a proper solution, but you can link directly to a .so file: Link .so file to .cpp file via g++ compiling
Open CMakeLists.txt and remove all references to libXmu linking in target_link_libraries for all targets.
Add /home/user/path/to/libXmu.so to the cmake CXX or link flags. More information on how to do that can be found in: How do I add a linker or compile flag in a CMake file? or: Set CFLAGS and CXXFLAGS options using CMake
I would recommend that you first try something such as:
export CFLAGS=/home/user/path/to/libXmu.so
export CXXFLAGS=/home/user/path/to/libXmu.so
Before running cmake. If this fails, open CMakeLists.txt and try to find where extra CFLAGS and CXXFLAGS are defined and add the path to libXmu.so
Another thing that you can do is you can run make VERBOSE=1, which will show you the exact gcc/g++ command issued, copy it in a text editor and replace -lxmu with /home/user/path/to/libXmu.so
I hope at least one of those works.

The libgit2 examples are not building properly

I have built libgit2 on my Ubuntu 16.04 machine, and everything seemed fine. I ran make in the /examples directory and when I try to run ./log I get the following:
./log: error while loading shared libraries: libgit2.so.26: cannot open shared object file: No such file or directory
But, in the /build folder I indeed have both libgit2.so and libgit2.so.26 so I am not really sure what I am missing. I can post more info if it is needed. I am using cmake version 3.5.1.
The Makefile in the examples will provide guidelines for usage, which should be suitable when you have actually installed libgit2 into system library locations.
To build the examples within the source directory, you should use cmake to build the examples. Given a fresh configuration:
$ mkdir build
$ cd build
$ cmake .. -DBUILD_EXAMPLES=ON
$ cmake --build .
...truncated...
$ examples/log
commit 8ac8c78c35905f7f9cc37f240c3d633a7cc5a5e3
Merge: 34ec6f3 4955125
Author: Edward Thomson <ethomson#edwardthomson.com>
Date: Mon Oct 9 15:15:08 2017 +0100
Merge pull request #4356 from pks-t/pks/static-clar
cmake: use static dependencies when building static libgit2
...truncated...

libcurl Invalid ELF header in new Arch Install

So I just installed Arch and most things are working fine, but when I try to use pacman or curl, I get the error:
pacman: error while loading shared libraries: /usr/lib/libcurl.so.4: invalid ELF header
Also, I can't seem to run anything pacman-related for now... not even a pacman --help
Not sure if useful, but ls -l /usr/lib | grep libcurl gives:
-rw-r--r-- 1 root root 594016 Jun 22 12:21 libcurl.a
lrwxrwxrwx 1 root root 16 Jun 22 12:21 libcurl.so -> libcurl.so.4.3.0
lrwxrwxrwx 1 root root 16 Jun 22 12:21 libcurl.so.4 -> libcurl.so.4.3.0
-rwxr-xr-x 1 root root 408324 Jun 22 12:21 libcurl.s0.4.3.0
Thanks in advance!
Update: running ./curl-config gives the error, "cannot execute binary file". This makes me wonder if maybe I have a 64 bit version, whilst I'm running Arch i686. What is the best way to handle this?
maybe I have a 64 bit version, whilst I'm running Arch i686
That would do it. Run file ./curl-config. If it says ELF 64-bit LSB executable,... reinstall curl from correct packages.

Problems adding DKMS support to kernel module

I'm trying to add DKMS support in a kernel module i'm working on.
I have placed the kernel module source with a static lib to be linked against in the following directory:
/usr/src/dpx/1.0
With the following files:
dkms.conf
Makefile
dpxmtt.c
lib.a
dkms.conf file is like this:
MAKE="make"
CLEAN="make clean"
BUILT_MODULE_NAME=dpx
BUILT_MODULE_LOCATION=src/
DEST_MODULE_LOCATION=/kernel/drivers/input/touchscreen
PACKAGE_NAME=dpxm
PACKAGE_VERSION=1.0
REMAKE_INITRD=yes
And the makefile is like this:
EXTRA_CFLAGS+=-DLINUX_DRIVER -mhard-float
obj-m += dpx.o
dpx-objs:= dpxmtt.o ../source/lib.a
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
The ../source/lib.a is an hack since when the makefile is invoked by the dkms building system it was saying that it couldn't be found in directory (the build directory), but since it was being copied to the source directory, i'm referencing it relatively.
When I call
sudo dkms build -m dpx -v 1.0
The result is almost perfect:
santos#NS-PC:~$ sudo dkms build -m dpx -v 1.0
Kernel preparation unnecessary for this kernel. Skipping...
Building module:
cleaning build area....
make KERNELRELEASE=3.0.0-14-generic....
ERROR (dkms apport): binary package for dpx: 1.0 not found
Error! Build of dpx.ko failed for: 3.0.0-14-generic (i686)
Consult the make.log in the build directory
/var/lib/dkms/dpx/1.0/build/ for more information.
nsantos#NS-PC:~$
And the content of the log file is:
DKMS make.log for dpx-1.0 for kernel 3.0.0-14-generic (i686)
Thu Jan 19 11:07:54 WET 2012
make -C /lib/modules/3.0.0-14-generic/build M=/var/lib/dkms/dpx/1.0/build modules
make[1]: Entering directory `/usr/src/linux-headers-3.0.0-14-generic'
CC [M] /var/lib/dkms/dpx/1.0/build/dpxmtt.o
LD [M] /var/lib/dkms/dpx/1.0/build/dpx.o
Building modules, stage 2.
MODPOST 1 modules
CC /var/lib/dkms/dpx/1.0/build/dpx.mod.o
LD [M] /var/lib/dkms/dpx/1.0/build/dpx.ko
make[1]: Leaving directory `/usr/src/linux-headers-3.0.0-14-generic'
The module was built correctly but it ends with the error:
ERROR (dkms apport): binary package for dpx: 1.0 not found
Error! Build of dpx.ko failed for: 3.0.0-14-generic (i686)
And I don't know what it means. Does anybody know?
Using:
$(shell uname -r)
in the Makefile it might be also wrong! The "shell uname -r" refers to the currently running kernel, but the main reason to use the dkms it's because it offers an automated method to recompile the kernel modules that reside outside of the kernel tree for every newly installed kernel. What i mean is that the Makefile might refers to a different kernel which the dkms is building the module for.
Use:
${kernelver} instead.
I had a similar problem. I think your BUILT_MODULE_LOCATION is set incorrectly to the src directory. It should be set in your example to the current directory, or you can just omit this variable and dkms would default to the current directory.