-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
libc++ assumed to be required for C++11 support when using Clang #604
Comments
GLM is just being conservative. Are you aware of a way to detect the C++ version of the STL implementation? I have been looking for one for exactly this purpose... |
I guess it may be possible to check for it, but as far as I know, there is no single universally-supported be-all end-all solution. If you really need to check for it, the only way would probably be to do the exact same thing you're already doing; just keep iterating on it until nobody complains. As for Clang, the solution linked above seems to be reliable since this commit (May 2012) for both In general, the best way to deal with such an issue is to first check the most "promising" heuristic, and keep falling back to lesser heuristics until you end up deciding that it does not fit the bill. That way you can minimize the chance of failure to such a low rate that nobody notices it. |
Erm, I think GLM does a good job at C++11 checking https://github.com/g-truc/glm/blob/0.9.8.3/glm/detail/setup.hpp#L170 but yes the STL implementation version is independent from compiler version. You can use GLM_LANG_STL11_FORCED to force GLM to consider that the STL implementation is a C++11 one. Thanks, |
@Groovounet, as far as I can tell, defining |
I had a second look and turns out I was wrong. \o/ Thanks for contributing, |
libstdc++ is the default STL implementation in Linux (at least in most distributions), and provides full support for C++11 (and C++14). However, GLM assumes that it doesn't have C++11 support when compiled using Clang with anything but libc++. This is a wrong assumption to make, and breaks the build for no actual reason on Linux.
The text was updated successfully, but these errors were encountered: