Skip to content

0.1.2: shared libraries at run time (mcpplibs.os.library) - #5

Merged
Sunrisepeak merged 2 commits into
mainfrom
library
Oct 27, 2026
Merged

Sunrisepeak merged 2 commits into
mainfrom
library

Conversation

@Sunrisepeak

Copy link
Copy Markdown
Member

Adds mcpplibs.os.library, the dynamic loader. Two cases need it:

  • a plugin system that loads a module by name;
  • an extension that another program loads, and that needs that program's functions without linking against them. openmui's Python binding is one: it reaches the interpreter's stable C API this way, on every platform, without CPython headers or an import library.

openkal does not cover the loader: it is the C library's on Linux and macOS and kernel32's on Windows. So the implementations are per system, beside machine. The README says so.

API:

  • open(path or name) returns a handle that closes the library when it goes. The library's symbols stay local to it (RTLD_LOCAL).
  • loaded(name) finds a library already in the process, without loading it.
  • A handle's symbol and function<F> look up what the library defines.
  • process_symbol(name) resolves a symbol as the loader does: the global scope on POSIX, every module of the process in load order on Windows.
  • suffix() is the system's library suffix.

Tests (tests/library_test.cpp):

  • a system library (libc / libSystem / kernel32) opens by name, and one of its functions is called;
  • a loaded library is found without loading it;
  • a program symbol resolves;
  • a missing library is an error;
  • a handle can be moved.

Checked locally with LLVM on Linux. This CI is the first macOS, Windows (LLVM and MSVC) and GCC run. Version 0.1.2.

A plugin system loads a module by name, and an extension that another
program loads needs that program's functions, which it did not link
against (a Python extension and the interpreter's C API). Both need the
dynamic loader, which openkal does not cover: it belongs to the C
library on Linux and macOS and to kernel32 on Windows.

The new module mcpplibs.os.library:
- open(path or name) answers a handle that closes the library when it
  goes; the library's symbols stay local to it;
- loaded(name) finds a library the process already has, without loading
  it;
- handle::symbol and function<F> look up what a library defines;
- process_symbol(name) resolves a symbol as the loader does: the global
  scope on POSIX, every module of the process on Windows;
- suffix() is the system's library suffix.

The implementations are src/posix/library.cpp (dlopen),
src/windows/library.cpp (kernel32, declared in win32.h) and
src/openkal/library.cpp (an image loads nothing). library_test opens a
system library by name, calls one of its functions, finds a loaded
library and a program symbol, and gets an error for a missing library.
@Sunrisepeak
Sunrisepeak merged commit d8d4304 into main Oct 27, 2026
12 checks passed
@Sunrisepeak
Sunrisepeak deleted the library branch October 27, 2026 06:14
Sunrisepeak added a commit to mcpplibs/mcpp-index that referenced this pull request Oct 27, 2026
…#584)

mcpplibs/os#5 adds the dynamic loader: open a library by path or name,
find one the process already has, look up its symbols, and resolve a
symbol of the program as the loader does. openmui's Python binding
reaches the interpreter's stable C API this way, without headers or an
import library. The consumer test moves to 0.1.2 and resolves a program
symbol.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant