# eXtremeDB VxWorks Libraries - target/bin/<PROCESSORcompiler>

> The `/target` directory under your eXtremeDB installation root directory contains a number of binary libraries in subdirectories with names beginning with "bin-": One set is for the target processor, the other set in the directory with name beginning "bin-sim" is for the simulator in the host environment. These will be statically linked to your C/C++ applications. In addition, there are source code files in directory `libmcohv` that can be used to build the HTTP Viewer interface. The libraries provided for all eXtremeDB packages are described below. Please refer to the following link for descriptions of additional libraries to support extension module features.

> Each library is provided in two forms:

> - Debug - used during development to aid in finding application level errors; contains several levels of checks for possible erroneous argument values and other error conditions that should be caught and resolved before application deployment; These are located in the directory with the `-debug` suffix
> - Release - used when the development cycle is completed or when performance comparisons are desired; because most of the checks built into the debug version are removed this version of the libraries performs significantly faster

> (Only release mode filenames are shown in the sections below.)

> ## Required Libraries

> The following tables lists the essential libraries that implement the eXtremeDB functionality. Platform-dependent functionality is implemented in the set of libraries called System Access Layer (SAL) . At least one of the libraries from each of the categories below must be linked to C and C++ applications together with the supporting SAL libraries.

> The SAL libraries in the following table implement the indicated functionality for all supported platforms:

> libmcosalatomic.a | Atomic operations
> libmcosallatches.a | Latches implementations
> libmcosaltimer.a | Lo-resolution and hi-resolution timer implementations
> libmconet.a | System network layer
> libmcosalmem.a | System memory management
> libmcosalsmp.a | System mutex, semaphores, threading and other multi-thread/process related code
> libmcosaldload.a | System dynamic loader
> libmcosalhollow.a | Stub functions for in-memory database single-threaded applications only

> ### Core Runtime

> Of the following libraries, `libmcolib.a` is required for basic eXtremeDB functions and either `libmcovtmem.a` or `libmcovtdsk.a` is required depending on whether a persistent database is used:

> libmcolib.a | Main database functions
> libmcovtmem.a | Virtual Table management for in-memory databases
> libmcovtdsk.a | Virtual Table management for persistent and hybrid databases

> ### Memory Device Manager

> Depending on the type of database memory device being used, one of the following libraries is required:

> libmcomconv.a | Conventional memory device
> mcomalloc.lib | Conventional memory device with internal memory allocation by the eXtremeDB runtime
> libmcompsx.a | Shared memory device using IPC

> ### Transaction Manager

> Depending on the choice of Transaction Manager, one of the following libraries is required:

> libmcotmursiw.a | MURSIW (MUlti-Read-Single-Write) transaction manager
> libmcotmvcc.a | MVCC (Multi Version Concurrency Control) transaction manager
> libmcotexcl.a | EXCLusive transaction manager

> ### Concurrency Management

> One of the following libraries is required to manage synchronization of database access from multiple threads or processes.

> (Note that minimalistic single threaded in-memory database applications, a “hollow” synchronization stub is provided in library `libmcosalhollow.a`. It has no synchronization code so it is the fastest implementation - but it is valid for single-threaded applications only. If the application links with `libmcosalhollow.a` then no synchronization library is necessary).

> libmcosvxn.a | Synchronization implementation using conventional memory
> libmcosvxshm.a | Synchronization implementation using shared memory

> ### Persistent Database Support

> All C and C++ applications using the Persistent Storage APIs must link with `libmcovtdsk` instead of `libmcovtmem` for "virtual table" control, and, in addition, the following file system wrapper library is required:

> libmcofvx.a | VxWorks file system support

> Or, if a custom file system wrapper is desired, the following library is provided as an empty "placeholder" (also provided for convenience are the project files to build this library):

> libmcofempty.a | A placeholder for a possible custom VxWorks file system wrapper implementation

> ### Utility Functions

> Miscellaneous functionality used in eXtremeDB internals are provided in the following libraries. Depending on whether the standard C runtime libraries are used one of these is required:

> libmcouwrt.a | Utilities using the C runtime
> libmcounrt.a | Utilities without the C runtime

> ## Optional Libraries

> The following sections describe optional libraries that are required only for the eXtremeDB features specified:

> ### Dynamic Module Loader [Optional]

> The following library provides the capability to dynamically load parts of the eXtremeDB core on request:

> libmcoloader.a | Provides the `mco_core_load()` API to dynamically load parts of the eXtremeDB core on request

> ### Sequence Data Type Support [Optional]

> These libraries provide basic ``sequence`` data type operations such as reading and inserting `sequence` data. All applications that use the `sequence` data type must link with one of the following libraries:

> libmcoseq.a | `Sequence` data type API support
> libmcoseqrle.a | `Sequence` data type with RLE compression API support

> ### Analytics Function Library Support [Optional]

> If, in addition to basic sequence operations, mathematics and statistical functions that operate on sequences are required, applications must link with one of the following libraries:

> libmcoseqmath.a | Mathematical and statistical functions operating on `sequences`
> libmcoseqrlemath.a | Mathematical and statistical functions operating on `sequences` with RLE compression

> ### Active Replication Fabric Support [Optional]

> eXtremeDB Active Replication Fabric packages provide the following libraries. All applications that use ARF (IoT) APIs must link with both:

> libmcoiotcomm.a | IOT communication library
> libmcoiotrepl.a | IOT replication

> ### Transaction Logging APIs [Optional]

> The eXtremeDB Transaction Logging APIs are implemented in the following library. All applications that use the Transaction Logging API must link with:

> libmcolog.a | Transaction Logging API

> In addition, all applications that use the Transaction Logging APIs must link with a File System Wrapper library (see the Persistent Database Support section above)

> ### Backup [Optional]

> The following library is provided for applications using the incremental backup feature to backup and restore databases on persistent media:

> libmcobackup.a | Incremental backup and restore for in-memory and persistent databases

> ### Serialization [Optional]

> The following library is provided for applications using the `save` / `load` features to store and retrieve database or class snapshots on persistent media. (Note that this functionality does not require file system wrappers. The `save` / `load` features use an abstract stream (implemented by the application) to transfer data to the operating system.)

> Serialization capability is implemented in the following library:

> libmcoseri.a | Serialization (save and load) for all-in-memory databases

> ### Uniform Data Access (UDA) [Optional]

> For applications the use the Uniform Data Access functions the following library is required:

> libmcouda.a | Required if UDA APIs are used

> ### Debug Error and Tracing Diagnostics [Optional]

> The eXtremeDB tracing framework allows applications to output trace and debugging information to a log file. If desired, the following library can be included:

> libmcotrace.a | Required if tracing framework is used

> ### Database Calculator [Optional]

> The following library is required for applications that use the database calculator:

> libmcodbcalc.a | Database Calculator implementation

> ### HTTP Database Viewer [Optional]

> The HTTP Viewer requires the following two libraries:

> libmcoews.a | HTTP server implementation
> libmcohv.a | HTTP Database Viewer (without SQL capability)

> ### Cryptography [Optional]

> The Database Encryption feature requires one of the following libraries:

> libmcocryptaes.a | AES encryption algorithm
> libmcocryptstub.a | Empty encryption APIs for custom implementation