Chilkat for Lazarus / Free Pascal

an object-oriented Pascal API for Lazarus and Free Pascal (FPC)

Windows 32-bit, 64-bit, and Arm64 · Linux x86_64, x86, arm (armv7l), and arm64 · macOS universal (Intel and Apple Silicon). The units also compile in Delphi XE2+ on Windows.

Chilkat for Lazarus is a true object-Pascal API: each Chilkat class is a real Pascal class (TCrypt2, THttp, TZip, …) with native string properties and methods — no handles, no PWideChar, no manual dispose calls. The classes are thin wrappers over the Chilkat C bridge shared library, which CkDllLoader.pas loads dynamically at runtime — there is no link-time dependency, nothing is installed on your machine, and nothing is registered. All units are namespaced (Chilkat.Crypt2, Chilkat.Http, …), so their names can never collide with other libraries in your project.

Download

This is the full-version Chilkat product. Chilkat libraries are fully functional for a 30-day evaluation; no separate trial build is required. One download covers Windows, Linux, and macOS — the same units compile unchanged on every platform, and the matching shared library for each platform is included.

Documentation & Samples

• 📖 Chilkat Pascal Reference Documentation
• 💻 Chilkat Pascal (Lazarus/Delphi) Sample Code — ready-to-run examples
• 📝 Release Notes on the Chilkat blog

What's in the download

Unzipping creates a chilkat-lazarus directory. The paths on this page assume C:\chilkat-lazarus on Windows.

Using Chilkat in your own project

1. Tell the compiler where the units are. In Lazarus, select Project → Project Options → Compiler Options → Paths and add C:\chilkat-lazarus to Other unit files (-Fu). (Building with plain FPC from the command line, that's -Fu C:\chilkat-lazarus.) You do not add the .pas files to the project; the compiler finds them from the unit path.
2. Add the Chilkat units you need to the uses clause. Each class lives in the unit of the same name, prefixed with Chilkat.:

   uses
     SysUtils, Chilkat.Global, Chilkat.Crypt2;

   Chilkat.Global is where the unlock call lives; you'll almost always use it.
3. Put the Chilkat library where the loader can find it. The simplest reliable choice on every platform is the same directory as your executable — the loader checks there automatically. On 64-bit Windows, copy chilkat_c_bridge_x64.dll next to your EXE (for a Lazarus project that is usually the project folder itself, or wherever Target file name (-o) points).
4. Write some code. Here is a complete console program: it unlocks Chilkat, AES-encrypts a string, and decrypts it again. The same calls work unchanged in a LCL GUI application — and on Linux and macOS.

   program QuickStart;
   
   {$mode delphi}
   
   uses
     SysUtils, Chilkat.Global, Chilkat.Crypt2;
   
   var
     glob: TGlobal;
     crypt: TCrypt2;
     encStr, decStr: string;
   
   begin
     // Unlock Chilkat once at application startup.
     // Any string unlocks a fully-functional 30-day trial.
     glob := TGlobal.Create;
     crypt := TCrypt2.Create;
     try
       if not glob.UnlockBundle('Anything for 30-day trial') then
       begin
         WriteLn(glob.LastErrorText);
         Exit;
       end;
   
       // AES-256 in CBC mode, hex-encoded output.
       crypt.CryptAlgorithm := 'aes';
       crypt.CipherMode := 'cbc';
       crypt.KeyLength := 256;
       crypt.PaddingScheme := 0;
       crypt.EncodingMode := 'hex';
       crypt.SetEncodedIV('000102030405060708090A0B0C0D0E0F', 'hex');
       crypt.SetEncodedKey('000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F', 'hex');
   
       encStr := crypt.EncryptStringENC('The quick brown fox jumps over the lazy dog.');
       WriteLn('Encrypted: ' + encStr);
   
       decStr := crypt.DecryptStringENC(encStr);
       WriteLn('Decrypted: ' + decStr);
     finally
       crypt.Free;
       glob.Free;
     end;
   end.

5. Press F9. The encrypted hex string and the decrypted text appear in the console.

How the library is loaded

Nothing is linked at build time. The first time your program calls into Chilkat, CkDllLoader.pas loads the shared library whose name matches the target platform — the name is chosen at compile time from the target OS and CPU:

The loader tries, in order: a copy already loaded in the process (Windows), the operating system's standard library search (PATH / LD_LIBRARY_PATH / DYLD_LIBRARY_PATH and system directories), and finally the directory containing your executable. That last fallback is why simply shipping the library beside your program works on every platform with no environment setup.

To load from a specific location instead, call SetChilkatDllPath (from CkDllLoader) with the full path before creating any Chilkat object:

SetChilkatDllPath(ExtractFilePath(ParamStr(0)) + 'libchilkat_c_bridge.dylib');

Platform notes

Windows

Copy the DLL matching your target (chilkat_c_bridge_win32.dll, chilkat_c_bridge_x64.dll, or chilkat_c_bridge_arm64.dll) into the directory containing your EXE. Nothing is registered and no installer is needed.

Windows on Arm: the aarch64-win64 FPC/Lazarus target loads the native chilkat_c_bridge_arm64.dll. If you instead compile these units with Delphi's Windows on Arm target (Delphi 13.1+), no action is needed: Delphi WoA produces Arm64EC code, which loads the x64 DLL through Windows' EC interop, and the units select chilkat_c_bridge_x64.dll there automatically.

Linux

Four architectures are provided: x86_64, 32-bit x86, 32-bit hard-float arm (armv7l — e.g. Raspberry Pi OS 32-bit), and arm64. The libraries require glibc 2.27 or newer — in practice, any Linux distribution released around mid-2018 or later (Ubuntu 18.04+, Debian 10+, RHEL/CentOS 8+, Fedora 28+, and equivalents). To check a system, run ldd --version; the first line reports the glibc version.

The easiest deployment is to ship the matching .so in the same directory as your executable — the loader finds it there with no LD_LIBRARY_PATH or ldconfig setup. A system-wide install works too:

sudo cp libchilkat_c_bridge_x86_64.so /usr/local/lib/
sudo ldconfig

macOS (Intel and Apple Silicon)

One file covers both CPUs: libchilkat_c_bridge.dylib is a universal (fat) binary, and macOS loads the right slice automatically — your Pascal code needs no architecture {$IFDEF}. The dylib is signed with Chilkat's Developer ID, so it passes Gatekeeper and can be included in a notarized application.

Place the dylib in the same directory as your executable — for a .app bundle that is MyApp.app/Contents/MacOS/ — and the loader finds it with no extra setup. To use the bundle-canonical Contents/Frameworks/ location instead, point the loader at it explicitly:

{$IFDEF DARWIN}
SetChilkatDllPath('@executable_path/../Frameworks/libchilkat_c_bridge.dylib');
{$ENDIF}

Deploying your application

The Chilkat shared library is the only runtime dependency: nothing needs to be installed or registered on the target machine.

Using Embarcadero Delphi?

These units also compile in Delphi XE2 and later on Windows. However, Delphi developers may prefer the dedicated Chilkat Delphi DLL download, which additionally covers Delphi's Linux, macOS, iOS, and Android targets.

Next Steps

Browse the Pascal examples for working code covering HTTP/REST, JSON, XML, email (SMTP/POP3/IMAP), FTP, SFTP/SSH, Zip, PDF, digital signatures, encryption, and much more. For questions, see the reference documentation or contact Chilkat support.