I'm compiling a program that uses Boost on a shared cluster. I have my own copy of gcc and most programs and libs I use in my home directory, including Boost 1.81.0. The cluster has Boost 1.66 in /usr/local/include. gcc seems to prefer these files over my local ones in some instances, leading to errors. How can I fix this?
This is the current include search list: (Edited to show the effect of -I/home/charlesprior/include )
GNU C++23 (GCC) version 12.1.0 (x86_64-pc-linux-gnu) compiled by GNU C version 12.1.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version none GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/home/charlesprior/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../x86_64-pc-linux-gnu/include" ignoring duplicate directory "/home/charlesprior/include" as it is a non-system directory that duplicates a system directory #include "..." search starts here: #include <...> search starts here: /home/charlesprior/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0 /home/charlesprior/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0/x86_64-pc-linux-gnu /home/charlesprior/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0/backward /home/charlesprior/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include /usr/local/include /home/charlesprior/include /home/charlesprior/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include-fixed /usr/include End of search list. If I use -I/home/charlesprior/include (which is what I did in the example above) to try and force that to the top, gcc ignores the duplicate. If I use -I/some/other/dir/include where that includes Boost, everything compiles fine. I want to not have to do this and just make gcc use the include files in my home directory. An example of the type of error I get is:
In file included from /home/charlesprior/include/boost/histogram/detail/detect.hpp:11, from /home/charlesprior/include/boost/histogram/axis/traits.hpp:12, from /home/charlesprior/include/boost/histogram/indexed.hpp:12, from /home/charlesprior/include/boost/histogram/algorithm/empty.hpp:11, from /home/charlesprior/include/boost/histogram/algorithm.hpp:15, from /home/charlesprior/include/boost/histogram.hpp:27, from test.cpp:1: /usr/local/include/boost/mp11/function.hpp: In substitution of ‘template<class ... T> using variant_ca_base = boost::variant2::detail::variant _ca_base_impl<std::integral_constant<bool, (static_cast<bool>(std::is_copy_constructible<T>::value) ... && static_cast<bool>(std::is_copy_assi gnable<T>::value) ...)>::value, std::integral_constant<bool, (static_cast<bool>(std::is_trivially_destructible<T>::value) ... && (static_cast< bool>(std::is_trivially_copy_constructible<T>::value) ... && static_cast<bool>(std::is_trivially_copy_assignable<T>::value) ...))>::value, T . ..> [with T = {T ...}]’: /home/charlesprior/include/boost/variant2/variant.hpp:1449:96: required from here /usr/local/include/boost/mp11/function.hpp:97:77: error: invalid use of pack expansion expression where you can see that gcc included a file from /usr/local/include, leading to errors.
/home/charlesprior/include/boost/mp11/function.hpp?make,cmake,ninja,bazel, some IDE specific project file, .... . Or maybe you are building this manually?/home/charlesprior/include) anyway, but doesn't do anything to make the compiler prioritize this. My solution was to use try_compile with a small test program to see if the right version was being included. I've updated my answer with an example.