Skip to main content

About external components (AddIns)

Some tools in the OPI set use external components (AddIns) — Rust dynamic libraries that provide functions hard or impossible to implement with 1C or OneScript alone. You rarely touch AddIns directly when using OPI, but having them introduces practical constraints and quirks. They are summarized here.

Compatibility​

All external components bundled with OPI are built for x64 and x86 (x32) on Windows and Linux. They are shipped in ZIP archives with four native libraries — one per platform. Both platforms have compatibility constraints tied to specific OS versions and system libraries.

Repository storage​

Built ZIP archives and 1C Template.addin layouts are not stored in the main or stable branch history — they live on a separate orphan branch, addins, so the main Git history stays lean.

That branch holds a single current build for ongoing development on main. After cloning main, files at the usual paths (src/ru/OInt/addins/*.zip, src/en/OInt/addins/*.zip, **/CommonTemplates/*/Template.addin) are missing from the working tree. Pull them with:

# Windows
src\addins\sync-addins.bat

# Linux / macOS / CI
bash src/addins/sync-addins.sh

The stable branch contains the last published release codebase. Binaries from addins target main and may not work with stable (BSL wrappers and native API can diverge). When working on stable, build components from src/addins at that branch’s commit (build.bat) or use archives from the matching release.

Windows​

Release builds of AddIns on Windows use a modern MSVC toolchain. The resulting .dll files may reference functions from Windows system libraries (kernel32, bcrypt, ws2_32, and others) that are only available starting with Windows 8 and Windows Server 2012. On older systems — Windows 7 and Windows Server 2008 R2 — components from the standard OPI release may fail to load or crash when such functions are called.

For a self-service build targeting Windows 7 / Server 2008 R2, the repository includes src/addins/legacy-win7 with setup-win7-build-env.bat and build-win7-package.bat. See the directory README.md for details. The build uses nightly Rust with win7-windows-msvc targets and can take noticeably longer than a standard release build. Use the resulting ZIP as an AddIn package, or replace the matching archive from the release for your delivery.

Linux​

On Linux the components assume glibc, gcc* and OpenSSL** are available.

* Applies to CLI and OneScript builds ** Applies to libraries that use TLS

glibc​

glibc is the C runtime that backs system calls and basics like open, malloc, printf, and so on. It is present on x86 Linux distros, but version matters. The minimum supported version for OPI AddIns is 2.18, roughly matching CENTOS 7, RHEL 7, Fedora 19, Debian 8, and Ubuntu 12.04 (2013–2014 era). Older distros will not run libraries that depend on these components.

gcc​

The gcc toolchain version affects which libstdc++.so.6 is on the system; that library is required for the AddIn engine in CLI and OSPX OPI builds. Minimum supported gcc is 7.5.0 (CentOS 8, RHEL 8, Fedora 28, Debian 10, Ubuntu 20.04, or older distros with devtoolset-7 or equivalent).

OpenSSL​

Libraries that implement TLS link against system OpenSSL 3.x — libssl.so.3 and libcrypto.so.3. That version is the default starting with CENTOS 9, RHEL 9, Fedora 36, Debian 12, and Ubuntu 22.04 (2022–2023). On older distros that ship OpenSSL 1.1 or earlier, you must install or build OpenSSL 3.x separately.

Usage hints in the docs​

You can tell that a library uses external components from footnotes on its first documentation page, for example:

Some functions in this library are implemented with an external component
Please read About external components before you start
This library needs OpenSSL 3.x on Linux
Learn more: Using OpenSSL in external components

If there is no such note, the library was implemented without external components.

External components OnClient in the 1C:Enterprise edition​

Methods that rely on external components can run on server or client in the 1C:Enterprise build. On the server, AddIns are loaded transparently. On the client, they require an interactive install on that workstation. The process starts on the first call for each AddIn you use: the platform shows a dialog and may raise an exception telling you to call the same function again after installation.

Besides on-demand installation, you can pre-install selected AddIns on a client using the Control panel (OPI) data processor

warning

При обновлении Открытого пакета интеграций до новой версии, компоненты на клиенте необходимо установить заново через панель управления (пошаговая инструкция присутствует на форме обработки). В противном случае новые функции, реализованные в коде 1С, могут оказаться несовместимы с функциями компонент, которые остались на клиентской машине после предыдущей установки

FAQ​

Miscellaneous questions about how external components work or are built — not specific to day-to-day OPI usage.

1. Can I rebuild the external components?

Yes. The Rust sources live under src/addins. Put the built binaries in a ZIP together with the manifest file. The build.bat script in src/addins places archives in the four working-tree locations and describes the release build flow. To publish the result to the addins branch, use src/addins/publish-addins.bat; to fetch already published binaries after cloning main, use sync-addins.bat / sync-addins.sh (see Repository storage). You can also replace the archive from a release that matches your delivery. For Windows 7 / Server 2008 R2, use the separate legacy-win7 directory — see the Windows section above.

2. Can OpenSSL-dependent components be rebuilt against OpenSSL 1.1 / 1.1.1k?

I was not able to get this working: even with a successful link to libssl.so.1.1, Rust dependencies (notably native-tls) need APIs that are missing or different in OpenSSL 1.1 compared to 3.x. Pinning crates down to the edge of acceptable security did not help. If you know a workable approach, please share it in Issues.

3. Why is OpenSSL linked dynamically instead of statically?

Static linking (embedding OpenSSL inside each .so) causes many problems: clashes when several such libraries share process-wide state (ERR_STATE, /dev/random, etc.), much larger binaries because every component ships its own copy, and no way to upgrade OpenSSL without rebuilding everything. For those reasons we use dynamic linking.

4. Can I see the full dependency list for a given component?

Each component’s source tree contains dependencies.log — the output of ldd and strings | grep GLIBC for the x64 .so after a build. It looks roughly like this:


"MAIN ---" 
	linux-vdso.so.1 (0x00007ffe4cd2e000)
	libssl.so.3 => not found
	libcrypto.so.3 => not found
	libm.so.6 => /lib64/libm.so.6 (0x00007f1ed1fb9000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f1ed1d99000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f1ed19c2000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007f1ed17be000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f1ed2562000)
GLIBC_2.2.5
GLIBC_2.3
GLIBC_2.3.4
GLIBC_2.14
GLIBC_2.17

You can produce the same information yourself by unpacking the platform ZIP and running these or other tools on the .so that matches your OS and bitness.

Technical notes on builds and development​

  • Every component is a Rust cdylib based on the addin1c crate by medigor.
  • Linux binaries are cross-compiled with cargo-zigbuild targeting Oracle Linux 9.1 (via WSL).
  • Profile.release:
	lto = "fat"
	codegen-units = 1
	panic = "unwind"
	strip = true
	opt-level = "z"