https://github.com/osquery/osquery logo
Join Slack
Powered by
I'm working on porting forward an old patch for co...
# core
a
I'm working on porting forward an old patch for containerd support, which requires grpc. I can get it to run but it fails when upgrading grpc with a linking error. I'd rather not keep an ancient grpc version, so does anyone with experience with cmake have troubleshooting suggestions?
z
cc @alessandrogario @Stefano Bonicatti any ideas?
a
Sorry for the late reply! I think it's a problem with absl, due to how properties are being propagated
A hack to fix it could be to just force a 
set(CMAKE_CXX_STANDARD 17)
right before the submodule is added
Some more details on why it is happening: osquery expects to be able to set link/build flags down through the dependency tree. Libraries are not always built in a way that make them usable directly as a submodule; some of the common problems are that they might try to go the opposite way, forcing their own build settings up the dependency tree
a
Interesting, I'll try that. I'm currently working on putting the proto files in a submodule but hopefully I can get that done today
đź‘Ť 1
a
So in practice, the problem starts from now being able to easily link the settings target (thirdparty_cxx_settings and thirdparty_c_settings)
If you prefer not to force it globally, you can also try to set it on absl; they are however exporting ALIAS targets that can't receive any build settings. So the only way is to track down the private targets: 
cmake --build build --target help | grep absl
The library may still try to fight against that though
a
Kind of weird grpc is like this, normally google likes to vendor everything
a
99% of the time CMake is used in wrong and absurd ways, sometimes I tell a joke about how much time I end up spending on build systems
If everything supported modern CMake and was written cleanly, we wouldn't even have a “libraries” folder in osquery
s
Up to a point though; I think the major problem is that not everyone considers that static libraries are a thing and much less that you may want to control the flags for the whole project. So the common setup is that each library it’s its own island that you want to build independently (because you’re going to build a .so after all, right?), and where you can query compilation flags.. so that you can adapt to it. Modern CMake unfortunately doesn’t give you that.
At the same time messing with the flags is always risky; naive example is that the project uses floating point math, but expects it to be IEEE 754 compliant and oops, my project enables 
-ffast-math
a
I think we should have a list of things that go wrong when importing a library
s
Modern CMake is more about CMake itself, which functions you use and partially how you structure the project, but I think the problems we normally have transcend a specific build system
a
Either way, it's so messy; I feel like we have chosen the least worse, especially compared to the old solution that used Linuxbrew. Wish there was a better way
a
Okay, that's building now and pushed! Thanks
I'm still a bit weirded out by the license of the protobuf files but it would be a huge pain to pull them from the containerd repo because they want a go directory structure
Open in Slack
PreviousNext
Powered by