Linux info about so file

List available functions in a shared library .so file

Recently, we wanted to see if a certain function call was available in a shared library ( .so ).

To do so we used the command nm .
nm lists symbols from object files.

We used the command nm -D /libs/mylib.so.1 .
The parameter -D (or —dynamic ) displays the dynamic symbols rather than the normal symbols. (This is only meaningful for dynamic objects, such as certain types of shared libraries.)

We got a huge list which was similar to this

. 000000000000e6e0 T sudo_SHA512Update 000000000000eb20 T sudo_sig2str 000000000000b970 T sudo_strlcat 000000000000b910 T sudo_strlcpy 0000000000006f60 T sudo_strsplit_v1 00000000000070a0 T sudo_strtobool_v1 0000000000007330 T sudo_strtoid_v1 0000000000007570 T sudo_strtomode_v1 000000000000bb20 T sudo_strtonum 000000000000ac20 T sudo_term_cbreak_v1 000000000000adb0 T sudo_term_copy_v1 000000000021339c B sudo_term_erase 00000000002133a0 B sudo_term_kill 000000000000a920 T sudo_term_noecho_v1 000000000000aa80 T sudo_term_raw_v1 000000000000a860 T sudo_term_restore_v1 00000000000052a0 T sudo_vfatal_nodebug_v1 00000000000052d0 T sudo_vfatalx_nodebug_v1 0000000000005480 T sudo_vwarn_nodebug_v1 00000000000054b0 T sudo_vwarnx_nodebug_v1 00000000000055c0 T sudo_warn_gettext_v1 00000000000052f0 T sudo_warn_nodebug_v1 00000000000055a0 T sudo_warn_set_conversation_v1 .

We filtered out all elements that had the value T or t on the second column as those objects are symbol in the text (code) section and we found the function call we wanted there!

Источник

How can I look inside a Linux .so or .a object and see what functions they contain?

The linker can presumably do this, so is there a command-line tool to list functions in object files and tell me the names of functions and their signatures?

2 Answers 2

For a shared library, you have to use:

Without the -D , nm dumps debug symbols; -D refers to the dynamic symbols that are actually used for dynamic linking. From Ubuntu 12 session:

$ nm /lib/i386-linux-gnu/libc.so.6 nm: /lib/i386-linux-gnu/libc.so.6: no symbols $ nm -D /lib/i386-linux-gnu/libc.so.6 | tail 0011fc20 T xdr_wrapstring 001202c0 T xdrmem_create 00115540 T xdrrec_create 001157f0 T xdrrec_endofrecord 00115740 T xdrrec_eof 00115690 T xdrrec_skiprecord 00120980 T xdrstdio_create 00120c70 T xencrypt 0011d330 T xprt_register 0011d450 T xprt_unregister 

On this system libc.so is stripped of debug symbols, so nm shows nothing; but of course there are symbols for the dynamic linking mechanism revealed by nm -D .

For a .a archive or .o object file, just nm . The symbols are the symbols; if these files are stripped, these objects cannot be used for linking.

Exported sumbols are indicated by a T . Required symbols that must be loaded from other shared objects have a U . Note that the symbol table does not include just functions, but exported variables as well.

Or if you only want to see exported symbols, add the —defined-only flag. eg: nm -D —defined-only /lib/libtest.so

Источник

How to see the object file contents of a .so file

You can’t know, given just a shared library, what object files were compiled into it. If you’re lucky, you may be able to make a reasonable guess.

A shared library is made, by the linker, from object files and possibly other shared libraries, but it does not contain the object files or shared libraries from which it was made. A static library, on the other hand, which is made by the archiver ar , does contain object files: it is just an ar archive of object files.

If a shared library has not been stripped of debugging information, then for debugging purposes its symbol table will contain the names of the source files from which the object files were compiled that were linked in the shared library — at least those source files which were compiled with debugging information. From the names of those source files you can infer the names of the object files with reasonable confidence, but not with certainty.

For example, here we make a shared library from source files foo.c and bar.c .

Compile the source files to object files:

$ gcc -Wall -fPIC -c -o foo.o foo.c $ gcc -Wall -fPIC -c -o bar.o bar.c 

Link the object files to make a shared library:

$ gcc -shared -o libfoobar.so foo.o bar.o 

$ readelf -s libfoobar.so | grep FILE 26: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c 35: 0000000000000000 0 FILE LOCAL DEFAULT ABS foo.c 37: 0000000000000000 0 FILE LOCAL DEFAULT ABS bar.c 39: 0000000000000000 0 FILE LOCAL DEFAULT ABS crtstuff.c 42: 0000000000000000 0 FILE LOCAL DEFAULT ABS 

indicates that three source files have contributed debugging info to the library, and we’d infer that the object files to which they were compiled were likely to be:

Note that crtstuff.c is not one of the source files that we compiled. It happens to contain program initialization and finalization code from the C runtime library, which has got into our library from a C runtime object file that is linked by default.

This inference could be wrong about any of the files, since:

$ gcc -Wall -fPIC -c -o abc.o foo.c $ gcc -Wall -fPIC -c -o xyz.o bar.c $ gcc -shared -o libfoobar.so abc.o xyz.o 

is also a perfectly possible way of compiling and linking the library.

If debugging information has been stripped from the library:

$ readelf -s libfoobar.so | grep FILE $ 

Источник

Linux — Shared Library (so, sl)

As Shared Library, so files are open file opened by a process.

The shared library extension is operating system dependent:

Articles Related

Management

Search Path

When an executable is looking for a dynamic library (.so file), the linker searches in order:

/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin 

PATH

Dynamically linked libraries are typically placed in directories.

The usual directories include:

