# mco_core_load

This function loads eXtremeDB libraries dynamically.

### Prototype

        MCO_RET mco_core_load(	mco_bool disk, mco_bool mvcc, mco_bool shmem,
                    const char *sync_library,
                    const char *memory_library,
                    const char *runtime_path);

### Arguments

disk | A non-zero (`MCO_YES`) value means load disk libraries; a zero value (`MCO_NO`) means load the In-Memory libraries
mvcc | A non-zero value (`MCO_YES`) means load the MVCC transaction manager library; a zero value (`MCO_NO`) means load the MURSIW library
shmem | A non-zero value (`MCO_YES`) means load the Shared Memory library; a zero value (`MCO_NO`) means load the conventional memory library
sync_library | For Unix-Linux only; optionally force the loader to load specific sync library `mcos*`. If NULL, the loader will select `mcoslnx` if shared memory is requested, `mcoslnxp` otherwise
memory_library | For Unix-Linux only; optionally force the loader to load specific memory library `mcom*`. If NULL, the loader will select `mcomipc` if shared memory is requested, `mcomconv` otherwise
runtime_path | For Windows and Unix-Linux; overrides the eXtremeDB library search path

### Description

> Some eXtremeDB components need to link with eXtremeDB libraries dynamically. The most common reason is the need to be able to choose the core configuration (transaction manager, local/shared memory, persistence, etc.) at runtime. eXtremeDB currently ships with several components that need it, such as xSQL, Java, and .NET Framework wrappers.

> However, eXtremeDB core components have mutual dependencies, i.e. there are pairs of libraries that use each other’s functions. This is usually not a problem on Linux and UNIX-like platforms, but it is impossible to build these libraries as standalone DLLs on Windows, since Windows requires all dependencies to be resolved at compile time, which is obviously unattainable with mutual dependencies.

> The solution is to provide “configurations” as separate DLLs on Windows that include all mutually dependent libraries, as well as any extra libraries provided by the distribution (SQL, Cluster, HA and others). An example of a configuration would be “MURSIW + disk + shmem + debug”. A full set of configurations is provided for each of the products that use dynamic core configuration. Furthermore, each of the components that uses configurable core has to manually set up DLL search paths, load the required configuration’s shared library, handle platform-dependent issues, etc.

> To address these issues, two components are provided: `mcocore` and `mcoloader`.

> The `mcocore` library is essentially the same set of libraries as the other wrappers mentioned above (xSQL, Java, .NET Framework wrappers). It packages all interdependent libraries in “configurations”, which are available as separate DLLs on Windows. Unlike the wrappers, `mcocore` does not include the SQL, Cluster, HA and other components that are “external” to the core. Also, there is no need for `mcocore` configurations on UNIX systems, so this is a strictly Windows entity.

> The `mcoloader` library exports the single function `mco_core_load()` that allows the application to select the core configuration, and "wrappers around pointers" to the actual eXtremeDB core functions (including non-static internal functions).

> So, instead of linking with the eXtremeDB core static libraries or loading them dynamically, the application simply links with `mcoloader`.

> When `mco_core_load()` is called, it loads the required configuration’s DLL (or shared objects on UNIX) and retrieves addresses for all its functions; the “wrappers” for core functions will call the loaded functions using their addresses. The functions are loaded in the `loaderimpl.c` file. This file should not be modified manually; it is generated by a script. This script takes in the file containing the list of functions, and generates all the necessary type definitions, variables, functions and loader function calls.

> The `mcoloader` is currently available for Windows, Linux and macOS. It provides the user with the uniform core configuration interface.

### Return Codes

MCO_S_OK | Core libraries successfully loaded
MCO_E_CORE | The core libraries load failed

Related Topics