I'm developing a little project based on vulkan with glm glfw adding several other constructor libraries like rplidar and accelerometer sensor, all went fine, even when I passed from simple make to cmake to use cgal library, until, all of the sudden, this error appeared :
g++ -std=c++17 -O2 -I. -I./dependencies/include -I./dependencies/src -L./dependencies/lib -Wall -funsigned-char -fPIC -o vulkanRPLidar main.cpp -lglfw3 -lvulkan -ldl -lpthread -lX11 -lXxf86vm -lXrandr -lXi -lrt -lstdc++ -lsl_lidar_sdk
In file included from /usr/include/X11/Xlib.h:44,
from main.h:30,
from main.cpp:1:
/usr/include/boost/math/tools/roots.hpp:793:16: error: expected identifier before numeric constant
793 | template<class Complex, class F>
| ^~~~~~~
/usr/include/boost/math/tools/roots.hpp:793:16: error: expected ‘>’ before numeric constant
/usr/include/boost/math/tools/roots.hpp:794:1: error: expected unqualified-id before numeric constant
794 | Complex complex_newton(F g, Complex guess, int max_iterations = std::numeric_limits<typename Complex::value_type>::digits)
| ^~~~~~~
Here I tried again with simple make, but the same error with cmake. I tried every packages reinstallation from X11 to Boost, in vain (the exact same errors). Even installed boost from source 1.82.0 and linked successfully with the project but still in vain.
I went through the file's error from Xlib.h and deeper to see that boost is not used at all in those files !!! So strange !
In the doubt that the "Complex" class name is used in "limits" or "algorithm" libs (having reordered the inclusion in my header) to avoid imaginary conflict I temporarily commented them, but still the same error.
It's been days I'm searching the forums for similar situations but nothing. I really hope to find some help regarding this issue. I have to add that an ubuntu update went on the day this error appeared, but nothing related : the most related being the vulkan-layers updated that moment, but separately Vulkan works great... I don't know
$ fgrep Complex /usr/include/X11/X.h
#define Complex 0 /* paths may intersect */
$
Avoid using XLib includes and any moderately complex third-party includes in the same source file, especially XLib above said complex third-party includes, because XLib has a nasty habit of #defineing very common names. But if you must, watch for error messages like the one you've got and #undef.