What Are Ld-Linux.So.2 and Linux-Gate.So.1

What are ld-linux.so.2 and linux-gate.so.1?

I hope that you're not asking about the main entries, which are stating that for the requested library libm.so.6 it was found in the file /lib/libm.so.6, for example, but are asking about the two outliers.

Why are they displayed differently? for linux-gate.so.1 it's because it's not actually a file on-disk - it's exposed by the kernel as the mechanism for making system calls. For /lib/ld-linux.so.2 it's because this is the program interpreter that is used for actually running the application.

There's a pretty good blog entry describing the linux-gate.so, and it explains it pretty well.

For /lib/ld-linux.so.2, you have to understand a little of what happens when you launch an ELF binary. The short answer is that the kernel handler for these types of binaries uses this file for the purposes of launching the application.

The main purpose of this program is to map the binary into memory, load any referenced libraries in the program (e.g. the libm.so.6 previously mentioned), and then hand off control to the starting address of the binary being executed.

This program is defined as part of the structure of the ELF file, in the INTERP section of the program header. For 32bit linux binaries, this is the typical name of the 32bit interpreter. For 64bit binaries, you'll find it is typically called ld-linux-x86_64.so.2 (for 64bit x86 platforms).

You can determine this information yourself using readelf -l, and the INTERP section:

INTERP         0x0000000000000238 0x0000000000400238 0x0000000000400238
               0x000000000000001c 0x000000000000001c  R      1
    [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

Custom ld-linux.so for subprocesses

I think the problem is that the subprocess is reverting to the system /lib64/ld-linux-x86-64.so.2.

That is what one should expect to happen if the execve argument is /path/to/subprocess or subprocess.

If you want the subprocess to use explicit loader invocation /path/to/my/ld-linux-x86-64.so.2 --library-path /path/to/my/libs /path/to/subprocess, then you must arrange for execve arguments to be exactly that.

This is why using patchelf or other solutions from this answer is generally a better approach.

understanding shared libraries using gcc

What does the address given in brackets (for example, (0x002de000)) mean?

It is the (virtual) memory address where the library is loaded.
Recent system can provide randomization of where libraries are loaded though, so
that address might vary between invocations.

shouldn't they be loaded only at runtime?

Yes they are. ldd goes through much of the same procedure as what is
done at runtime though, to be able to figure out various things.

Why does two need any libraries at all?

libc.so.6 is the standard C library (and other stuff, like the interface to the kernel) and is always linked in ny default. gcc has options to control this though, e.g. the -nostdlib flag

ld-linux.so is a the dynamic loader, and is repsonsible for loading/relocating other shared libraryis and run your application. The manpage for ld-linux.so gives you the details.

linux-gate.so.1 is a virtual library, it exists only in memory in the kernel. It's used to perform system calls to the kernel, and figures out the most efficient way to do so based on your CPU. This was probably added to linux later than your other 2.6.9 kernel machine.

I don't know what /usr/lib/libcwait.so is , but chances are you can get some info about it by doing rpm -qif /usr/lib/libcwait.so

ldd cannot find library

Turns out it's an issue with kernel being too old. On newer ones it works fine.

ldd dependencies

You need to link dynamically libA.so into libB.so, that is to build libB.so with something like

 gcc -shared -o libB.so B*.pic.o -lA 

(assuming no libA.a exist, only a libA.so)

And then you could use ldd libB.so to check that it does link libA.so

Look for example into most GUI libraries like /usr/lib/libQtGui.so.4 or /usr/lib/libgtk-3.so, e.g.

% ldd /usr/lib/libgtk-3.so
linux-vdso.so.1 =>  (0x00007fffe4cef000)
libgdk-3.so.0 => /usr/lib/libgdk-3.so.0 (0x00007f5a69c3b000)
libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f5a69a00000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f5a696c0000)
libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007f5a694be000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f5a692bc000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f5a690b5000)
libatk-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007f5a68e92000)
libcairo-gobject.so.2 => /usr/lib/libcairo-gobject.so.2 (0x00007f5a68c8a000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00007f5a689c9000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007f5a687aa000)
libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007f5a68465000)
libpangoft2-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f5a68238000)
libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f5a67feb000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f5a67d4d000)
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f5a67b17000)
libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f5a678c6000)
libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f5a676c3000)
libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007f5a674bd000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f5a672b5000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f5a66fbe000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5a66d3b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f5a66b1f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5a6679b000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f5a66587000)
libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f5a66385000)
libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f5a66176000)
libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f5a65f6d000)
libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f5a65d63000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f5a65b46000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5a65942000)
libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007f5a656ba000)
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f5a65494000)
libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f5a65291000)
libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f5a65087000)
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f5a64e7d000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f5a64c65000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f5a64a44000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f5a6482e000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f5a64604000)
libffi.so.5 => /usr/lib/x86_64-linux-gnu/libffi.so.5 (0x00007f5a643f7000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5a6a50e000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f5a641ba000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f5a63fb7000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f5a63db1000)

ldd shows varied addresses on x86 Linux

Fedora uses address space randomization as part of its various security measures. ldd works by actually loading the shared objects and showing where they end up. Putting the two together results in the given observations.

---

Related Topics