Installation

Table of Contents

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

Environments

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

• Visual Studio 2015
• Visual Studio 2017
• RedHat 7 (gcc 4.8)
• 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
MSVC 15	X	2.0	3.6, 3.7, 3.8
RHEL 7 gcc 4.8	X	2.0
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

C++

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 library is delivered in static (.lib, .a) and dynamic (.dll, .so).

IOLink is compatible with conan v1.x.

Integration in your project

Add IOLink conan package name into your conanfile.py as requirement. (see conan documentation for more help) In your CMakeLists files, you can now require IOLink in parts of your application by adding the following line:

target_link_libraries(${PROJECT_NAME} CONAN_PKG::IOLink)

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

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 same application. You can find a good explaination of that problem on wiki.

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 2 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 can 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. (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 at compilation can be manually checked by calling Versioning::checkCompatibility() method (in this case, a warning will be raised but won't block the execution).