Installation

Table of Contents

• Environments
• Installation
• Integration in your project
• DLL sharing issue

Environments

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

• Visual Studio 2015
• Visual Studio 2017
• RedHat 8 (gcc 8.3)
• Ubuntu 18.04 (gcc 7.x)
• Ubuntu 20.04 (gcc 9.x)

The .NET wrapping of IOLink is compiled for .NET Standard 2.0, so it should support all .NET implementations that support that version. Packages are currently tested for .NET core 2.1 and .NET Framework 4.6.1; but should work with other compatible versions as well.

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

Compilers	C++	.NET Standard	Python
MSVC 14	X		3.6, 3.7, 3.8, 3.9, 3.10
MSVC 15	X	2.0	3.6, 3.7, 3.8, 3.9, 3.10
RHEL 8 gcc 8.3	X	2.0
Ubuntu 18.04 gcc 7.3	X	2.0	3.6
Ubuntu 20.04 gcc 9	X	2.0	3.8

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.