Difference between revisions of "macOS Dynamic Libraries"

From Free Pascal wiki
Jump to navigationJump to search
Line 144: Line 144:
 
If you turn test.pas above into a Lazarus project named project1 and create an [[Application_Bundle|application bundle]] then you need to:
 
If you turn test.pas above into a Lazarus project named project1 and create an [[Application_Bundle|application bundle]] then you need to:
  
* Delete the project1.app/Contents/MacOS/project1 symbolic link to the executable file
+
* Open a Terminal (Applications > Utilities > Terminal)
* Copy the project1 executable file into the project1.app/Contents/MacOS directory
+
* Delete the <tt>project1.app/Contents/MacOS/project1</tt> symbolic link to the project1 executable file
* Copy libtest.dylib into the project1.app/Contents/Frameworks directory (you need to create the Frameworks directory)
+
* Copy the project1 executable file into the <tt>project1.app/Contents/MacOS</tt> directory
* Change into the project1.app/Contents/MacOS directory
+
* Copy libtest.dylib into the <tt>project1.app/Contents/Frameworks</tt> directory (you need to create the Frameworks directory)
* Enter: ''install_name_tool -add_rpath "@executable_path/../Frameworks/." project1''
+
* Change into the <tt>project1.app/Contents/MacOS</tt> directory
 +
* Enter: <syntaxhighlight lang=text inline>install_name_tool -add_rpath "@executable_path/../Frameworks/." project1</syntaxhighlight>
  
 
This ensures that the project1 executable in your application bundle will look in the Frameworks directory to find your dynamic library.
 
This ensures that the project1 executable in your application bundle will look in the Frameworks directory to find your dynamic library.
  
For more information on the install_name_tool utility, open a Terminal and enter:  
+
For more information on the install_name_tool command line utility, open a Terminal and enter:  
 
   man install_name_tool
 
   man install_name_tool
  

Revision as of 02:27, 13 May 2020

Overview

Note-icon.png

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

Operating System Dynamic library Static library Library prefix
FreeBSD .so .a lib
macOS .dylib .a lib
Linux .so .a lib
Windows .dll .lib n/a

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.dylib. When importing routines from shared libraries, it is not necessary to give the library prefix or the filename extension.

Example dynamic library

test.pas:

library TestLibrary;
  
{$mode objfpc} {$H+}

uses
  // needed for UpperCase
  SysUtils;     

// library subroutine
function cvtString(strIn : string) : PChar; cdecl;
  begin
    cvtString := PChar(UpperCase(strIn));
  end;

// exported subroutine(s)
exports
  cvtString;
end.

Compile:

 fpc test.pas

which produces the dynamic library file named libtest.dylib.

Example application to load dynamic library

This version of the example application loads the dynamic library on demand when necessary (load-time dynamic linking aka dynamic loading) and can also unload it when it is no longer necessary. You can successfully compile the application even if the dynamic library does not exist.

The alternative example version that follows loads the dynamic library at start-up (run-time dynamic linking aka dynamic linking) and cannot unload it until the application quits. You cannot successfully compile the application unless the dynamic library exists.

dynlibdemo.pas:

Program dynlibdemo;
  
{$mode objfpc}{$H+}

uses
   Dynlibs,
   SysUtils;

type
   // definition of the subroutine to be called as defined in the dynamic library to be loaded
   TcvtString = function(strToConvert : string) : PChar;  cdecl;

var
   // create suitable variable for the dynamic library subroutine
   cvtString : TcvtString;

   // create a handle for the dynamic library
   LibHandle : TLibHandle;

begin
   // load and get the dynamic library handle
   LibHandle := LoadLibrary(PChar('libtest.dylib'));

   // check whether loading was successful
   if LibHandle <> 0 then
     begin
       // assign address of the subroutine call to the variable cvtString
       Pointer(cvtString) := GetProcAddress(LibHandle, 'cvtString');

       // check whether a valid address has been returned
       if @cvtString <> nil then
         WriteLn(cvtString('hello world'))
       // error message on no valid address
       else
         WriteLn('GetLastOSError1 = ', SysErrorMessage(GetLastOSError));
     end
   else
     // error message on load failure
     WriteLn('GetLastOSError2 = ', SysErrorMessage(GetLastOSError));

   // release memory
   cvtString := nil;
   FreeLibrary(LibHandle);
end.

Compile:

 fpc dynlibdemo.pas

Run:

$ ./dynlibdemo
HELLO WORLD

Alternative example application to load dynamic library

This version of the example application loads the dynamic library at startup (run-time dynamic linking aka dynamic linking) and cannot unload it. You cannot successfully compile the application unless the dynamic library exists.

The previous version of the example application loads the dynamic library when necessary (load-time dynamic linking aka dynamic loading) and can also unload it when it is no longer necessary. You can successfully compile the application even if the dynamic library does not exist.

dynlibdemo.pas:

{$linklib libtest}    

program dynlibdemo;

{$mode objfpc} {$H+}

function cvtString(const strToConvert: string): PChar; cdecl; external;
begin
  WriteLn(cvtString('hello world'));
end.

Compile:

 fpc dynlibdemo.pas

Run:

$ ./dynlibdemo
HELLO WORLD

If you think the code looks like it statically links the library, you can verify that it does not by moving the library or renaming it and then re-running the demo application which produces output similar to this:

$ ./dynlibdemo 
dyld: Library not loaded: /Users/[user]/fpc_dynamic_lib2/libtest.dylib
  Referenced from: /Users/[user]/fpc_dynamic_lib2/./dynlibdemo
  Reason: image not found
Abort

Additional steps using a Lazarus project

If you turn test.pas above into a Lazarus project named project1 and create an application bundle then you need to:

  • Open a Terminal (Applications > Utilities > Terminal)
  • Delete the project1.app/Contents/MacOS/project1 symbolic link to the project1 executable file
  • Copy the project1 executable file into the project1.app/Contents/MacOS directory
  • Copy libtest.dylib into the project1.app/Contents/Frameworks directory (you need to create the Frameworks directory)
  • Change into the project1.app/Contents/MacOS directory
  • Enter: install_name_tool -add_rpath "@executable_path/../Frameworks/." project1

This ensures that the project1 executable in your application bundle will look in the Frameworks directory to find your dynamic library.

For more information on the install_name_tool command line utility, open a Terminal and enter:

 man install_name_tool

Standard locations for dynamic libraries

While in the above example we stored the dynamic library in the application bundle, the standard locations for dynamic libraries are ~/lib (for single user) and /usr/local/lib (for multiple users). There used to also be /usr/lib, but that is now locked-down in macOS 10.15 (Catalina) on the system read-only volume. You need to use the standard locations if you want to share the dynamic library among multiple applications and set the correct path using the command line install_name_tool.

Note: You cannot distribute an application through the Mac App Store that depends on a custom library being installed first by the user into /usr/local/lib.

See also