This seems like a bug? ```osquery> select versi...
# core
This seems like a bug?
Copy code
osquery> select version, build_platform from osquery_info;
       version = 4.9.0
build_platform = 1
or similar on Linux?
on mac:
Copy code
osqueryi --line 'select version, build_platform, build_distro from osquery_info;'
       version = 4.9.0
build_platform = darwin
  build_distro = 10.12
I had to go back to 3.3.2 for a sane looking result on linux, but it's still not what I'd expect:
Copy code
docker run --rm -it dactiv/osquery:3.3.2-ubuntu20.04 osqueryi --line 'select version, build_platform, build_distro from osquery_info;'
       version = 3.3.2
build_platform = ubuntu
  build_distro = xenial
It seems a stringification issue which only appears on Linux clang for some reason..
I see that too now. OSQUERY_BUILD_PLATFORM is a define preprocessor used to set that value and is passed to the compiler as
, then it’s used in code as
r["build_platform"] = STR(OSQUERY_BUILD_PLATFORM)
STR should stringify it
oh I see now..
is a macro too, so instead of expanding to the string linux, it also expands that macro and the result is 1
So yeah, this is fixable by having CMake generate a file which contains C++ code with the correct strings in it and without using macros, since it gives this issue. Something like:
Copy code
const std::string kOsqueryBuildPlatform = @OSQUERY_BUILD_PLATFORM@
and then that OSQUERY_BUILD_PLATFORM it’s actually a CMake variable that is substituted using
CMake could also try to detect the platform specifics, since right now we hardcode values instead
actually nvm, even simpler fix for now is to use
and then remove the stringification, since it’s already a string (otherwise it would print
I've also opened an issue here: I think that with the 2 build systems conversions there has been a confusion on what build_platform and build_distribution should represent too.
👍 1
ty 1