# eXtremeDB Unix-Linux Libraries - target/bin

> The `/target/bin` directory under your eXtremeDB installation root directory contains Java archives `extremedb.jar` and `extremedb_jdbc.jar`, a `python` subdirectory and a number of binary libraries described below. The Java archive files are required only for Java applications and JDBC applications. The python subdirectory contains shared object libraries and `exdb.py` which are required for Python applications.

> ## Python Subdirectory

> The `/target/bin/python` directory contains the eXtremeDB Python implementation source file `exdb.py` and the following Python shared object libraries:

> eXtremeDB.so | The release mode version of the eXtremeDB Python implementation
> eXtremeDB_debug.so | The debug mode version of the eXtremeDB Python implementation
> eXtremeDB_load.so | The loader functionality that dynamically loads requested runtime modules

> ## Native C Libraries

> The native C libraries (upon which the C++, Java and Python wrappers depend) are described in the sections below. 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 easily recognized with the `_debug` suffix in the filename
> - 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.)

> Java and Python applications load shared object versions of the necessary libraries at runtime, but normally C and C++ applications will statically link the appropriate libraries.

> ## 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
> libmcomalloc.a | Conventional memory device with internal memory allocation by the eXtremeDB runtime
> libmcomipc.a | Shared memory device using Unix-Linux IPC
> libmcompsx.a | Shared memory device using Unix-Linux POSIX

> ### 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).

> libmcoslnxp.a | POSIX synchronization implementation – faster than SysV-based but applicable only for conventional memory applications (Note that this library is good for multi-process applications if pthread supports that and the operating system is not MacOS)
> libmcoslnxs5.a | Pure SysV synchronization implementation – slowest but good for all applications
> libmcoslnx.a | SysV with atomic operations. - good for all applications in shared or conventional memory (Note that atomic operations avoid unnecessary kernel calls and can provide better performance.)

> ### 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, one of the following libraries is required depending on the file system used:

> libmcofuni.a | Unix-Linux file system support
> libmcofu98.a | Unix98 file system support
> libmcofu98zip.a | LZ Compression and database + mmap
> libmcofu98ziplog.a | LZ Compression and sequential log

> ### 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 [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.)

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

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

> For applications that 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 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