SOCI - The C++ Database Access Library

Installation

Requirements

Below is an overall list of SOCI core:

• C++ compiler: GCC, Microsoft Visual C++, LLVM/clang
• CMake 2.8+ - in order to use build configuration for CMake
• Boost C++ Libraries: DateTime, Fusion, Optional, Preprocessor, Tuple

and backend-specific dependencies:

• DB2 Call Level Interface (CLI)
• Firebird client library
• mysqlclient - C API to MySQL
• ODBC (Open Database Connectivity) implementation: Microsoft ODBC, iODBC, unixODBC
• Oracle Call Interface (OCI)
• libpq - C API to PostgreSQL
• SQLite 3 library

Downloading

Download package with latest release of the SOCI source code: soci-X.Y.Z, where X.Y.Z is the version number. Unpack the archive.

You can always clone SOCI from the Git repository:

git clone git://github.com/SOCI/soci.git

Building using CMake

SOCI is configured to build using CMake system in version 2.8+.

The build configuration allows to control various aspects of compilation and installation by setting common CMake variables that change behaviour, describe system or control build (see CMake help) as well as SOCI-specific variables described below. All these variables are available regardless of platform or compilation toolset used.

Running CMake from the command line allows to set variables in the CMake cache with the following syntax: -DVARIABLE:TYPE=VALUE. If you are new to CMake, you may find the tutorial Running CMake helpful.

The following tables provide summary of variables accepted by CMake scripts configuring SOCI build. The lists consist of common variables for SOCI core and all backends as well as variables specific to SOCI backends and their direct dependencies.

IBM DB2

Firebird

MySQL

ODBC

Oracle

PostgreSQL

SQLite 3

Empty (sample backend)

By default, CMake will try to determine availability of all depdendencies automatically. If you are lucky, you will not need to specify any of the CMake variables explained above. However, if CMake reports some of the core or backend-specific dependencies as missing, you will need specify relevant variables to tell CMake where to look for the required components.

CMake configures SOCI build performing sequence of steps. Each subsequent step is dependant on result of previous steps corresponding with particular feature. First, CMake checks system platform and compilation toolset. Next, CMake tries to find all external dependencies. Then, depending on the results of the dependency check, CMake determines SOCI backends which are possible to build. The SOCI-specific variables described above provide users with basic control of this behaviour.

Building using CMake on Unix

Short version using GNU Make makefiles:

$ mkdir build
$ cd build
$ cmake -G "Unix Makefiles" -DWITH_BOOST=OFF -DWITH_ORACLE=OFF (...) ../soci-X.Y.Z
$ make
$ make install

Building using CMake on Windows

Short version using Visual Studio 2010 and MSBuild:

C:\>MKDIR build
C:\>cd build
C:\build>cmake -G "Visual Studio 10" -DWITH_BOOST=OFF -DWITH_ORACLE=OFF (...) ..\soci-X.Y.Z
C:\build>msbuild.exe SOCI.sln

Building using classic Makefiles on Unix (deprecated)

NOTE: These Makefiles have not been maintained for long time. The officially maintained build configuration is CMake. If you still want to use these Makefiles, you've been warned that you may need to patch them.

The classic set of Makefiles for Unix/Linux systems is provided for those users who need complete control over the whole process and who can benefit from the basic scaffolding that they can extend on their own. In this sense, the basic Makefiles are supposed to provide a minimal starting point for custom experimentation and are not intended to be a complete build/installation solution.
At the same time, they are complete in the sense that they can compile the library with all test programs and for some users this level of support will be just fine.

The core directory of the library distribution contains the Makefile.basic that can be used to compile the core part of the library. Run make -f Makefile.basic or make -f Makefile.basic shared to get the static and shared versions, respectively. Similarly, the backends/name directory contains the backend part for each supported backend with the appropriate Makefile.basic and the backends/name/test directory contains the test program for the given backend.

For example, the simplest way to compile the static version of the library and the test program for PostgreSQL is:

$ cd src/core
$ make -f Makefile.basic
$ cd ../backends/postgresql
$ make -f Makefile.basic
$ cd test
$ make -f Makefile.basic

The Makefiles for test programs can be a good starting point to find out correct compiler and linker options.

Running regression tests

The process of running regression tests highly depends on user's environment and build configuration, so it may be quite involving process. The CMake configuration provides variables to allow users willing to run the tests to configure build and specify database connection parameters (see the tables above for variable names).

In order to run regression tests, configure and build desired SOCI backends and prepare working database instances for them.

While configuring build with CMake, specify SOCI_TESTS=ON to enable building regression tests. Also, specify SOCI_{backend name}_TEST_CONNSTR variables to tell the tests runner how to connect with your test databases.

Dedicated make test target can be used to execute regression tests on build completion:

$ mkdir build
$ cd build
$ cmake -G "Unix Makefiles" -DWITH_BOOST=OFF \
   -DSOCI_TESTS=ON \
   -DSOCI_EMPTY_TEST_CONNSTR="dummy connection" \
   -DSOCI_SQLITE3_TEST_CONNSTR="test.db" \
   (...)
   ../soci-X.Y.Z
$ make
$ make test
$ make install

In the example above, regression tests for the sample Empty backend and SQLite 3 backend are configured for execution by make test target.

Libraries usage

CMake build produces set of shared and static libraries for SOCI core and backends separately. On Unix, for example, build/lib directory will consist of the static libraries named like libsoci_core.a, libsoci_sqlite3.a and shared libraries with names like libsoci_core.so.3.2.3, libsoci_sqlite3.so.3.2.3, and so on.

In order to use SOCI in your program, you need to specify your project build configuration with paths to SOCI headers and libraries, and specify linker to link against the libraries you want to use in your program.

Copyright © 2010-2013 Mateusz Loskot

Copyright © 2004-2011 Maciej Sobczak, Stephen Hutton