I am using ft232r library provided by ftdi for programming an LPC11C14 micro-controller through Linux Mint. To initialize the software, I need to run the following command:
./ft232r_prog --manufacturer Sunswift --product $(PROJECT_NAME) --invert_rts --invert_dtr
When I run the code, I get the following issue:
Error while loading shared libraries: libftdi.so.1: cannot open shared object file: No such file or directory
on running ldd ft232r_prog, I get:
linux-gate.so.1 => (0xf77b8000)
libusb-0.1.so.4 => /lib/i386-linux-gnu/libusb-0.1.so.4 (0xf7790000)
libftdi.so.1 => not found
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf75e5000)
/lib/ld-linux.so.2 (0xf77b9000)
The file libftdi.so.1 is located in /usr/lib/x86_64-linux-gnu. Since the executable ft232r_prog is unable to find the .so file, I have tried the following:
Updated the path environment variable to contain /usr/lib/x86_64-linux-gnu -- Failed
Updated the $LD_LIBRARY_PATH environment variable to contain /usr/lib/x86_64-linux-gnu -- Failed
Ran ldconfig in /usr/lib/x86_64-linux-gnu -- Failed
This appears to be a common issue with including shared libraries. Any ideas on how I can resolve it?
Thanks
To install 32-bit version of libftdi on Ubuntu 12.04 x64 try following:
$ sudo apt-get install libftdi1:i386
I suspect your system is 64-bit and the program is 32-bit. In this case, you need to install the 32-bit version of the library.
Related
I can't run the executable file because of the libz.so.1 library.
I have the libz.so.1 file in file path /usr/lib/x86-64-linux-gnu/libz.so.1, but the error appears. How can I do to solve this? This is the output of the terminal.
aruvi#iris:Desktop/Final_iRTC_witout_ACM_model$ ./main_iRTC_init
./main_iRTC_init: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory
The executable file was compiled for 32 bit environment but now the platform is changed to the 64 bit version. please suggest and guide me to solve the problem.
If your application is compiled for i386 (aka x86, or ia32), then all it's dylib dependencies must be i386 as well (or more generally: all dylib dependencies must be satisfied by the same architecture).
You can install (and run) i386 binaries/packages/dependencies on your Debian system by enabling multiarch:
dpkg --add-architecture i386
apt-get update
apt-get install zlib1g:i386
I've just compiled an executable with stack build and then just copying over the executable to a different machine, however running the application results in:
./app: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory
I'm guessing I need to install some packages from the appropriate Linux distro's packages - but is there more efficient way then googling for each error that comes up and trying to identify the package?
I've tried running executable within some docker images:
fpco/haskell-scratch, debian:stretch-slim which all result in the same behaviour:
sudo docker run --rm -it -v $(pwd):/abcxyz fpco/haskell-scratch sh
# /abcxyz/app
/abcxyz/app: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory
Update
With the debian image I installed openssl:
apt-get install openssl
New error:
/abcxyz/app: error while loading shared libraries: libgmp.so.10: cannot open shared object file: No such file or directory
apt-get install libgmp-dev
And it works...
This is actually not specific to Haskell, but rather to the way Linux dynamically links shared libraries. You can use ldd <file>:
% ldd ./StateSort
linux-vdso.so.1 (0x00007ffd29385000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007fd986bd1000)
libgmp.so.10 => /usr/lib/libgmp.so.10 (0x00007fd98693e000)
librt.so.1 => /usr/lib/librt.so.1 (0x00007fd986736000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fd986532000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fd986314000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fd985f5c000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fd986f1d000)
If there are missing libraries, you will notice them right away: the right hand side with the path to the so file will be absent.
You will then have to refer to your Linux distro's package management system to find out what package may contain the desired so file. For Ubuntu you would use apt-file, for ArchLinux − pkgfile, and so on.
I must warn you that ldd actually executes some of the code found in a file, so a malicious program may take over and wreak havoc. If you want to dissect an executable of unknown origin this way, you must do so in a disposable forensic containment. As I understand, this is not applicable in the case at hand, but nevertheless I must warn you.
Problem
I'm trying to install Python 3 with the --enable-shared option. Installation "succeeds" but the resulting Python is not runnable. Trying to run Python after installation gives the following error:
$ /opt/python3/bin/python3.5
/opt/python3/bin/python3.5: error while loading shared libraries: libpython3.5m.so.1.0: cannot open shared object file: No such file or directory
Background
The OS is Debian (squeeze), and has a previous installation of Python 2.6, which is necessary to retain because other code relies on it, and Apache 2.2. Ultimately what I'm trying to do is set up Django to run on Apache, meaning I'm trying to install mod_wsgi (or mod_wsgi-express), which requires shared libraries. I have already tried to install mod_wsgi without using --enable-shared in the Python installation, and have gotten... well, the same thing, but this time from the mod_wsgi installer (and from pip install mod_wsgi, which I also tried): /opt/python3/bin/python3.5: error while loading shared libraries: libpython3.5m.so.1.0: cannot open shared object file: No such file or directory.
Trace
Starting from an installation as described in Background above, here is the minimum list of commands I've executed that produce the error above (with verbosity removed).
user#server:~$ wget https://www.python.org/ftp/python/3.5.1/Python-3.5.1.tgz
user#server:~$ tar -zxvf Python-3.5.1.tgz
user#server:~$ cd Python-3.5.1
user#server:~/Python-3.5.1$ ./configure --prefix=/opt/python3 --enable-shared
user#server:~/Python-3.5.1$ make && sudo make install
(... appears to install correctly)
user#server:~/Python-3.5.1$ /opt/python3/bin/python3.5
/opt/python3/bin/python3.5: error while loading shared libraries: libpython3.5m.so.1.0: cannot open shared object file: No such file or directory
I have also tried this with LD_RUN_PATH set as described in the solution to this other question, with the same results:
user#server:~/Python-3.5.1$ sudo make distclean
user#server:~/Python-3.5.1$ ./configure --prefix=/opt/python3 --enable-shared
user#server:~/Python-3.5.1$ LD_RUN_PATH=/usr/local/lib make
user#server:~/Python-3.5.1$ sudo make install
user#server:~/Python-3.5.1$ /opt/python3/bin/python3.5
/opt/python3/bin/python3.5: error while loading shared libraries: libpython3.5m.so.1.0: cannot open shared object file: No such file or directory
I have also tried this with Python 3.4, with the same results. I have not tried this with Python 2, because I do not want future development to be limited to Python 2.7 (therefore even a successful installation would not satisfy my requirements). I'm also assuming the attempt would not provide any new or useful information.
I've repeated your steps on CentOS7 and get something similar:
$ /tmp/py3/bin/python3
/tmp/py3/bin/python3: error while loading shared libraries: libpython3.5m.so.1.0: cannot open shared object file: No such file or directory
If you look at the linking of python, it isn't providing a full path to the library:
$ ldd /tmp/py3/bin/python3
linux-vdso.so.1 => (0x00007fff47ba5000)
libpython3.5m.so.1.0 => not found
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fdfaa32e000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fdfaa12a000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007fdfa9f27000)
libm.so.6 => /lib64/libm.so.6 (0x00007fdfa9c24000)
libc.so.6 => /lib64/libc.so.6 (0x00007fdfa9862000)
/lib64/ld-linux-x86-64.so.2 (0x000055e85eac5000)
For some reason, the Python build process isn't adding -rpath to the link line, which would "add a directory to the runtime library search path."
If you explicitly set your library path, it will work:
$ LD_LIBRARY_PATH=/tmp/py3/lib/ /tmp/py3/bin/python3
Python 3.5.1 (default, Jun 10 2016, 14:54:59)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
So now it becomes a question as to whether you want to:
set LD_LIBRARY_PATH globally on your system
Edit /etc/ld.so.conf (or /etc/ld.so.conf.d/*)
Use chrpath to change the embedded path
export LD_RUN_PATH={prefix}/lib before you run configure and make
(Where {prefix} is what you passed to --prefix. You used the wrong path.)
As explained in the mod_wsgi documentation, set LD_RUN_PATH at the time of installing mod_wsgi.
http://modwsgi.readthedocs.io/en/develop/user-guides/installation-issues.html?highlight=ld_run_path#unable-to-find-python-shared-library
When trying to download a Windows XP Virtual Machine from https://www.modern.ie/en-us/virtualization-tools#downloads the file I downloaded has an .sfx extension. The file is IE6.WinXP.For.LinuxVirtualBox.sfx. After downloading the file using wget (and by clicking the link through Icedove), I have the file located in my /root directory. Followed the instructions to make it executable then run the file as follows...
root#kali:~# chmod +x IE6.WinXP.For.LinuxVirtualBox.sfx
root#kali:~# ./IE6.WinXP.For.LinuxVirtualBox.sfx
./IE6.WinXP.For.LinuxVirtualBox.sfx: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
I have tried editing the ld.so.conf file to add /usr/local/lib, I have tried adding /usr/local/lib to LD_LIBRARY_PATH, but still get the same error. I have also tried installing libstcdc++.so.6 with apt-get but unable to locate the package. The following results might help...
root#kali:~# ldd /root/IE6.WinXP.For.LinuxVirtualBox.sfx
linux-gate.so.1 => (0xf7759000)
libstdc++.so.6 => not found
libm.so.6 => /lib32/libm.so.6 (0xf7717000)
libgcc_s.so.1 => not found
libc.so.6 => /lib32/libc.so.6 (0xf75b1000)
/lib/ld-linux.so.2 (0xf775a000)
This is above my head, please could somebody help me get this VM installed. My system info:
Linux kali 3.14-kali1-amd64 #1 SMP Debian 3.14.5-1kali1 (2014-06-07) x86_64 GNU/Linux
Sometimes symbolic links are broken when you do a system update. Try to search for the version of libstdc++ in your computer with the find command(dont forget to run with sudo) and create a symbolic link with that name(libstdc++.so.6) pointing to your existing library.
I compile my project on the Gentoo linux(x86_64) with 2.15 glibc.
Then i copy the *.so and out to centos server (6.2 x86_64) with glibc 2.12.
when i run command:
LD_LIBRARY_PATH=/home/ray/deploy/lib:/opt/glibc-2.15/lib:$LD_LIBRARY_PATH ./deploy/proxy/scan
i got error :
./deploy/proxy/scan: error while loading shared libraries: libchecksum.so: cannot open shared object file: No such file or directory
what confusing me is that when i run command :
sudo LD_LIBRARY_PATH=/home/ray/deploy/lib:/opt/glibc-2.15/lib:$LD_LIBRARY_PATH ./deploy/proxy/scan
it works.
Does anybody know what goes wrong?
ldd info:
linux-vdso.so.1 => (0x00007fff207c1000)
libchecksum.so => /home/ray/deploy/lib/libchecksum.so (0x00007fcccced2000)
libportscan.so => /home/ray/deploy/lib/libportscan.so (0x00007fccccccc000)
libc.so.6 => /opt/glibc-2.15/lib/libc.so.6 (0x00007fcccc926000)
/lib64/ld-linux-x86-64.so.2 (0x00007fcccd0d5000)
it shows that the *.so are found.
Thanks for your comments.
I try to compile on the server machine but the problem still exists.
I try to give 0777 to the libs and run scripts but still not work.
The setcap or sudo disable the LD_LIBRARY_PATH variable. So, it do not work.
You may use rpath option in gcc or just link the shared lib to /usr/lib.