This article introduces C standard library and its implementations on Linux system.

C Standards

Refer to C Standards.

C++ Standards

Refer to C++ Standards.

Online References of C/C++ Language & Libraries

The online references of C/C++ language & libraries can be found on website:

• CppReference.com Home Page
• C Reference on CppReference.com
• C++ Reference on CppReference.com

Also, you can download the offline archives from website:

• Archives for offline viewing

C Standard Library header files

The C Standard Library header files are listed in following table. It also can be found here on CppReference.com.

C++ Standard Library header files

The C++ Standard Library header files can be found here on CppReference.com.

GNU Compiler Collection (GCC)

GCC Releases

Refer to GCC Releases for more details.

Content of GCC 4.8.4

The Linux From Scratch (LFS) introduces the installation of GCC and its content.

The GCC 4.8.4 installs the following programs:

The GCC 4.8.4 installs the following libraries:

Those following directories are created by GCC 4.8.4:

GNU C Library (glibc)

The GNU C Library, commonly known as glibc, is the GNU Project’s implementation of the C standard library. Despite its name, it now also directly supports C++ (and indirectly other programming languages). Was started in the early 1990s by the Free Software Foundation (FSF) for their GNU operating system. Released under the GNU Lesser General Public License (LGPL), glibc is free software.

glibc Releases

glibc Repository

In 2009, glibc was migrated to a Git repository on Sourceware. You can browse the glibc source code on gitweb. The Community wiki for GLIBC answers questions a user might have when installing and using glibc. And use following command to clone the git repository:

chenwx@chenwx ~ $ git clone git://sourceware.org/git/glibc.git
chenwx@chenwx ~ $ cd glibc/
chenwx@chenwx ~/glibc $ git br
* master
chenwx@chenwx ~/glibc $ git tag -l glibc-*
...
glibc-2.20
glibc-2.21
glibc-2.22

Build & Install glibc from source

If you want to build the glibc from source code, you can follow the Glibc-2.22 on Linux From Scratch (LFS). Also refer to 使用源代码将Glibc升级到2.6.

The glibc-2.22 installs following programs:

The glibc-2.19 installs following libraries:

Those following directories are created by glibc:

C Standard Library for Embedded System (newlib)

What’s newlib?

Newlib is a C library intended for use on embedded systems. It is a conglomeration of several library parts, all under free software licenses that make them easily usable on embedded products.

Newlib is only available in source form. It can be compiled for a wide array of processors, and will usually work on any architecture with the addition of a few low-level routines.

Newlib can be downloaded from ftp directory or accessed by web-based GIT.

newlib Repository

chenwx@chenwx ~ $ git clone git://sourceware.org/git/newlib-cygwin.git

GNU C++ Library (libstdc++)

The GNU Standard C++ Library v3 (libstdc++-v3) is an ongoing project to implement the ISO 14882 Standard C++ library as described in clauses 17 through 30 and Annex D. For those who want to see exactly how far the project has come, or just want the latest bleeding-edge code, the up-to-date source is available over anonymous SVN, and can be browsed over the web. Also refer to following websites for more details:

• GNU C++ Library
• GNU C++ Library Online Documentation
• GNU C++ Library API Reference
• The C++ Runtime Library (libstdc++)
• GNU C++ Library FAQ

The glibstdc++ installs following libraries, refer to section Content of GCC 4.8.4 of this article:

Static Library (.a)

What’s static library?

As stated in wikipedia, a static library or statically-linked library is a set of routines, external functions and variables which are resolved in a caller at compile-time and copied into a target application by a compiler, linker, or binder, producing an object file and a stand-alone executable. This executable and the process of compiling it are both known as a static build of the program. Historically, libraries could only be static. Static libraries are either merged with other static libraries and object files during building/linking to form a single executable, or they may be loaded at run-time into the address space of the loaded executable at a static memory offset determined at compile-time/link-time.

Advantages and disadvantages

There are several advantages to statically linking libraries with an executable instead of dynamically linking them. The most significant is that the application can be certain that all its libraries are present and that they are the correct version. This avoids dependency problems, known colloquially as DLL Hell or more generally dependency hell. Static linking can also allow the application to be contained in a single executable file, simplifying distribution and installation.

