POCO C++ libraries: what the build system gives you and what it leaves out

The default build compiles every component, including the 290 KB logger

The plain configure step covers the whole tree. The documented build sequence is:

$ git clone -b main https://github.com/pocoproject/poco.git
$ cd poco
$ mkdir cmake-build
$ cd cmake-build
$ cmake ..
$ cmake --build . --config Release

The repository root carries separate directories for ActiveRecord, ApacheConnector, Benchmark, CodeGeneration, CppParser, CppUnit, Crypto, DNSSD, Data, Encodings, Foundation, JSON, JWT, MongoDB, Net, NetSSL_OpenSSL, NetSSL_Win, PDF, PageCompiler, PocoDoc, Prometheus, Redis, RemotingNG, SSH, SevenZip, Util, XML, XSD and Zip, and the default build includes all components and features. One of them deserves its own line in your notes. FastLogger is a Quill based high performance logger that adds roughly 290 KB to Foundation, and `-DENABLE_FASTLOGGER=OFF` drops it if you do not need sub microsecond logging. Size constrained deployments can combine the switches:

$ cmake .. -DPOCO_MINIMAL_BUILD=ON -DENABLE_FOUNDATION=ON -DENABLE_NET=ON \
  -DENABLE_UTIL=ON -DENABLE_FASTLOGGER=OFF \
  -DCMAKE_CXX_VISIBILITY_PRESET=hidden -DCMAKE_VISIBILITY_INLINES_HIDDEN=ON

Hidden visibility is what lets the linker discard unreferenced internal symbols from shared libraries. Once the tree builds, the Guided Tour and Getting Started pages under docs.pocoproject.org are the named entry points for the library itself. The libraries themselves are licensed under the Boost Software License.

A C++17 build leaves the C++20 features and the module surface out

The prerequisites name a C++20 compiler (Visual C++ 2022, GCC 10, Clang 10, Apple Clang 13, or newer); CMake selects C++20 when the compiler supports it and falls back to C++17 otherwise, and some features are only available with C++20. The module support sits behind a stricter gate: C++20, CMake 3.28 or later, and Ninja. The consequence for a reader is concrete rather than theoretical. Pin an older language standard and an older CMake and the configure step still completes, but the C++20 only features are not compiled into your libraries, and the module surface does not exist in that build at all. Nothing in the documented set of project specific CMake variables turns a C++17 build into a C++20 feature build, so this is a toolchain decision, not a flag you can find later. Treat the compiler version and the CMake version as build inputs you own in CI, in the same place you own the OpenSSL version.

macOS will not locate OpenSSL unless you name the prefix yourself

On macOS it is necessary to tell CMake where to find the OpenSSL headers and libraries by setting the `OPENSSL_ROOT_DIR` variable. With a Homebrew install the invocation becomes:

$ cmake .. -DOPENSSL_ROOT_DIR=/opt/homebrew/opt/openssl@3

On Intel Macs the path is `/usr/local/opt/openssl@3` instead. The same pattern covers the other external libraries:

$ cmake .. -DOPENSSL_ROOT_DIR=/opt/homebrew/opt/openssl@3 -DMYSQL_ROOT_DIR=/opt/homebrew/opt/mysql-client -DPostgreSQL_ROOT_DIR=/opt/homebrew/opt/libpq

OpenSSL 1.1.1 or newer headers and libraries are marked optional but recommended, and that is the second half of the problem: a configuration can finish without them and leave you without NetSSL_OpenSSL. Binary distributions are acceptable, so the Debian, Homebrew, WinGet and vcpkg routes all satisfy the requirement without a local compile. On Windows you can sidestep the whole question by targeting SChannel instead, at the cost of having no OpenSSL code path to test against.

The bundled Makefile exists mostly to warn you off it

