Sergiu Deitsch

This is actually a very good example why legacy variables should be dropped in the first place: those variables can be modified by subsequent `find_package` calls (e.g., by subprojects) causing...

The error stems from your Homebrew version of SuiteSparse not from Ceres: ```console /opt/homebrew/lib/cmake/SuiteSparse_config/SuiteSparse_configConfig.cmake:68 (find_dependency) ``` For some reason, the OpenMP C component is not usable. You could check the...

While Ceres 2.1.0 supported OpenMP as one of the threading backends, Ceres 2.2.0 removed OpenMP support in 06bfe6ffacecd09f82ca54e761117aa7d9bca565. This is likely the reason why the issue no longer occurs in...

You could try explicitly setting the `CERES_THREADING_MODEL` CMake variable, e.g., to `CXX_THREADS` to avoid Ceres invoking the above `find_package` call. Alternatively, you can unconditionally set the threading backend to `CXX_THREADS`...

I'm closing the issue as there are no more updates.

It looks like you are using Ceres Solver 2.1.0. Does the problem actually occur in 2.2.0?

I believe we can close the issue since there are no more updates.

It looks like you've updated to a development version of glog which recently removed deprecated methods. I suggest you use the release version of glog instead.

That's strange. How can this be reproduced? Our [macOS 13 runner](https://github.com/ceres-solver/ceres-solver/actions/runs/6216760122/job/16871002743#step:9:416) does not seem to show this problem.

There's a related [CMake discussion](https://gitlab.kitware.com/cmake/cmake/-/issues/25297) which provides a possible [workaround](https://gitlab.kitware.com/cmake/cmake/-/issues/25297#note_1425461). At this point, however, it does not seem to be easy to reliably identify the linker being used. Therefore, applying...