You can do this with ldd command:
ldd - print shared library dependencies
ldd [OPTION]... FILE...
ldd prints the shared libraries required by each program or shared
library specified on the command line.
$ ldd /bin/ls
linux-vdso.so.1 => (0x00007fff87ffe000)
readelf -d $executable | grep 'NEEDED'
Can be used if you can't run the executable, e.g. if it was cross compiled, or if you don't trust it:
In the usual case, ldd invokes the standard dynamic linker (see ld.so(8)) with the LD_TRACE_LOADED_OBJECTS environment variable set to 1, which causes the linker to display the library
dependencies. Be ...
dlopen isn't a system call, it's a library function in the libdl library. Only system calls show up in strace.
On Linux and on many other platforms (especially those that use the ELF format for executables), dlopen is implemented by opening the target library with open() and mapping it into memory with mmap(). mmap() is really the critical part here, it's ...
Shared libraries should be versioned according to the following scheme:
X = backwards incompatible ABI release
Y = backwards compatible ABI release
Z = Internal changes only - no change to the ABI
Typically you only see the first digit like hello.so.1 because the first digit is the only thing needed to identify the "version" of the ...
But why does it not do the same until it finds the expected version rather than accepting the first instance of library irrespective of its version?
It does, as far as it’s aware. zlib.so.1.2.7 and zlib.so.1.2.8 both have an soname of zlib.so.1, so your alpha and bravo binaries say they need zlib.so.1. The dynamic loader loads the first matching library it ...
The gold linker was designed as an ELF-specific linker, with the intention of producing a more maintainable and faster linker than BFD ld (the “traditional” GNU binutils linker). As a side-effect, it is indeed able to link very large programs using less memory than BFD ld, presumably because there are fewer layers of abstraction to deal with, and because the ...
The option is shown as "-l_library_" (no space) or "-l _library_" (with a space) and c is the library argument,
-lc will link libc (-lfoobar would link libfoobar etc.)
General information about options and arguments
UNIX commands often accept option arguments with or without whitespace. If you have an option o which ...
As mentioned in Why does a software package run just fine even when it is being upgraded?, the lock is placed on inode not on filename. When you load and execute a binary, the the file is marked as busy - which is why you get ETXTBSY (file busy) error when you try to write to it.
Now, for shared libraries it is slightly different: the libraries get memory ...
The order is documented in the manual of the dynamic linker, which is ld.so. It is:
directories from LD_LIBRARY_PATH;
directories from /etc/ld.so.conf;
(I'm simplifying a little, see the manual for the full details.)
The order makes sense when you consider that it's the only way to override a library in a default location with a custom ...
ldd and lsof show the libraries loaded either directly or at a given moment. They do not account for libraries loaded via dlopen (or discarded by dlclose). You can get a better picture of this using strace, e.g.,
strace -e trace=open myprogram
(since dlopen ultimately calls open - though you may of course have a system using different names for 64-bit ...
ldconfig can list all the libraries it has access to. These libraries are also stored in its cache.
/sbin/ldconfig -v -N will crawl all the usual library paths, list all the available libraries, without reconstructing the cache (which is not possible if you're a non-root user). It does NOT take into account libraries in LD_LIBRARY_PATH (contrarily to what ...
Yes, it links itself when it initialises. Technically the dynamic linker doesn’t need object resolution and relocation for itself, since it’s fully resolved as-is, but it does define symbols and it has to take care of those when resolving the binary it’s “interpreting”, and those symbols are updated to point to their implementations in the loaded libraries. ...
The paths to look for libraries in will be listed in the file /etc/ld.so.conf, the environment variable LD_LIBRARY_PATH and any RPATHs encoded into the ELF binary. The program ldd will tell you what libraries a specific application will load.
Once you have a symbol you are curious about, you can use the program nm to dump symbols of .o and .a files and ...
The path to the loader is compiled into the binary as you discovered with your hex editor. You actually got lucky that editing the binary directly worked because both /lib/ld-linux.so.2 and /home/chroot/ld.so are the same length. The lengths of those strings are also in the binary and you can cause subtle problems if you modify the strings directly.
If you ...
As mentioned by @Kusalananda, usually upgrades are done by removing the old file, and creating a new one with the same name. This will actually create a new file with a new inode, leaving the system free to use the old one as long as it is open.
As a simplified example, stuff like
cp /new/version/of/cat /bin/cat
will create a logically new ...
You probably don’t want to “solve” this problem; according to the Debian glibc manpage for ld.so,
/etc/ld.so.nohwcap When this file is present the dynamic linker will load the non-optimized version of a library, even if the CPU supports the optimized version.
It’s not installed by a package, it can be created by the system administrator to ...
System calls are implemented in the kernel, as mentioned in the answer to your followup question. vDSO, the virtual dynamic shared object, is a small virtual library, also implemented by the kernel, which the kernel maps into all processes. Like syscalls it is wrapped by the C library.
The main difference between syscalls and the vDSO is one of privilege. ...
Actually, you can install multiple versions of a shared library if it's done properly.
Shared libraries are usually named as follows:
Next, there are symlinks to the library under the following names:
When a developer links against the library ...
The following is a really good reference: http://www.ibm.com/developerworks/linux/library/l-dynamic-libraries/. It contains a bibliography at the end of a variety of different references at different levels. If you want to know every gory detail you can go straight to the source: http://www.akkadia.org/drepper/dsohowto.pdf. (Ulrich Drepper wrote the Linux ...
The gold linker was written to make the link process considerably faster. According to the gold auther Ian Lance Taylor
At the moment gold has only one significant advantage over the
existing linker: it is faster. On large C++ programs, I have measured
it as running five times faster.
He is comparing gold linker performance with the traditional GNU ...
The start address is the address of main(), right?
Not really: The start of a program isn't really main(). By default, GCC will produce executables whose start address corresponds to the _start symbol. You can see that by doing a objdump --disassemble Q1. Here's the output on a simple program of mine that only does return 0; in main():
You can't usually run binary files in NixOS, they will either need some environment variables set or to be patched with patchElf. I assume you can install and run java using the nix package manager. You can probably also create a suitable environment to run it using myEnvFun.
lsof also can show you which libraries are being used for one particular process.
$ pidof nginx
$ lsof -p 6919|grep mem
nginx 6919 root mem REG 0,64 65960 43 /lib64/libnss_files-2.12.so
nginx 6919 root mem REG 0,64 19536 36 /lib64/libdl-2.12.so
nginx 6919 root mem REG ...
I don't have the same binary you have but I made a little test and it
seems that patchelf can work here. I have a hello binary compiled
with -Wl,-rpath=/home/ja/c/hello-puts/make/lib and libtest.so as a
$ ldd hello
libtest.so => /home/ja/c/hello-puts/make/lib/libtest.so (0x00007f04a2437000)...
A very similar question was asked on Stack Overflow: How to extract function prototype from an ELF file?
In short: generally you can't. If the executable (or shared library) doesn't have debug information, the information on the number and type of arguments is not stored in the executable.
If the shared object file does have debug information, then you ...
I think the answer to your question is no, although you can accomplish the same thing other ways.
in man ld.so, I see no mention of being able to use custom .conf or .cache
True, but there is mention of $LD_LIBRARY_PATH and and --library-path, the former being more generally useful.
what's the point of the above two options of ldconfig then?
So you ...
I found two ways to do this:
Debian-specific, lists most deleted/replaced files held by processes (with the exception of certain files known to be transient, e.g. stuff in /tmp): The debian-goodies package contains checkrestart, which accomplishes something like what I've described by scraping the output of lsof to find open files that are gone or replaced ...
The working solution is using patchelf (if you have to deal with non-matching glibc versions: in the host system and the one nix libs have been linked with), see the second half of my story.
Trying the usual approach
Trying to use LD_LIBRARY_PATH
Well, I have set up an environment variable for this in ~/.bash_profile:
The answer is "Other". You can get a glimpse of the memory layout with cat /proc/self/maps. On my 64-bit Arch laptop::
00400000-0040c000 r-xp 00000000 08:02 1186758 /usr/bin/cat
0060b000-0060c000 r--p 0000b000 08:02 1186758 /usr/bin/cat
0060c000-0060d000 rw-p 0000c000 08:02 1186758 ...