I feel lucky in stumbling across this solution, but wanted to post it up in case anyone else runs across this issue in installing legacy software.
Assuming the install anywhere script is called Install.bin
# cp Install.bin Install.bak
# cat Install.bak | sed "s/export LD_ASSUME_KERNEL/#xport LD_ASSUME_KERNEL/" > Install.bin
# rm Install.bak
This worked nicely.
The fix was originally posted on the Zend Knowledgebase (now 404'ed), it is still archived on linuxquestions.org.
Answer from a coder on Stack Exchangeoperator: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory
libdl.so.2 error in postgres container
Linux Error error while loading shared libraries
Missing libdl.so and other basic libraries
Your library is a dynamic library. You need to tell the operating system where it can locate it at runtime.
To do so, we will need to do those easy steps:
Find where the library is placed if you don't know it.
sudo find / -name the_name_of_the_file.soCheck for the existence of the dynamic library path environment variable(
LD_LIBRARY_PATH)echo $LD_LIBRARY_PATHIf there is nothing to be displayed, add a default path value (or not if you wish to)
LD_LIBRARY_PATH=/usr/local/libWe add the desired path, export it and try the application.
Note that the path should be the directory where the
path.so.somethingis. So ifpath.so.somethingis in/my_library/path.so.something, it should be:export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/my_library/
Reference to source
Here are a few solutions you can try:
ldconfig
As AbiusX pointed out: If you have just now installed the library, you may simply need to run ldconfig.
sudo ldconfig
ldconfig creates the necessary links and cache to the most recent shared libraries found in the directories specified on the command line, in the file /etc/ld.so.conf, and in the trusted directories (/lib and /usr/lib).
Usually your package manager will take care of this when you install a new library, but not always, and it won't hurt to run ldconfig even if that is not your issue.
Dev package or wrong version
If that doesn't work, I would also check out Paul's suggestion and look for a "-dev" version of the library. Many libraries are split into dev and non-dev packages. You can use this command to look for it:
apt-cache search <libraryname>
This can also help if you simply have the wrong version of the library installed. Some libraries are published in different versions simultaneously, for example, Python.
Library location
If you are sure that the right package is installed, and ldconfig didn't find it, it may just be in a nonstandard directory. By default, ldconfig looks in /lib, /usr/lib, and directories listed in /etc/ld.so.conf and $LD_LIBRARY_PATH. If your library is somewhere else, you can either add the directory on its own line in /etc/ld.so.conf, append the library's path to $LD_LIBRARY_PATH, or move the library into /usr/lib. Then run ldconfig.
To find out where the library is, try this:
sudo find / -iname *libraryname*.so*
(Replace libraryname with the name of your library)
If you go the $LD_LIBRARY_PATH route, you'll want to put that into your ~/.bashrc file so it will run every time you log in:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/library
I was able to fix this problem with:
sudo apt install libsdl2-dev
You're getting error when running resulting program because system's dynamic linker cannot find required library. Program requires libSDL2-2.0.so.0, linker looks for it in system-defined directories (/lib, /usr/lib, ..., - defined in /etc/ld.so.conf), but finds none - hence an error.
To inform linker where you want it to look for libraries, you can define LD_LIBRARY_PATH environment variable, e.g. in your case:
export LD_LIBRARY_PATH="$HOME/Desktop/SDL2-2.0.3/install/lib"
./test
Other ways is installing libraries in standard location, defining LD_LIBRARY_PATH in your .bashrc (or whatever shell you use), or using rpath, e.g. adding -Wl,-rpath=$HOME/Desktop/SDL2-2.0.3/install/lib at the end of your compilation line.
You can simply create a symbolic link like so:
$ whereis libdl.so.2
libdl.so.2: /usr/lib/libdl.so.2 /usr/lib32/libdl.so.2
$ sudo ln -s /usr/lib/libdl.so.2 /usr/lib/libdl.so
$ sudo ln -s /usr/lib32/libdl.so.2 /usr/lib32/libdl.so
In my case that's enough for MonoGame.
First step, you should check which libraries (with exact versions) are required for the build.
The dl library is now part of the C standard library. The release notes, tells that, starting from version 2.34, which is yours,
...all functionality formerly implemented in the libraries libpthread, libdl, libutil, libanl has been integrated into libc. New applications do not need to link with -lpthread, -ldl, -lutil, -lanl anymore. For backwards compatibility, empty static archives libpthread.a, libdl.a, libutil.a, libanl.a are provided, so that the linker options keep working. Applications which have been linked against glibc 2.33 or earlier continue to load the corresponding shared objects (which are now empty).
This means that you have to pick an older version of the libc library (before 2.34), typically on an older OS version, or if you know what you are doing, tweak your Makefile (to remove the explicit libdl.so requirement).
From ldd, it is clear that prime is a 32bit/i386 build. It requires dependencies from same architecture. We may confirm too using:
file ./prime
We search for each missing library file using apt-file (if installed, be aware it downloads large indexes) or https://packages.ubuntu.com for corresponding package then install it.
sudo apt install libsigsegv2:i386 \
libsdl1.2debian:i386 libsdl-image1.2:i386 liblua5.1-0:i386 \
libsdl-mixer1.2:i386 libsdl-net1.2:i386
For a so called 64-bit application prime needs a bunch i386 libaries. sudo dpkg --add-architecture i386 afterwards sudo apt update
Make sure the not founding libaries are installed for 64-bit and 32-bit.
You can found the relevant packages with apt-file search missing file.
maybe you have to install it sudo apt install apt-file and sudo apt-file update
How to use apt-file