Compiling Xerces-C with toolchain validation and clean installation

Xerces-C is a core XML dependency for multiple C++ integration stacks. The important part is not only building it, but ensuring predictable runtime for projects that link against it.

Goal and risk control

Goal: install xerces-c-3.2.5 with reproducible behavior.

Main risks addressed:

incomplete dependency chain;
conflicting system/local libraries;
missing post-install verification.

Install dependencies

# Debian/Ubuntu
sudo apt update
sudo apt install -y build-essential libssl-dev libreadline-dev libncurses5-dev libcppunit-dev pkg-config doxygen

# RHEL/CentOS
yum groupinstall -y "Development Tools"
yum install -y xerces-c-devel openssl-devel readline-devel ncurses-devel cppunit-devel pkgconfig doxygen

Download and extract

cd /usr/local/src
wget http://archive.apache.org/dist/xerces/c/3/sources/xerces-c-3.2.5.tar.bz2
tar -xjvf xerces-c-3.2.5.tar.bz2
cd xerces-c-3.2.5

Configure and build

./configure
make -j"$(nproc)"
make install
make doc
ldconfig

Post-install checks

ldconfig -p | grep -i xerces
find /usr/local/include -iname '*xerces*' | head
pkg-config --cflags --libs xerces-c || true

Practical troubleshooting

Linking failures after successful configure usually indicate library path

conflicts.

Fix by reviewing loader paths and cleaning stale build artifacts.
Permission errors on make install require elevated install step only.

Validation with dependent project

After installation, validate against a real consumer project such as libepp-nicbr:

cd /usr/local/src/libepp-*
./configure
make -j"$(nproc)"

Successful consumer build confirms that Xerces-C is not only installed, but actually linkable in your operational toolchain.

Final takeaway

A stable Xerces-C installation depends on disciplined dependency validation and runtime checks, not only on successful compilation output.

This post is licensed under CC BY-NC.