The repository root still ships a Makefile, and its first act is to tell you to stop using it. The file opens with `$(warning Please build Poco with CMake)`, which make prints on every invocation. Under that line it includes config.make and config.build, emits a second warning when POCO_BASE is undefined and falls back to the current directory, derives POCO_CONFIG from the output of uname, collapses Cygwin and MinGW into their own names, and includes build/config/$(POCO_CONFIG). The target list covers poco, all, libexecs, cppunit, cpptrace, tests, samples, cleans, clean, distclean, install and uninstall, and the COMPONENTS line names Foundation, Encodings, XML, JSON, Util, Net, Crypto and NetSSL_OpenSSL further down the same list. Because CMake is the official build system, reading the Makefile as a specification of how the library is laid out will lead you to configuration variables that modern builds ignore.

Every dependency library is installed before configure, and by you

The external libraries listed as prerequisites are installed in a separate step before configure runs. For Debian, Ubuntu and Raspbian the documented command brings in the compiler, CMake, OpenSSL and both database client libraries at once:

$ sudo apt-get -y update && sudo apt-get -y install git g++ cmake libssl-dev libmysqlclient-dev libpq-dev

RedHat systems get openssl-devel, mysql-devel and postgresql-devel through dnf. Arch gets the mariadb and postgresql libraries through pacman. macOS gets cmake, openssl, mysql-client and libpq through Homebrew. The Windows WinGet line installs Git, LLVM, CMake, the ShiningLight OpenSSL development package, PostgreSQL, Oracle MySQL and Microsoft msodbcsql in one command. MySQL, PostgreSQL, ODBC and the Apache/APR client libraries are all listed as optional, which means a tree built without them compiles the core but not the Data connectors for those databases. On Windows there is one escape from the OpenSSL requirement: POCO can also use the native Windows TLS APIs, SChannel.

vcpkg and Conan trail main, and both say who fixes it

The main branch received its last push on 2026-11-02, and the tags moved with it: 1.15.4 on 2026-09-22, 1.15.3 on 2026-05-20 and 1.15.2 on 2026-04-16. Conan Center asks for an exact version, and adding one flag builds the recipe locally instead of taking binaries:

$ conan install --requires=poco/1.15.4
$ conan install --requires=poco/1.15.4 --build=poco

vcpkg takes no version argument at all, and the documented sequence is:

$ git clone https://github.com/Microsoft/vcpkg.git
$ cd vcpkg
$ ./bootstrap-vcpkg.sh
$ ./vcpkg integrate install
$ ./vcpkg install poco

What neither route promises is parity with what a clone of main produces. The poco port is kept up to date by Microsoft team members and community contributors, and the Poco recipe in Conan Center by Conan team members and community contributors, so both can sit behind the repository. The stated remedy for a stale vcpkg version is an issue or a pull request on the vcpkg repository, and the Conan section likewise asks for an issue or pull request. Before you file a bug against the library, check which version your package manager actually resolved.

The install target writes to /usr/local and documents no rollback

Headers and libraries are written only when you build the install target:

$ sudo cmake --build . --target install

The default prefix is `/usr/local/` on Linux and macOS and `C:\Program Files\` on Windows, and CMAKE_INSTALL_PREFIX overrides it. Embedded targets set that same variable at configure time, next to a toolchain file:

$ cmake .. -DCMAKE_TOOLCHAIN_FILE=/path/to/mytoolchain.cmake -DCMAKE_INSTALL_PREFIX=/path/to/target

If a machine needs 1.15.4 and a patched build at the same time, give each one its own prefix and point include and library search paths at them yourself. The Windows default lands in a directory that requires elevation, and the sudo prefix on the documented command carries no meaning there.

Editorial conclusion

Adopt POCO when you want one vendor's networking, XML, JSON and data components behind a CMake path you can trim for an embedded target, and track either main or a fresh tag rather than a package manager port that can trail. Before committing, confirm which version your package manager actually resolved, pin a C++20 toolchain if you need the features that only exist there, and decide who owns the OpenSSL, MySQL, PostgreSQL, ODBC and APR client libraries, because the project hands every one of them to you.

Frequently asked questions

Official sources

1. Issues
2. pocoproject/poco on GitHub
3. Project website
4. README
5. Releases