I compiled my program with gcc using openssl crypto library.
I moved the executable to an other system, and after installing openssl tried to run it. I got the following error:
error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory
What I understand from the following the library is present, but has another name:
locate libcrypto
/usr/lib64/.libcrypto.so.1.0.2f.hmac
/usr/lib64/.libcrypto.so.10.hmac
/usr/lib64/libcrypto.so
/usr/lib64/libcrypto.so.1.0.2f
/usr/lib64/libcrypto.so.10
/usr/lib64/pkgconfig/libcrypto.pc
Can I somehow tell the binary to use one of the present libraries? Or is there a way to install the one which is required?
The compilation was done on Ubuntu 15.10 64 bit, tried to run on Fedora 4.2.3-300.fc23.x86_64.
Can I somehow tell the binary to use one of the present libraries?
No, you can't: there is a reason these libraries have a different name: they are not ABI-compatible. If you managed to somehow tell the binary to use the other library, the result will be a crash if you are lucky, or a silent corruption if you are not.
(BTW, you can try this by creating a symbolic link: ln -s libcrypto.so.1.0.2f libcrypto.so.1.0.0, but you've been warned not to do this).
is there a way to install the one which is required?
Sure: you should be able to copy libcrypto.so.1.0.0 from Ubuntu machine to Fedora one, assuming you can't find a Fedora package that provides it.
Related
I am trying to run the metal executable from my zsh terminal in order to meta-analyze GWAS data. I have the executable in the correct directory and have checked that it is not 0MB due to truncation.
Reproducible:
Download the Linux file from http://csg.sph.umich.edu/abecasis/metal/download/
In terminal:
PATH TO EXECUTABLE ./metal
zsh: exec format error: ./metal
You probably install wrong OS of go, for example, you might install go for MacOS in Linux
I solve this problem by installing go for correct OS
The executable has been pre-compiled on a certain distribution with libraries at a certain places at certain versions.
If you have a different distribution, libraries versions, it won't work and you better compile from the source.
Basically what you have to do is to download and extract the sources, go in the folder and execute make. (You will have probably to install make first.)
I think that's not your job at all so maybe you can find a geeky person to help you, because you may stumble upon problems, libraries to install, old versions not supported anymore, new versions not supported yet...
It happened to me when I emptied an executable by mistake.
~>true > a
~>wc -c a
0 a
~>./a
zsh: exec format error: ./a
Background: I compile bitcoind on one system but run it on another. When I compiled bitcoind 0.19.1 some time back using the following method, I was able to run bitcoind and bitcoin-cli on the target system without issue. I think.
./autogen.sh
./configure --disable-wallet --disable-tests --disable-bench --disable-gui --enable-util-tx=no --prefix=$HOME/bitcoind/x64 --exec-prefix=$HOME/bitcoind/x64
make && make install
Today I compiled v0.20.0 using the same method. If I run ./bitcoind -version on the system I compiled the binary it runs fine, but if I take the binary to my target system I get the following error:
./bitcoind: error while loading shared libraries: libboost_filesystem.so.1.67.0: cannot open shared object file: No such file or directory
The binary seemed to be portable last time, and the pre-compiled binary I download from the Bitcoin Core team runs fine.
Note that on the target system libboost-filesystem-dev and libboost-filesystem1.67-dev are not installed, this is likely the source of my error. That said, running the pre-compiled binary from the Core team runs, so why doesn't mine?
Can someone help me understand if I did something wrong or if I need to add ./configure flags to make the binary more portable? Specifically what I likely did differently than the core developers that made my binary fail where theirs worked?
EDIT 1: Running ./configure --enable-static or ./configure LDFLAGS=-static does not result in a portable binary either.
Also note that installing libboost-filesystem library with apt does fix the error.
Thanks to Andrew Chow for his helpful answer to this on the bitcoind StackExchange. I needed to build the depends as per the depends documentation. Since I'm building for the same platform I'll be running on, I can run make in the depends directory with no arguments except -j2 which uses two cores. Change the number to however many cores you want to commit to the compile.
cd depends
make -j2
cd ..
./autogen.sh
./configure --prefix=$PWD/depends/x86_64-pc-linux-gnu
make -j2 && make install
So I'm using the new Bash on Ubuntu on Windows shell, and installed the clisp package to mess with Common Lisp. I get this error when I try clisp test.clisp:
/usr/lib/clisp-2.49/base/lisp.run: error while loading shared libraries: libavcall.so.0: cannot enable executable stack as shared object requires: Invalid argument
This is an entirely fresh install too. I looked in /usr/lib and found the libavcall.so.0 file, but I'm not sure what to do with it. How do I fix this issue?
This issue no longer exists with libffcall 2.0 or newer. It was fixed through this commit.
If you are still using libffcall 1.x: The FAQ (cited by user #cybevnm) explains most of it:
libavcall.so is flagged as requiring executable stack (property GNU_STACK has the value RWE), although it does not need an executable stack. This occurs because it was compiled from assembly-language source code.
You can remove this flag through a command such as sudo execstack -c /usr/lib/libavcall.so.0.
When compiling with -fsanitize=memory I get WARNING: Trying to symbolize code, but external symbolizer is not initialized! when running the program. How do I initialize the external symbolizer?
I solved my own problem using MSAN_SYMBOLIZER_PATH=$(which llvm-symbolizer-3.4) ./a.out. The problem is that Ubuntu postfixes the version number but the binary doesn't know that. Of course you need to use MSAN instead of ASAN when using the memory sanitizer.
You are supposed to be able to set the ASAN_FILTER environment variable to point at a symbolizer, but I could not get it to work. However, you can redirect stderr into a symbolizer after the fact. You'll still get the warnings about the uninitialized symbolizer, but the filenames and line numbers will be correct.
You can use asan_symbolizer.py as the external symbolizer. After downloading it from that link (to /tmp, for example), invoke your program like so (in bash, for this example):
./myprogram 2>&1 | /tmp/asan_symbolize.py | c++filt
On my Ubuntu system, the issue is that LLVM's tools are installed under /usr/bin with version suffixes (like llvm-symbolizer-4.0), and the sanitizer tools are looking for them without version suffixes.
LLVM also installs its binaries to, e.g., /usr/lib/llvm-4.0/bin; the tools under /usr/bin are actually just symlinks. So an easy solution is to add the appropriate /usr/lib/llvm-*/bin directory to your path when working with sanitizers.
I received such warning when I run program debug version (compiled with -fsanitize=address) on Linux machine that didn't contain clang installation. The problem disappeared after I installed clang from devtoolset.
I am trying to compile Network.HTTP (http://hackage.haskell.org/package/network) on win32/cygwin. However, it does fail with following message:
Setup.hs: Missing dependency on a foreign library:
* Missing (or bad) header file: HsNet.h
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
If the header file does exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
Unfortuntely it does not give more clues. The HsNet.h includes sys/uio.h which, actually should not be included, and should be configurered correctly.
Don't use cygwin, instead follow Johan Tibells way
Installing MSYS
Install the latest Haskell Platform. Use the default settings.
Download version 1.0.11 of MSYS. You'll need the following files:
MSYS-1.0.11.exe
msysDTK-1.0.1.exe
msysCORE-1.0.11-bin.tar.gz
The files are all hosted on haskell.org as they're quite hard to find in the official MinGW/MSYS repo.
Run MSYS-1.0.11.exe followed by msysDTK-1.0.1.exe. The former asks you if you want to run a normalization step. You can skip that.
Unpack msysCORE-1.0.11-bin.tar.gz into C:\msys\1.0. Note that you can't do that using an MSYS shell, because you can't overwrite the files in use, so make a copy of C:\msys\1.0, unpack it there, and then rename the copy back to C:\msys\1.0.
Add C:\Program Files\Haskell Platform\VERSION\mingw\bin to your PATH. This is neccesary if you ever want to build packages that use a configure script, like network, as configure scripts need access to a C compiler.
These steps are what Tibell uses to compile the Network package for win and I have used this myself successfully several times on most of the haskell platform releases.
It is possible to build network on win32/cygwin. And the above steps, though useful (by Jonke) may not be necessary.
While doing the configuration step, specify
runghc Setup.hs configure --configure-option="--build=mingw32"
So that the library is configured for mingw32, else you will get link or "undefined references" if you try to link or use network library.
This combined with #Yogesh Sajanikar's answer made it work for me (on win64/cygwin):
Make sure the gcc on your path is NOT the Mingw/Cygwin one, but the
C:\ghc\ghc-6.12.1\mingw\bin\gcc.exe
(Run
export PATH="/cygdrive/.../ghc-7.8.2/mingw/bin:$PATH"
before running cabal install network in the Cygwin shell)