Building Intel’s decimal floating-point library on macOS (CMake)

Scope: This article is a how-to for wiring your own CMake build around Intel’s official Decimal Floating-Point Math Library package. It does not redistribute Intel’s source code, binaries, or license text. You must download the library from Intel and follow Intel’s license and terms for any use, modification, or sharing.

If you integrate with Interactive Brokers’ API, you may eventually need decimal floating-point support: their stack expects IEEE decimal semantics in places, and one practical route is Intel’s Decimal Floating-Point Math Library (Intel® Decimal Floating-Point Math Library) — often referred to as libDFP or the BID implementation.

Binary float / double are fine for many things, but decimal is what financial rules and APIs often assume; mixing binary floats in those paths can introduce tiny errors that are unacceptable when you need deterministic decimal behavior.

Intel publishes source for Linux, Windows, and macOS. The upstream tree is Makefile-oriented. For personal projects, a small CMake layer you write yourself — living beside a local checkout of Intel’s sources (with Intel’s license file preserved next to them) — can give you one build description you reuse across machines and wire into a parent CMakeLists.txt with add_subdirectory, without mixing Intel’s files into unrelated trees.

This post is how to reason about that wrapper on macOS (Apple Silicon) and what to adjust for Linux or Windows so the same workflow stays consistent.

Obtaining Intel’s package (your responsibility)

  1. Use only Intel’s official distribution page and any license or README they ship.
  2. Keep Intel’s license and attribution files with the sources you extract—wherever you store them.
  3. Before you publish a repo that contains Intel source (even in a submodule), read Intel’s license and confirm your use case (private mirror, fork, etc.) is allowed. This guide does not summarize those terms.

What follows assumes you already have Intel’s tree locally in a directory layout you control (e.g. a private repo or a vendor folder) and that you are not relying on this blog to supply any Intel files.

What to take from Intel’s package (conceptually)

After you unpack Intel’s official package, the pieces you typically compile are essentially the LIBRARY / src tree of C files, plus a CMakeLists.txt that you author. You do not need to wire Intel’s float128/ / DPML transcendental path in a minimal CMake build: that subtree expects Intel’s proprietary mphoc preprocessor for a couple of generated files (#include "mp.h" fails without it). For IB-style decimal work, the core BID operations in src/ (arithmetic, compare, conversions, rounding) are often enough; the missing piece is transcendentals (sin, cos, exp, log, …) in some configurations — match symbols to whatever your consumer actually links.

CMake on macOS (Apple Silicon)

The idea is a single static library target (e.g. bid) that compiles all src/*.c files you choose to include from your Intel tree.

Compiler flags can mirror Intel’s Makefiles for Clang on macOS:

  • Optimization: -O3
  • Position-independent code: -fPIC (useful if the static archive later ends up inside a shared library)
  • Warnings: -w on third-party code (optional)

Preprocessor defines (common Intel Makefile set):

CALL_BY_REF=0 GLOBAL_RND=0 GLOBAL_FLAGS=0 UNCHANGED_BINARY_FLAGS=0

For standalone builds, you can mirror a predictable output layout, e.g. bin/arm64/debug/libbid.a vs release, from CMAKE_BUILD_TYPE.

Build (after CMake and Xcode Command Line Tools are installed), from your wrapper project root — paths are examples only:

cd /path/to/your/cmake-wrapper   # your repo; Intel sources live where your CMake expects them
cmake -B build/cmake -DCMAKE_BUILD_TYPE=Debug
cmake --build build/cmake -j

Release:

cmake -B build/cmake -DCMAKE_BUILD_TYPE=Release
cmake --build build/cmake -j

Using the same layout in a larger app: if your policy allows, you can point a git submodule at your wrapper (or at a tree that includes Intel’s sources per their license). In the parent:

add_subdirectory(extern/<your-wrapper-or-vendor-dir>)
target_link_libraries(your_target PRIVATE bid)

The bid target should PUBLIC-expose include directories for src/ headers so consumers compile against the same API.

Making the same idea work on Linux and Windows

The sources are portable C; differences are toolchain, ABI, and output layout.

Concern macOS Linux Windows
Compiler Clang (Xcode) GCC or Clang MSVC or Clang with MSVC ABI
Arch flags CMAKE_OSX_ARCHITECTURES (e.g. arm64) -m64 / default triplet /arch:, /MT vs /MD, etc.
Static lib libbid.a libbid.a bid.lib
PIC -fPIC -fPIC if linking into .so N/A (different model)

A portable CMakeLists.txt usually:

  1. Avoids hard-coding CMAKE_OSX_ARCHITECTURES unless you’re on Apple (APPLE / Darwin).
  2. On Windows, uses MSVC / clang-cl flags instead of -fPIC.
  3. Uses generator expressions if you want a consistent bin/<arch>/<config>/ layout on every OS.

Once those branches match your machines, the same build recipe can be reused: configure once per platform, build.

Linking against Interactive Brokers

Exact steps depend on your language binding and whether IB ships prebuilt binaries for your OS. If you build from source, you typically:

  1. Produce libbid.a (or the platform equivalent) as above.
  2. Link your IB client / wrapper with bid plus whatever IB already expects (system libs, their SDK).
  3. Run IB’s samples or tests and confirm no missing symbols from any DPML / float128 pieces you chose not to build.

If you later need transcendentals from the full Intel package, you either integrate mphoc and the float128 pipeline or follow Intel’s full documented build — that’s beyond a slim src/*.c CMake target.

Summary

  • Intel’s library addresses decimal math where binary float is wrong for the API; you obtain it from Intel and comply with their license.
  • A CMake wrapper you write can sit next to those sources for personal or internal builds and integrate with add_subdirectory.
  • Toolchain-specific CMake branches bridge macOS, Linux, and Windows without maintaining three separate shell builds.

Disclaimer: This is not legal advice. Verify Intel’s current license, redistribution rules, and any Interactive Brokers terms that apply to your deployment before production use.