Path	Description
/lib
/usr/lib	Standard system libraries
/gnu/lib	Gnu libraries
/lib/security	PAM modules
/usr/X11R6/lib or /usr/openwin/lib	X-windows
/usr/local/lib	3rd party libraries

On GNU glibc-based systems, including all Linux systems, the list of directories automatically searched during program start-up is stored in the file /etc/ld.so.conf.

To control this process, you can use the LD_PATH environment variable (for instance: LD_LIBRARY_PATH for Linux/Solaris)

Content (Unpack)

Version

Soname

The version info in not explicitly stored . The full version is usually stored as a part of the library file name.

The soname contains the name of the library which includes the major version. If there was an API change, the library creator is supposed to change the soname . Multiple libraries can then be on a single system.

readelf -d /path/to/library.so | grep SONAME 

File

The version is just to be found in the symbolic link.

libc below is the version 2.5

/lib64/libc.so.6: symbolic link to `libc-2.5.so' 

File Attribute (Symlink or file info)

# if it's a symlink libodbc.so: symbolic link to `libodbc.so.2.0.0' # if it's file libodbc.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped 

Load Test

Dependency

ldd ../product/fmw/Oracle_BI1/bifoundation/odbc/lib/libodbc.so 

ldd: warning: you do not have execution permission for `../product/fmw/Oracle_BI1/bifoundation/odbc/lib/libodbc.so' linux-vdso.so.1 => (0x00007fff375c4000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7bc07ba000) librt.so.1 => /lib64/librt.so.1 (0x00007f7bc05b0000) libodbcinst.so => /u01/app/oracle/product/fmw/Oracle_BI1/bifoundation/odbc/lib/libodbcinst.so (0x00007f7bc03ca000) libSEicu23.so => /u01/app/oracle/product/fmw/Oracle_BI1/bifoundation/odbc/lib/libSEicu23.so (0x00007f7bbf7b9000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f7bbf5b4000) libstdc++.so.5 => /usr/lib64/libstdc++.so.5 (0x00007f7bbf2d9000) libm.so.6 => /lib64/libm.so.6 (0x00007f7bbf056000) libc.so.6 => /lib64/libc.so.6 (0x00007f7bbecfd000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f7bbeaef000) /lib64/ld-linux-x86-64.so.2 (0x00000035bb600000) 

List Shared Library used by processes

lsof -p $(pgrep nqsserver) | awk '' | grep .so$ 

Find a shared library

sudo find / | grep whatever.so 

sudo find / | grep libodbc.so 

/tmp/infa_rpm/Domain/ce908432ad08b4beffd072ef5344365b/infa_rpm.tar/ODBC7.1/lib/libodbc.so /tmp/unixODBC-2.3.6/DriverManager/.libs/libodbc.so.2.0.0 /tmp/unixODBC-2.3.6/DriverManager/.libs/libodbc.so.2 /tmp/unixODBC-2.3.6/DriverManager/.libs/libodbc.so /usr/local/lib/libodbc.so.2.0.0 /usr/local/lib/libodbc.so.2 /usr/local/lib/libodbc.so 

Creation

Example with Sqlite and an amalgam adapted from the Ref documentation

gcc \ -Wl,-soname,libsqlite3.so.0 \ -DDISABLE_DIRSYNC \ -DENABLE_COLUMN_METADATA \ -DENABLE_FTS3 \ -DENABLE_RTREE \ -DENABLE_JSON1 \ -DENABLE_UNLOCK_NOTIFY \ -DSECURE_DELETE \ -DTEMP_STORE=1 \ -DTHREADSAFE=1 \ -shared \ -o libsqlite3.so \ -fPIC \ sqlite3.c 

Documentation / Reference

LD_LIBRARY_PATH is a environment variable that lists directory where executable can search for linux shared library. It’s also called the shared library search path. The value of the environment variable.

odbcinst.ini has all driver information configuration. See Configuration file containing all the database drivers specifications. odbcinst.ini Run: Normally: /etc/odbcinst.ini In the.

Shared libraries are libraries that are linked dynamically. Shared libraries allow common OS code to be bundled into a wrapper and used by any application software on the system without loading multiple.

An object file is an specific operating system format that packages an object code with related metadata to create: executable files (native image) or libraries (shared or static) There is several.

The Executable and Linkable Format (ELF, formerly named Extensible Linking Format), is a object file format (executable files and shared libraries) used also for core dumps. The format of an ELF.

Источник

How do I list the symbols in a .so file

How do I list the symbols being exported from a .so file? If possible, I’d also like to know their source (e.g. if they are pulled in from a static library). I’m using gcc 4.0.2, if that makes a difference.

The platform makes a difference. Apple provides a GCC 4.0, but its nm does not respond to some options, like -D and -g (IIRC).

11 Answers 11

The standard tool for listing symbols is nm , you can use it simply like this:

If you want to see symbols of a C++ library, add the «-C» option which demangle the symbols (it’s far more readable demangled).

If your .so file is in elf format, you have two options:

Either objdump ( -C is also useful for demangling C++):

$ objdump -TC libz.so libz.so: file format elf64-x86-64 DYNAMIC SYMBOL TABLE: 0000000000002010 l d .init 0000000000000000 .init 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 free 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 __errno_location 0000000000000000 w D *UND* 0000000000000000 _ITM_deregisterTMCloneTable 

$ readelf -Ws libz.so Symbol table '.dynsym' contains 112 entries: Num: Value Size Type Bind Vis Ndx Name 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND 1: 0000000000002010 0 SECTION LOCAL DEFAULT 10 2: 0000000000000000 0 FUNC GLOBAL DEFAULT UND free@GLIBC_2.2.5 (14) 3: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __errno_location@GLIBC_2.2.5 (14) 4: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_deregisterTMCloneTable 

Источник