IOLink 1.11.0
Loading...
Searching...
No Matches
Installation

Environments

IOLink is natively (C++) available for following compilers:

  • Visual Studio 2017
  • Visual Studio 2019
  • Visual Studio 2022
  • Ubuntu 20.04 (gcc 9.x)
  • Ubuntu 22.04 (gcc 11.x)
  • CentOS 8 (gcc 8.x)

The .NET wrapping of IOLink is compiled for .NET Standard 2.0 and it should be compatible with all implementations of .NET that support this standard.

Packages are currently tested for:

  • .NET Framework 4.6.1
  • .NET Core 3.1
  • .NET 6

There is a Python wrapping too, using the Python stable ABI to make the package compatible with versions 3.8.10 and after. Currently, IOlink Python is tested for all python versions between 3.8.10 and 3.12.

Here is an array which gives all compatibility for handled languages:

Compilers C++ .NET Standard Python
MSVC 15 X 2.0 3.8.10 - 3.12
MSVC 16 X 2.0 3.8.10 - 3.12
MSVC 17 X 2.0 3.8.10 - 3.12
Ubuntu 20.04 gcc 9 X 2.0 3.8.10 - 3.12
Ubuntu 22.04 gcc 11 X 2.0 3.10 - 3.12
Ubuntu 24.04 gcc 13 X 2.0 3.12
CentOS 8 gcc 8 X

Installation

IOLink is delivered as a Conan package. Conan packages are named as follow:

IOlink/x.y.z@builsystem/<preview|stable>

preview versions can be released between two stable deliveries.

IOlink Conan packages provides dynamic libraries, dll and so, and these must be imported in all dependent projects. IOLink is compatible with Conan 1.X

Integration in your project

Add the IOLink Conan package into your conanfile.py as a requirement. You can refer to the Conan documentation for more details on conanfiles. In your CMakeLists files, you can now add IOLink as a dependency by using the following syntax:

target_link_libraries(${PROJECT_NAME} CONAN_PKG::IOLink)

You have now access to IOLink headers and can start using it.

DLL sharing issue

As a reminder, there is an issue on Windows platforms concerning the management of DLLs from a library shared by many components of a unique application. You can find a good explanation of that problem on wikipedia.

IOLink purpose is to ease inter-operability between software components, and thus, can theorically be loaded by many components. The problem occurs when these components don't load the same version of IOLink. IOLink guarantees the binary-compatibility between two major versions. But some APIs can be added between two minor versions of IOLink, in the same major version. And if the component using the newest version of IOLink call one of these new APIs with the oldest version of the DLL, it will usually crash.

Thus, in a same software, if two components dynamically load two different versions of IOLink, there can be a issue even if these two versions are binary-compatible.

A solution is to always load the newest version of the library. By doing so, only one version of the DLL will be loaded and shared between all components.

IOLink provides some basic mechanisms which will help you to identify this issue:

  • current loaded version can be displayed at runtime
  • compatibility between current loaded version and version used in headers can be manually checked by calling the a Versioning method. In this case, a warning will be raised but won't block the execution.