← All tasks
cppceres-solver/ceres-solver #669Reported task

cmake script is not compatible with TBB 2021.1

envgap__ceres-solver__ceres-solver-669

01 / FAILURE SIGNATURE

Captured in a clean container

file STRINGS file "/usr/include/tbb/tbb_stddef.h" cannot be read.

02 / ENVIRONMENT RECIPE

Base commit
323c350a66c503fe2815286f48da391b6ce01bc6
Manifest
CMakeLists.txt
Reproduce
apt-get update -qq && DEBIAN_FRONTEND=noninteractive apt-get install -y -qq libeigen3-dev libgoogle-glog-dev libgflags-dev libsuitesparse-dev libtbb-dev libblas-dev liblapack-dev && cmake -S . -B build -DBUILD_TESTING=OFF -DBUILD_BENCHMARKS=OFF -DBUILD_EXAMPLES=ON -DSCHUR_SPECIALIZATIONS=OFF && cmake --build build --target helloworld -j2 && ./build/bin/helloworld
Run under trace
./build/bin/helloworld
Reference environment fix used for admission
diff --git a/cmake/FindTBB.cmake b/cmake/FindTBB.cmake
index 5ae7b615..9e364405 100644
--- a/cmake/FindTBB.cmake
+++ b/cmake/FindTBB.cmake
@@ -432,7 +432,7 @@ if(NOT TBB_VERSION)
 
  #only read the start of the file
  file(STRINGS
-      "${TBB_INCLUDE_DIR}/tbb/tbb_stddef.h"
+      "${TBB_INCLUDE_DIR}/oneapi/tbb/version.h"
       TBB_VERSION_CONTENTS
       REGEX "VERSION")

03 / ORIGINAL ISSUE TEXT

ceres-solver/ceres-solver #669 · read the original issue
When I try to build `ceres-solver` with tbb [2021.1.1](https://github.com/oneapi-src/oneTBB/releases/tag/v2021.1.1) it fails an with error:

```

CMake Error at cmake/FindTBB.cmake:434 (file):

  file STRINGS file "/usr/local/include/tbb/tbb_stddef.h" cannot be read.

Call Stack (most recent call first):

  cmake/FindSuiteSparse.cmake:309 (find_package)

  CMakeLists.txt:282 (find_package)

```



It turns out, that file [`tbb/tbb_stddef.h`](https://github.com/oneapi-src/oneTBB/blob/v2020.3/include/tbb/tbb_stddef.h) was removed from tbb 2021.1, and now there's [`oneapi/tbb/version.h`](https://github.com/oneapi-src/oneTBB/blob/v2021.1.1/include/oneapi/tbb/version.h) with similar content though.



If I replace `tbb/tbb_stddef.h` with `oneapi/tbb/version.h` in `cmake/FindTBB.cmake` it builds without any error.
Continue on GitHub ↗

04 / LABELS

Labels checked by running the task · assistant reviewed

misspecificationsecurity
Label rules and the text that matched
[
  {
    "category": "misspecification",
    "rule": "diff.changes_existing_manifest_line",
    "source": "manifest_diff:cmake/FindTBB.cmake",
    "excerpt": "-      \"${TBB_INCLUDE_DIR}/tbb/tbb_stddef.h\"\n+      \"${TBB_INCLUDE_DIR}/oneapi/tbb/version.h\""
  },
  {
    "category": "security",
    "rule": "audit.nonempty_security_flags",
    "source": "security_flags",
    "excerpt": "[\"unpinned\"]"
  },
  {
    "category": "security",
    "rule": "issue.security_keyword",
    "source": "issue_body",
    "excerpt": "thub.com/oneapi-src/oneTBB/blob/v2020.3/include/tbb/tbb_stddef.h) was removed from tbb 2021.1, and now there's [`oneapi/tbb/version.h`](https://github.com/oneapi-src/oneTBB/blob"
  }
]

Historical install-only results are not EnvGap validation.

System prerequisite packages are installed identically for original and gold; the failure is reached after the prerequisite context is present.

Ubuntu22 apt provides TBB2021.5.0, not the exact reported2021.1.1. Both lack tbb/tbb_stddef.h and supply oneapi/tbb/version.h. Apt packages are not issue-date bounded; package versions and install evidence are in execution logs.

CMake test and benchmark targets are disabled and Schur specializations are disabled for build time; the existing helloworld example still builds the Ceres library and executes its numerical solver. This exact command is identical before and after the environment fix.

CMake D1 statically records top-level find_package declarations, including platform/option-conditional packages. Header-only and statically linked libraries need not appear among runtime shared-library loads; C++ manifest_F1 has that visibility limit.

No source files were changed. The gold changes only a CMake dependency-discovery path.

Preparation uses current registries. Historical package availability is not enforced here; execution metadata records this limitation separately from the oracle's date-bounding policy.