Difference between revisions of "Lazarus/FPC Libraries"

From Lazarus wiki
Jump to navigationJump to search
Line 35: Line 35:
 
===Linux===
 
===Linux===
  
To share memory (GetMem/FreeMem, strings) with other libraries (not written in FPC) under Linux you should use the '''cmem unit'''. This unit must be added as the very first unit of the project main source file (typically .lpr).
+
To share memory (GetMem/FreeMem, strings) with other libraries (not written in FPC) under Linux you should use the '''unit cmem'''. This unit must be added as the very first unit of the project main source file (typically .lpr).
  
 
===Windows===
 
===Windows===

Revision as of 17:31, 19 January 2007

This page describes the possibilities how to create libraries with Lazarus/FPC and how to use them in projects and packages.

Related Topics

General

Static linking: FPC compiles and links as default a static executable. That means it tells the linker to put all .o files of the project and all packages into one big executable. Advantage: no external dependencies. Disadvantage: No code is shared between different programs on the same computer. And you can not load/unload a plugin.

Dynamic librariers: The idea of dynamic librariers is to share code between programs, saving the memory of the code, reducing the startup time for often used libraries and allowing plugins. The disadvantages of dynamic libraries are: they are slower for seldom used libs, their structure and internals are more complicated (this is mainly a problem for the compiler), their initialization is different (see below) and sharing code requires a version system to only mix compatible code.

Operating Systems

Dynamic libraries:

Operating System Dynamic library Static library
FreeBSD .so .a
MacOSX .dynlib ?
Linux .so .a
Windows .dll ?

FreeBSD

MacOSX

Linux

To share memory (GetMem/FreeMem, strings) with other libraries (not written in FPC) under Linux you should use the unit cmem. This unit must be added as the very first unit of the project main source file (typically .lpr).

Windows

ppumove, .ppu, .ppl

FPC normally creates for every unit a .ppu and .o file. The .ppu file contains every important information of the .pas/.pp file (types, required filenames like the .o file), while the .o file contains the assembler code and the mangled names understood by the current system.

The ppumove tool included with every FPC installation, converts one or several .ppu and .o files into a dynamic library. It does this by calling the linker to gather all .o files into a .so (windows: .ddl) file and removes the .o filename references from the .ppu file. These new .ppu files are normally called .ppl files.

For example:

You have the output directory of a package (where the .ppu files are):

 ppumove -o packagename -e ppl *.ppu

This will convert all .ppu files into .ppl files and creates a libpackagename.so (windows: packagename.dll). Note that under Linux the prefix 'lib' is always prepended.

This new library can already be used by other programming languages like C. Or by FPC programs by using the external modifiers. But the initialization/finalization sections must be called automatically. This includes the initialization/finalization of the heap manager. This means no strings or GetMem. Of course FPC programmers are spoiled and they can get more.

Initialization

Versions, contributing