Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
95

The shared library HOWTO explains most of the mechanisms involved, and the dynamic loader manual goes into more detail. Each unix variant has its own way, but most use the same executable format (ELF) and have similar dynamic linkers (derived from Solaris). Below I'll summarize the common behavior with a focus on Linux; check your system's manuals for the ...


69

When you fail to execute a file that depends on a “loader”, the error you get may refer to the loader rather than the file you're executing. The loader of a dynamically-linked native executable is the part of the system that's responsible for loading dynamic libraries. It's something like /lib/ld.so or /lib/ld-linux.so.2, and should be an executable file. ...


55

You can do this with ldd command: NAME ldd - print shared library dependencies SYNOPSIS ldd [OPTION]... FILE... DESCRIPTION ldd prints the shared libraries required by each program or shared library specified on the command line. .... Example: $ ldd /bin/ls linux-vdso.so.1 => (0x00007fff87ffe000) libselinux....


36

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 ...


32

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 ...


28

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 ...


26

The option is shown as "-l_library_" (no space) or "-l _library_" (with a space) and c is the library argument, see https://linux.die.net/man/1/gcc -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 ...


21

Shared libraries should be versioned according to the following scheme: blah.so.X.Y.Z where 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 ...


20

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 ...


18

libNAME.so is the filename used by the compiler/linker when first looking for a library specified by -lNAME. Inside a shared library file is a field called the SONAME. This field is set when the library itself is first linked into a shared object (so) by the build process. This SONAME is actually what a linker stores in an executable depending on that ...


16

In Linux the behavior is explicited in the ld(1) man page The linker uses the following search paths to locate required shared libraries: 1. Any directories specified by -rpath-link options. 2. Any directories specified by -rpath options. The difference between -rpath and -rpath-link is that directories specified ...


16

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 rm /bin/cat cp /new/version/of/cat /bin/cat will create a logically new ...


13

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 ...


12

open("$ORIGIN/../lib/i386/jli/tls/i686/sse2/cmov/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) The executable you're running looks for libraries in an rpath in addition to the normal library search path. The rpath here is $ORIGIN/../lib/i386/jli:$ORIGIN/../jre/lib/i386/jli. Normally $ORIGIN should be replaced by the location of the ...


12

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 ...


12

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 ...


11

This doesn't exactly answer your question, but... First of all, ELF is the specification use by Linux for executable files (programs), shared libraries, and also object files which are the intermediate files found when compiling software. Object files end in .o, shared libraries end with .so followed by zero or more digits separated by periods, and ...


11

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 ...


11

Actually, you can install multiple versions of a shared library if it's done properly. Shared libraries are usually named as follows: lib<name>.so.<api-version>.<minor> Next, there are symlinks to the library under the following names: lib<name>.so lib<name>.so.<api-version> When a developer links against the library ...


11

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 ...


10

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(): 0000000000400e30 <...


10

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.


10

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; /lib; /usr/lib. (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 ...


9

No, it doesn't. It appears to mean that the version of libz you linked against when you compiled your program was built with different tools than the version on the madriva system you're using. The mandriva copy is missing symbol version info which was present in the copy of the libz library your program originally linked against. This has to do with ...


9

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 ...


8

Yes, it's possible. You'll have to be very careful with the library load paths, and you may need to recompile some other libraries. As the path of least friction, I recommend installing an older version of Debian or Ubuntu in a chroot. That is, make a directory, say /old/etch, and install the older distribution in the tree rooted there; to run that ...


8

No, but the dynamic linker will ignore some environment variables when run with setuid as otherwise you could make it load and run any code as the target user. That goes for LD_LIBRARY_PATH, LD_PRELOAD and more. See ld.so(8).


8

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 ...


8

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 ...


8

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 ...


Only top voted, non community-wiki answers of a minimum length are eligible