With static linking, it is enough to include those parts of the library that are directly and indirectly referenced by the target executable (or target library). With dynamic libraries, the entire library is loaded, as it is not known in advance which functions will be invoked by applications. Whether this advantage is significant in practice depends on the structure of the library.

In static linking, the size of the executable becomes greater than in dynamic linking, as the library code is stored within the executable rather than in separate files. But if library files are counted as part of the application then the total size will be similar, or even smaller if the compiler eliminates the unused symbols.

Creating a Static Library

Static libraries can be easily created in C or C++. These two languages provide storage-class specifiers for indicating external or internal linkage, in addition to providing other features. To create such a library, the exported functions/procedures and other objects variables must be specified for external linkage (i.e. by not using the C keyword static). Static library filenames usually have a .a extension on Unix-like systems and .lib on Microsoft Windows.

To create a static library, or to add additional object files to an existing static library, use a command like this:

chenwx@chenwx ~/helloworld $ cat helloworldlib1.c
#include <stdio.h>

void printHelloWorld()
{
    printf("Hello World!\n");
}

chenwx@chenwx ~/helloworld $ cat helloworldlib2.c
#include <stdio.h>

void printUserName(char *name)
{
    printf("Hello World! %s\n", name);
}

chenwx@chenwx ~/helloworld $ cc -Wall -c -o helloworldlib1.o helloworldlib1.c
chenwx@chenwx ~/helloworld $ cc -Wall -c -o helloworldlib2.o helloworldlib2.c

chenwx@chenwx ~/helloworld $ ar crsv libhelloworld.a helloworldlib1.o helloworldlib2.o
a - helloworldlib1.o
a - helloworldlib2.o

[Historical Note] After creating the library it was once necessary to run the command ranlib libhelloworld.a to create a symbol table within the archive. Now, the ranlib is embedded into the ar command.

List Information of Static Library

# Display a table listing the contents of archive
chenwx@chenwx ~/helloworld $ ar -t libhelloworld.a
helloworldlib1.o
helloworldlib2.o

# List symbols from object files
chenwx@chenwx ~/helloworld $ nm libhelloworld.a

helloworldlib1.o:
0000000000000000 T printHelloWorld
                 U puts

helloworldlib2.o:
0000000000000000 T printUserName
                 U printf

Using Static Library

To compile a program that depends on the library libhelloworld.a, one could do:

chenwx@chenwx ~/helloworld $ cat testhelloworld.c
int main()
{
    char *userName = "Alex";
    printHelloWorld();
    printUserName(userName);

    return 0;
}

chenwx@chenwx ~/helloworld $ cc -o testhelloworld testhelloworld.c libhelloworld.a
chenwx@chenwx ~/helloworld $ ./testhelloworld
Hello World!
Hello World! Alex

or, run the following command if libhelloworld.a is placed in standard library path, like /usr/local/lib:

chenwx@chenwx ~/helloworld $ cc -lhelloworld -o testhelloworld testhelloworld.c

or, run the following command if libhelloworld.a is placed a directory other than standard library path:

chenwx@chenwx ~/helloworld $ cc -L/path/to/library-directory -lhelloworld -o testhelloworld testhelloworld.c

or, link the libhelloworld.a during linking stage:

chenwx@chenwx ~/helloworld $ cc -c -o testhelloworld.o testhelloworld.c
chenwx@chenwx ~/helloworld $ ld -lhelloworld -o testhelloworld testhelloworld.o

Shared Library (.so)

What’s shared library?

A shared library or shared object is a file that is intended to be shared by executable files and further shared object files. Modules used by a program are loaded from individual shared objects into memory at load time or run time, rather than being copied by a linker when it creates a single monolithic executable file for the program.

Shared libraries can be statically linked, meaning that references to the library modules are resolved and the modules are allocated memory when the executable file is created. But often linking of shared libraries is postponed until they are loaded.

Naming Convention of Shared Libraries

Every shared library has a special name called the soname. The soname has the prefix lib, the name of the library, the phrase .so, followed by a period and a version number that is incremented whenever the interface changes (as a special exception, the lowest-level C libraries don’t start with lib), that’s lib<name>.so.X. A fully-qualified soname includes as a prefix the directory it’s in; on a working system a fully-qualified soname is simply a symbolic link to the shared library’s real name.

