potential compatibility issues due to different features

[milyin]

Describe the feature

The zenoh-c could be compiled with different features enabled (unstable, shared-memory). But this is not reflected in .so naming. So it's possible that application built on system where zenoh-c with shm support is intalled will crash on system with zenoh-c of the same verison withou shm.

It's necessary to be able to differentiate zenoh by features and even be able to install different variations on the same system in parallel (i.e. different .a, .so, .h for different feeatures and versions)

First step is to make investigations how other libraries solves this problem. What are the good practices of having multiple parallel versions / variations of the library on the same system?

[sanri]

It is recommended that all data, memory allocation and deallocation of zenoh-c be implemented by zenoh-c functions. Only Pointers are kept externally. zenoh-c provides functions for reading and writing data of opaque types.

For example:

typedef struct ALIGN(8) z_owned_config_t {
  uint8_t _0[1984];
} z_owned_config_t;

Instead of exposing the size information for an external function to request memory, we just need to provide a function to request memory and initialize the object.

void* z_new_owned_config_t();
void z_free_owned_config_t(void* p);

[sanri]

The ability to export different library functions for different compilation parameters is handled well by the runtime dynamic loading of the binding library. When the binding library loads the dynamic library, it knows which functions are provided and which are not.

[milyin]

The current approach was selected to avoid extra dynamic allocations affecting performance. Each structure is allocated on stack, user himself may allocate it in the heap if necessary. The downside of this approach is the necessity to know the sizes of the strucrtures, the dynamic library interface by itself doesn't provide this information.