Hi Jacob,
Cantera 2.6.0 should work with a range of Eigen versions. If you don’t specify a location and SCons can’t find a version installed in a standard location, it will use a Git submodule, which is set to provide Eigen 3.3.7. To ensure consistency, you should explicitly set the SCons option system_eigen=y and add the directory containing the Eigen headers used by Tensorflow to the extra_inc_dirs option. I assume you meant either version 3.3.9 or 3.4.0, since 3.4.0 is the most recent Eigen release.
Regards,
Ray
Hi Jacob,
That appears to possibly be the latest development / unstable version of Eigen. As it says on the Eigen homepage (https://eigen.tuxfamily.org/index.php?title=Main_Page), the latest stable release is Eigen 3.4.0. Cantera has been tested to work with this version, but not with any development versions beyond that.
I noticed two things from the log:
First, there are some warnings that reference include/cantera/ext/Eigen, which suggest that you had previously compiled Cantera with the Eigen headers provided by Cantera. I would recommend deleting the directory include/cantera/ext/Eigen so these headers don’t get picked up before the ones from the Tensorflow installation.
Second, the directory you’re specifying as extra_inc_dirs is not the same as the directory where the build is picking up the Eigen headers, and I’m not sure what’s happening to get both of these directories on the compiler’s path. The former is
/home/mert/anaconda3/envs/tf/lib/python3.9/site-packages/tensorflow/include/third_party/
while the latter is:
/home/mert/Documents/tensorflow-2.13.0/bazel-bin/tensorflow/include/third_party
If these aren’t exactly the same version of Tensorflow and/or Eigen, then the compiler errors are not surprising.
Regards,
Ray
Hi Jacob,
SCons is just managing the compiler’s search path in a pretty standard way, that is, in addition to the compiler’s default search path adding a couple of directories withing the source tree, plus any directories that you’ve specified are needed. I don’t know where else on your system you have another, conflicting copy of the Protocol Buffers headers installed.
One step you can take that might help identify where the problematic headers are installed would be to run just the failing compilation command with the addition of the -H option, which will display (to stderr) the path to every header file read (recursively) as part of that compilation. This produces a lot of output, so I would recommend running it as:
g++ -H -o build/src/oneD/Boundary1D.os -c -std=c++17 -pthread -O3 -Wno-inline -g -Wall -include src/pch/system.h -fPIC -DNDEBUG -Iinclude -Iinclude/cantera/ext -Ibuild/src -I/home/mert/Documents/tensorflow-2.13.0/bazel-bin/tensorflow/include/third_party -I/home/mert/Documents/tensorflow-2.13.0/bazel-bin/tensorflow/include src/oneD/Boundary1D.cpp 2>&1 | lessRegards,
Ray