Every shared library also has a real name, which is the filename containing the actual library code. The real name adds to the soname a period, a minor number, another period, and the release number, that’s lib<name>.so.X.Y[.Z]. The last period and release number (.Z) are optional. The minor number and release number (.Y) support configuration control by letting you know exactly what version(s) of the library are installed. Note that these numbers might not be the same as the numbers used to describe the library in documentation, although that does make things easier.

In addition, there’s the name that the compiler uses when requesting a library, linker name, which is simply the soname without any version number, that’s lib<name>.so.

Advantages and disadvantages

As this article said, a shared library offers several benefits, like:

• Save disk storage space

  Shared library code is not copied into all the executable files that use that code. The executable files are smaller and use less disk space.

• Save memory

  By sharing library code at run time the dynamic memory needs of the processes are reduced.

• Easier to maintain

  Make executable files using library code easier to maintain.

  At run time shared library code is brought into the processes’ address space. Therefore, updating a shared library effectively updates all executable files that use the library. If an error in shared library code is fixed, all processes automatically use the corrected code.

  Non-shared libraries cannot offer this benefit: changes to archive libraries do not affect executable files, because code from the libraries is copied to the files during link editing, not during execution.

As this article said, the dynamic linking offers several advantages over static linking:

• Code Sharing

  With dynamic linking, programs can share identical code instead of owning individual copies of the same library. Think of the standard C or C++ libraries. They are both huge and ubiquitous. Every C or C++ program uses at least a portion of these libraries for I/O, date and time manipulation, memory allocation, string processing, and so on. If distinct copies of these libraries were statically linked into every executable file, even tiny programs would occupy dozens of megabytes.

  Worse yet, whenever a new version of the said libraries is released, every executable file would have to be replaced with a newly-linked executable in order to reflect the change. Fortunately, these libraries are usually implemented as shared dynamic libraries that are loaded into the core program at runtime.

• Automatic Updates

  Whenever a new version of a dynamically-linked library is installed, it automatically supercedes the previous version. When you run a program, it automatically picks the most up-to-date version without forcing the user to re-link.

• Security

  If you’re concerned about protecting your intellectual property, splitting an application into several linkage units makes it harder for crackers to disassemble and decompile an executable file (at least in theory).

Creating a Shared Library

Use following commands to create a shared library:

chenwx@chenwx ~/helloworld $ cat helloworldlib1.c
#include <stdio.h>

void printHelloWorld()
{
    printf("Hello World!\n");
}

chenwx@chenwx ~/helloworld $ cat helloworldlib2.c
#include <stdio.h>

void printUserName(char *name)
{
    printf("Hello World! %s\n", name);
}

chenwx@chenwx ~/helloworld $ cc -Wall -fPIC -c -o helloworldlib1.o helloworldlib1.c
chenwx@chenwx ~/helloworld $ cc -Wall -fPIC -c -o helloworldlib2.o helloworldlib2.c
chenwx@chenwx ~/helloworld $ cc -shared -Wl,-soname,libhelloworld.so.1 -o libhelloworld.so.1.0 helloworldlib1.o helloworldlib2.o

chenwx@chenwx ~/helloworld $ ll libhelloworld.so.1.0
-rwxrwxr-x 1 chenwx chenwx 8.0K Dec 29 20:54 libhelloworld.so.1.0

henwx@chenwx ~/helloworld $ objdump -p libhelloworld.so.1.0 | grep SONAME
  SONAME               libhelloworld.so.1

Compiler options:

• -Wall Include warnings. See man page for warnings specified.
• -fPIC Compiler directive to output position independent code, a characteristic required by shared libraries. The -fPIC always works, but may produce larger code than -fpic (mnenomic to remember this is that PIC is in a larger case, so it may produce larger amounts of code). Using -fpic option usually generates smaller and faster code, but will have platform-dependent limitations, such as the number of globally visible symbols or the size of the code. The linker will tell you whether it fits when you create the shared library. When in doubt, choose -fPIC, because it always works.
• -shared Produce a shared object which can then be linked with other objects to form an executable.
• -Wl,options Pass options to linker.

Here are a few points worth noting:

• Don’t strip the resulting library, and don’t use the compiler option -fomit-frame-pointer unless you really have to. The resulting library will work, but these actions make debuggers mostly useless.

