│English (en) │

But when I ran nm -g libMylib.so nothing happened - at all. When I ran objdump -TC libMylib.so I got: objdump: command not found. Then I saw the arm-linux-androideabi-nm and arm-linux-androideabi-objdump files (listed as 'Unix Executable File' in Finder) in the darwin-x8664/bin dir. The attempt to use both of them resulted in 'command not found'. In computing, the Executable and Linkable Format (ELF, formerly named Extensible Linking Format), is a common standard file format for executable files, object code, shared libraries, and core dumps.First published in the specification for the application binary interface (ABI) of the Unix operating system version named System V Release 4 (SVR4), and later in the Tool Interface Standard, it.

This article applies to macOS only.

See also: Multiplatform Programming Guide

Overview

Note:Dynamic libraries are also known as dynamic shared libraries, shared objects, or dynamically linked libraries.
Static libraries are also known as static archive libraries and static linked shared libraries.

Most of an application's functionality is implemented in libraries of executable code. When an application's source code is compiled into object code and linked with a static library, the object code and library code that the application uses is copied into the executable file that is loaded into memory in its entirety at launch time. The kind of library that becomes part of an application's executable is known as a static library. Static libraries are collections or archives of object files.

There are two important factors which determine the performance of applications: their launch times and their memory footprints. Reducing the size of an executable file and minimizing its memory use once launched make an application launch faster and use less memory. Using dynamic libraries instead of static libraries reduces the executable file size of an application. Dynamic libraries also allow applications to delay loading libraries with special functionality until they’re needed instead of loading them at launch time. This feature contributes further to reduced launch times and efficient memory use. Another reason to use dynamic libraries is so that you can share code among multiple applications thereby saving the memory (and to a lesser extent nowadays, disk space) that would otherwise be used for multiple copies of the library code.

There are, however, some advantages to statically linking libraries with an executable instead of dynamically linking them. The most significant advantage is that the application can be certain that all its libraries are present and that they are the correct version. Static linking of libraries also allows the application to be contained in a single executable file, simplifying distribution and installation. Also with static linking, only those parts of the library that are directly and indirectly referenced by the target executable are included in the executable. With dynamic libraries, the entire library is loaded, as it is not known in advance which functions will be used by the application. Whether this advantage is significant in practice depends on the structure of the library.

Library extensions and prefixes

The library prefix column indicates how the names of the libraries are resolved and created. Under macOS, the library name will always have the lib prefix when it is created. So if you create a dynamic library called test, this will result in the file libtest.dynlib. When importing routines from shared libraries, it is not necessary to give the library prefix or the filename extension.

Example FPC static library

Tip: If you use 'cdecl', FPC ensures that your function completely adheres to all ABI requirements (naming, parameter passing, etc). If you don't, then you are on your own.

test.pas:

Compile:

which produces an object file named test.o which we will now convert into a static library archive named libtest.a using the libtool command line utility:

Example FPC application to use FPC static library

Objdump For Mac Os High Sierra

statlibdemo.pas:

Compile:

which unexpectedly produces:

What happened? Why wasn't our library function cvtString found? Let's look for our function in the test.o object file by running the objdump command line utility:

Aha! Our function name has been well and truly mangled. It is obvious we need to use the mangled name TEST_$$_CVTSTRING$ANSISTRING$$PCHAR (omit the underscore as the linker will automatically add it) rather than the unmangled cvtString. Our example application now looks like:

Compile:

which again dashes our hopes and produces:

Unfortunately we are missing the object file for the UpperCase function which was pulled in from the FPC SysUtils unit. What to do? Simply add the SysUtils unit to the the Uses clause of the application. Our example application now looks like:

Third time lucky, compile:

Run:

Example C static library

myfunc1.c

myfunc2.c

Compile:

Note: If you do not specify the minimum macOS version, the C compiler will compile for your current operating system version, but your Free Pascal Compiler will compile for 10.5 (fpc 3.0.4) or 10.8 (fpc 3.3.1) by default.

which produces object files named myfunc1.o and myfunc2.o which we will now convert into a static library archive named libmyfuncs.a using the libtool command line utility:

Example FPC application to use C static library

statlibdemo.pas:

Compile:

Run:

If you need to check whether your external routines have been linked into the final application, you can use the objdump command line utility:

If you don't care for the assembly language, you can also use the nm command line utility:

See also

Objdump For Mac Os 10.13

• macOS Dynamic Libraries for the same FPC library being used as a dynamic library.

Objdump For Mac Os 10.10

• macOS Libraries.

Objdump For Mac Os Versions