Apache Santuario

Skip to end of metadata
Go to start of metadata

Installing the Apache XML Security for C++ Library


The library requires one of OpenSSL, NSS, or WinCAPI for cryptographic support, but only OpenSSL is well-tested. Xalan-C is also required if XPath and/or XSLT transformations are required.

Version 2.0.0 of the library requires Xerces-C 3.2+ and (if used) Xalan-C 1.0.11+. It supports OpenSSL 1.1.0 but maintains support for older releases for now.

Getting the source

You can download the sources via WWW in the distribution directory from one of the Apache mirrors.

This project's SVN repository can be checked out directly from here

A HTTP interface to browse the sources online is available here

Building for UNIX

XML Security C++ is currently fully supported on a few Linux distributions, principally Red Hat and derivatives, and macOS. It has been built and tested using a variety of compilers, but mostly gcc/g++.

Set up the Environment

The build process has been corrected as much as possible to rely on standard configure and make commands and not environment variables. It is a pkg-config-based build as of V2.0.0, and will auto-detect the right settings to use when possible.

If configure cannot find anything for Xalan, it will assume that you are not interested in XPath or XSLT support and will compile without linking to Xalan. Any attempt to use these features will raise an exception in the library.

You should normally provide one of --with-openssl or --with-nss to the build to ensure that at least one of the desired provider plugins is built and available. Saying nothing may result in the build completing but with no actual plugin included.


Now go to the root directory and run the command ./configure. This will create the necessary makefiles and header files necessary to build the package.

In addition to the standard options, configure can be passed a number of XSEC specific options :

  • --without-xalan disable linkage to Xalan.
  • --with-openssl to require OpenSSL support be available
  • --with-nss to require NSS support be available
  • --enable-xkms to include the XKMS support

Using the --without-xalan option will automatically mean that the library does not support XPath or XSLT transformations (although envelope transforms will work as the library can perform these without going through an XPath transform).


Assuming the output of the above command looks reasonable simply type make (or gmake) in the base directory. This will build the library. In addition, make tools will make the tools (or examples) in the src/tools directory.

The make process will create three directories in the distribution directory:

1. include - All public header files are copied here
2. bin - Where the tools are placed once compiles
3. lib - Where the shared library is place

You may need to set up your LD_LIBRARY_PATH environment variable to ensure ld.so will find the new shared libraries.

Finally - you can use make clean and make distclean to remove all binaries and libraries (former) and build scripts (latter)


make install can be used to install the library and the include files into the relevant directories (which can be set via the configure script using the various --prefix= options.

Building for Windows

Apache XML Security for C++ has been built and tested on Microsoft's VS 2017 compiler series but you will need to do substantial manual work to the solution files for your particular environment and to locate dependencies.

The library can be built without OpenSSL on a Windows platform by using WinCAPI, but this is deprecated.

Some of the settings you may need to touch will be in the .../src/framework/XSECW32Config.hpp file, including macros to determine whether Xalan, OpenSSL, NSS, WinCAPI, and/or XKMS support are included in the build.

The solution files include a "Minimal" debug and release option that presumes no Xalan, NSS, WinCAPI, or XKMS support.

Apologies for the incompleteness of this information but the project is now maintained solely for use by a single downstream project and it has build workflows that do not require a fully-working solution file for arbitrary project consumers at this time.

  • No labels