• In some cases, the call to gcc to create the object file will also need to include the option -Wl,-export-dynamic. Normally, the dynamic symbol table contains only symbols which are used by a dynamic object. This option (when creating an ELF file) adds all symbols to the dynamic symbol table (see ld(1) for more information). You need to use this option when there are reverse dependencies, i.e., a DL library has unresolved symbols that by convention must be defined in the programs that intend to load these libraries. For reverse dependencies to work, the master program must make its symbols dynamically available. Note that you could say -rdynamic instead of -Wl,export-dynamic if you only work with Linux systems, but according to the ELF documentation the -rdynamic flag doesn’t always work for gcc on non-Linux systems.

For more detail about creating shared library, refer to How to Write Shared Libraries.

Installing and Using a Shared Library

Standard Directory

Once you’ve created a shared library, you’ll want to install it. The simple approach is simply to copy the library into one of the standard directorie, (e.g., /lib, /usr/lib or /usr/local/lib) and run ldconfig.

First, you need to create the shared libraries somewhere. Then, set up the necessary symbolic links, in particular a link from a soname to the real name (as well as from a versionless soname, that is, a soname that ends in .so for users who don’t specify a version at all). The simplest approach is to run:

chenwx@chenwx ~/helloworld $ sudo cp libhelloworld.so.1.0 /lib/
[sudo] password for chenwx:

chenwx@chenwx ~/helloworld $ ldconfig -n /lib/
chenwx@chenwx ~/helloworld $ ll /lib/libhelloworld.so*
lrwxrwxrwx 1 root root   20 Dec 30 19:40 /lib/libhelloworld.so.1 -> libhelloworld.so.1.0
-rwxr-xr-x 1 root root 8.0K Dec 29 21:24 /lib/libhelloworld.so.1.0

chenwx@chenwx ~/helloworld $ sudo ln -s /lib/libhelloworld.so.1 /lib/libhelloworld.so
chenwx@chenwx ~/helloworld $ ll /lib/libhelloworld.so*
lrwxrwxrwx 2 root root   20 Dec 30 19:40 /lib/libhelloworld.so -> libhelloworld.so.1.0
lrwxrwxrwx 2 root root   20 Dec 30 19:40 /lib/libhelloworld.so.1 -> libhelloworld.so.1.0
-rwxr-xr-x 1 root root 8.0K Dec 29 21:24 /lib/libhelloworld.so.1.0

chenwx@chenwx ~/helloworld $ sudo ldconfig /lib
chenwx@chenwx ~/helloworld $ ldconfig -p | grep helloworld
	libhelloworld.so.1 (libc6,x86-64) => /lib/libhelloworld.so.1
	libhelloworld.so (libc6,x86-64) => /lib/libhelloworld.so

If the shared library is put into standard directory, then you’ll need to tell the linker about shared library:

chenwx@chenwx ~/helloworld $ cat testhelloworld.c
int main()
{
    char *userName = "Alex";
    printHelloWorld();
    printUserName(userName);

    return 0;
}

chenwx@chenwx ~/helloworld $ cc -o testhelloworld testhelloworld.c -lhelloworld
chenwx@chenwx ~/helloworld $ ll testhelloworld
-rwxrwxr-x 1 chenwx chenwx 8.5K Dec 30 21:12 testhelloworld
chenwx@chenwx ~/Downloads/helloworld $ ./testhelloworld
Hello World!
Hello World! Alex

NOTE: Libraries must be listed after the objects that use them (more precisely, a library will be used only if it contains a symbol that satisfies an undefined reference known at the time it is encountered). So here the -lhelloworld is appended after cc -o testhelloworld testhelloworld.c. Otherwise, you’ll get following error:

chenwx@chenwx ~/helloworld $ cc -lhelloworld -o testhelloworld testhelloworld.c             
/tmp/cccQMBIY.o: In function `main':
testhelloworld.c:(.text+0x16): undefined reference to `printHelloWorld'
testhelloworld.c:(.text+0x27): undefined reference to `printUserName'
collect2: error: ld returned 1 exit status

Non-standard Directory

If you can’t or don’t want to install a library in a standard place (e.g., you don’t have the right to modify /lib, /usr/lib or /usr/local/lib), then you’ll need to change your approach. In that case, you’ll need to install it somewhere:

chenwx@chenwx ~/helloworld $ mkdir ~/lib
chenwx@chenwx ~/helloworld $ cp libhelloworld.so.1.0 ~/lib/
chenwx@chenwx ~/helloworld $ ln -s ~/lib/libhelloworld.so.1.0 ~/lib/libhelloworld.so.1   
chenwx@chenwx ~/helloworld $ ln -s ~/lib/libhelloworld.so.1.0 ~/lib/libhelloworld.so  
chenwx@chenwx ~/helloworld $ ll ~/lib/
lrwxrwxrwx 1 chenwx chenwx   37 Dec 30 21:29 libhelloworld.so -> /home/chenwx/lib/libhelloworld.so.1.0
lrwxrwxrwx 1 chenwx chenwx   37 Dec 30 21:29 libhelloworld.so.1 -> /home/chenwx/lib/libhelloworld.so.1.0
-rwxrwxr-x 1 chenwx chenwx 8.0K Dec 30 21:28 libhelloworld.so.1.0

Then give your program enough information so the program can find the library… and there are several ways to do that. You can use gcc’s -L flag in simple cases:

chenwx@chenwx ~/helloworld $ cc -o testhelloworld testhelloworld.c -L/home/chenwx/lib -lhelloworld
chenwx@chenwx ~/helloworld $ ll testhelloworld
-rwxrwxr-x 1 chenwx chenwx 8.5K Dec 30 21:30 testhelloworld

Or, you can use the rpath approach, particularly if you only have a specific program to use the library being placed in a non-standard place. You can also use environment variables to control things. In particular, you can set LD_LIBRARY_PATH, which is a colon-separated list of directories in which to search for shared libraries before the usual places.

NOTE: LD_LIBRARY_PATH is handy for development and testing, but shouldn’t be modified by an installation process for normal use by normal users. But it’s still useful for development or testing, and for working around problems that can’t be worked around otherwise. If you don’t want to set the LD_LIBRARY_PATH environment variable, on Linux you can even invoke the program loader directly and pass it arguments. Or use --library-path instead of it:

chenwx@chenwx ~/helloworld $ cc -o testhelloworld testhelloworld.c -Wl,--library-path=/home/chenwx/lib -lhelloworld
chenwx@chenwx ~/helloworld $ ll testhelloworld
-rwxrwxr-x 1 chenwx chenwx 8.5K Dec 30 22:26 testhelloworld

If you’re using bash, you could invoke testhelloworld this way using:

chenwx@chenwx ~/helloworld $ LD_LIBRARY_PATH=/home/chenwx/lib:$LD_LIBRARY_PATH ./testhelloworld
Hello World!
Hello World! Alex

Configure the Dynamic Loader

By default, the dynamic loader /lib/ld-linux.so.2 searches through /lib and /usr/lib for dynamic libraries that are needed by programs as they are run. However, if there are libraries in directories other than /lib and /usr/lib, these need to be added to the /etc/ld.so.conf file in order for the dynamic loader to find them. Two directories that are commonly known to contain additional libraries are /usr/local/lib and /opt/lib, so add those directories to the dynamic loader’s search path.

Here is the configuration of /etc/ld.so.conf in my computer:

chenwx@chenwx ~ $ ll /etc/ld.so.conf
-rw-r--r-- 1 root root 34 Jun 24  2014 /etc/ld.so.conf

chenwx@chenwx ~ $ cat /etc/ld.so.conf   
include /etc/ld.so.conf.d/*.conf

chenwx@chenwx ~ $ ll /etc/ld.so.conf.d/*.conf  
-rw-rw-r-- 1 root root  38 Mar 24  2014 /etc/ld.so.conf.d/fakeroot-x86_64-linux-gnu.conf
lrwxrwxrwx 1 root root  40 Oct 24  2014 /etc/ld.so.conf.d/i386-linux-gnu_GL.conf -> /etc/alternatives/i386-linux-gnu_gl_conf
-rw-r--r-- 1 root root 108 Apr 12  2014 /etc/ld.so.conf.d/i686-linux-gnu.conf
-rw-r--r-- 1 root root  44 Aug 10  2009 /etc/ld.so.conf.d/libc.conf
-rw-r--r-- 1 root root  68 Apr 12  2014 /etc/ld.so.conf.d/x86_64-linux-gnu.conf
lrwxrwxrwx 1 root root  43 Oct 24  2014 /etc/ld.so.conf.d/x86_64-linux-gnu_EGL.conf -> /etc/alternatives/x86_64-linux-gnu_egl_conf
lrwxrwxrwx 1 root root  42 Oct 24  2014 /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf -> /etc/alternatives/x86_64-linux-gnu_gl_conf

chenwx@chenwx ~ $ cat /etc/ld.so.conf.d/fakeroot-x86_64-linux-gnu.conf
/usr/lib/x86_64-linux-gnu/libfakeroot

chenwx@chenwx ~ $ cat /etc/ld.so.conf.d/libc.conf
# libc default configuration
/usr/local/lib

chenwx@chenwx ~ $ cat /etc/ld.so.conf.d/i686-linux-gnu.conf
# Multiarch support
/lib/i386-linux-gnu
/usr/lib/i386-linux-gnu
/lib/i686-linux-gnu
/usr/lib/i686-linux-gnu

chenwx@chenwx ~ $ cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

chenwx@chenwx ~ $ cat /etc/alternatives/i386-linux-gnu_gl_conf
/usr/lib/i386-linux-gnu/mesa

chenwx@chenwx ~ $ cat /etc/alternatives/x86_64-linux-gnu_gl_conf
/usr/lib/x86_64-linux-gnu/mesa

chenwx@chenwx ~ $ cat /etc/alternatives/x86_64-linux-gnu_egl_conf
/usr/lib/x86_64-linux-gnu/mesa-egl

Show Shared Library Dependencies

The command ldd prints the shared libraries required by each program or shared library specified on the command line. For instance:

chenwx@chenwx ~ $ ldd /bin/ln
	linux-vdso.so.1 =>  (0x00007ffc51d95000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f686ee19000)
	/lib64/ld-linux-x86-64.so.2 (0x00005606eabc7000)

chenwx@chenwx ~ $ ldd -v /bin/ln
	linux-vdso.so.1 =>  (0x00007ffc68392000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd2a4ea5000)
	/lib64/ld-linux-x86-64.so.2 (0x0000562c348c3000)

	Version information:
	/bin/ln:
		libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
		libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
	/lib/x86_64-linux-gnu/libc.so.6:
		ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
		ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2

or, use a safer alternative when dealing with untrusted executables is:

chenwx@chenwx ~ $ objdump -p /bin/ln | grep NEEDED
  NEEDED               libc.so.6

Use the following command to list the dynamic share libraries:

chenwx@chenwx ~ $ ldconfig -p
1627 libs found in cache `/etc/ld.so.cache'
	libzvbi.so.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libzvbi.so.0
	libzvbi-chains.so.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libzvbi-chains.so.0
	libzip.so.2 (libc6,x86-64) => /usr/lib/libzip.so.2
	libzephyr.so.4 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libzephyr.so.4
	libzeitgeist-2.0.so.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libzeitgeist-2.0.so.0
	libzbar.so.0 (libc6,x86-64) => /usr/lib/libzbar.so.0
	libz.so.1 (libc6,x86-64) => /lib/x86_64-linux-gnu/libz.so.1
...

chenwx@chenwx ~ $ ldconfig -p | grep libc.so
	libc.so.6 (libc6,x86-64, OS ABI: Linux 2.6.24) => /lib/x86_64-linux-gnu/libc.so.6
	libc.so.6 (libc6, OS ABI: Linux 2.6.24) => /lib/i386-linux-gnu/libc.so.6

chenwx@chenwx ~ $ ldconfig -p | grep libstdc++.so
	libstdc++.so.6 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
	libstdc++.so.6 (libc6) => /usr/lib/i386-linux-gnu/libstdc++.so.6
	libstdc++.so.5 (libc6) => /usr/lib/i386-linux-gnu/libstdc++.so.5

References

• ISO/IEC 9899 - Programming languages - C

• C programming language on wiki

• JTC1/SC22/WG21 - The C++ Standards Committee

• C++ programming language on wiki

• GNU C Library Wikipedia
• GNU C Library FTP

• GNU C Library Reporsitory

• 动态库(.so)
• Shared Libraries and naming conventions
• Static, Shared Dynamic and Loadable Linux Libraries
• Computing Library on Wikipedia
• Static Libraries
• Shared Libraries