Bug summary says it all. popper should probably back off of -ansi if it wants to use 'long long'. This gets caught by clang on freebsd where -ansi results in __STRICT_ANSI__ being defined and __LONG_LONG_SUPPORTED is only defined if not strict, or if the C standard version is greater than c99.
Does it work if you replace -ansi for -std=c++98 ?
No. c++98 is the standard in which 'long long' does not exist. -std=c++11 does work, however (but I suspect that this may make some older compilers unhappy).
We could either omit the -ansi option (which defaults to c++98 + gnu extensions) or use -std=c++11 when gcc >= 4.7. If we omit the option we need to ensure we don't use gnu extensions that are not supported by visual c++. If we use -std=c++11 we need to ensure we don't start using c++11 features until they are widely supported by compilers that are a few years old.
I leave it up to you... I think the easiest thing would be to just drop it and try to exercise caution...
And there's no flag to tell clang "yeah we know, we want to be standard but we also want to use long long since it's kind of interesting". This seems one of those cases where clang is trying to be too smart for its own good imho.
I'm sort of confused by that logic... you're using a compiler flag to enforce strict c++98 compliance so that you can't accidentally use non-standard features, but you get upset when the compiler forces you to adhere to the standard. If you want to be able to use features outside of the spec, then drop the flag that says "I want to be held to the spec". fwiw, it should be possible to work around this issue on FreeBSD by -D__LONG_LONG_SUPPORTED.
I've removed -ansi in the master branch
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.