-
Notifications
You must be signed in to change notification settings - Fork 165
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
Fix pkgconfig files (mostly for static linking) #2005
Conversation
Perf diff from master - unit tests
Heap diff from master - unit tests
Heap diff from master - scap file
Benchmarks diff from master
|
e4de4bf
to
76021dc
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2005 +/- ##
==========================================
- Coverage 73.58% 73.58% -0.01%
==========================================
Files 253 253
Lines 31869 31869
Branches 5649 5630 -19
==========================================
- Hits 23452 23451 -1
+ Misses 8416 8401 -15
- Partials 1 17 +16
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Perf diff from master - unit tests
Perf diff from master - scap file
Heap diff from master - unit tests
Heap diff from master - scap file
|
LGTM. I tested a Logray build on macOS using the following CMake preset. The generated pkgconfig files look correct and after updating the Logray code to match the current libs API, everything built and ran as expected.
|
@@ -214,21 +214,7 @@ endif() | |||
|
|||
if(HAS_ENGINE_GVISOR) | |||
add_subdirectory(engine/gvisor) | |||
# The static and shared build differs here because a shared scap_engine_gvisor | |||
# will result in circular dependencies. | |||
if(BUILD_SHARED_LIBS) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a question after a very first look: will BUILD_SHARED_LIBS
behave like before? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WDYM? libscap_engine_gvisor.so becomes a separate shared library, so that's a change, but other than that, there should be no observable changes (at least, Works For Me ™️)
TBH I'm not entirely sure when the circular dependency disappeared, probably when extracting some scap_platform_util or other
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant regarding BUILD_SHARED_LIBS
in general, but I noticed right now that it's only related to gvisor (and I believe it's acceptable).
cc @LucaGuerra
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, I consider splitting out scap_engine_gvisor as a separate .so a fix
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds fine!
|
||
add_dependencies(scap_engine_gvisor uthash) | ||
target_link_libraries(scap_engine_gvisor | ||
target_include_directories(scap_engine_gvisor | ||
PRIVATE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be PUBLIC
too? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm we'll find out when somebody tries to include scap_gvisor's headers :)
Overall, including anything except libsinsp/sinsp.h and its dependencies is not really supported right now (IIRC you can't include libsinsp/cri.h for example) and there's a decision to make. We either:
- support that and install a bunch of extra headers (IIRC we need absl and it's a pain to extract from grpc sources)
- explicitly don't support that and (ideally) remove the headers from the installed set
I'd greatly prefer option 2 (drop most headers from the installed set) but that would require us to have a well specified API :) I guess one option is to remove them and see who complains. Another would be to decree that sinsp.h is the public API and anything it does not include is off limits (if you want to include anything else, you're not using sinsp, you're developing it).
Either way, I think it's best to have a clear way with the private(ish) headers shipped with libs and IMO figuring that out is out of scope for this PR (which AFAIK at least doesn't make things worse).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we'll find out when somebody tries to include scap_gvisor's headers :)
😶🌫️
76021dc
to
5996563
Compare
I updated the branch to handle bs_threadpool, mostly by ignoring it (it does not appear in any headers it seems). I haven't got around to using the thread pool yet, but if it turns out we do need to install the headers, we'll know eventually ;) |
5996563
to
68a5edd
Compare
/milestone 0.19.0 |
Hey @gnosek can you rebase this PR on top of latest master (so that we test After that, this LGTM and can be merged IMHO. |
Agreed! Let's rebase and merge this |
Unify the implementation between libscap and libsinsp, recursively descend into dependencies to build the whole tree (while avoiding the scap->scap_engine_gvisor->scap cyclic dependency) and skip static libraries linked by shared libraries (they do not need to be linked again when building the final binary). Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
I must be the only one for whom building gvisor in a shared library fails (or maybe the only one actually trying to do this), but I can't see how it could compile. We need to: * privately link the object library with scap_platform_util to pick up its includes * publicly link with gRPC (and other dependencies) to ensure correct linking order Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
When using bundled dependencies, we install their headers into .../include/falcosecurity, so we do not need to generate a fancy include path. This way we don't leak the build-time include paths to dependencies in the generated pkgconfig files. When we're not using bundled dependencies, we still need to add their include paths to ours though, so keep doing that (for the three dependencies: tbb, curl, jsoncpp, that are actually used in any headers). The elephant in the room is gRPC (with its dependency absl), which we don't install at all but also have never put in LIBSINSP_INCLUDE_DIRS, so this patch doesn't make things worse: including pkgconfig-installed sinsp headers that depend on gRPC didn't work before and doesn't work now either. The real fix would be to stop installing them (they're not really public), but reviewing all headers for public/private status is out of scope for this PR. Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
In fact, do not install the headers either, since they're not used in the public API. Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
68a5edd
to
53cf2d7
Compare
@FedeDP @LucaGuerra just rebased and pushed |
Thank you Grzeg! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: FedeDP, gnosek The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
LGTM label has been added. Git tree hash: ce095dd5ce42502b3f115984198c4b13cb82f02e
|
What type of PR is this?
/kind bug
/kind cleanup
Any specific area of the project related to this PR?
/area build
Does this PR require a change in the driver versions?
What this PR does / why we need it:
This PR cleans up a bunch of things related to pkg-config files, so that:
Also, it turns out we no longer have a circular dependency between scap and scap_engine_gvisor, so just make scap_engine_gvisor into a proper shared library.
Which issue(s) this PR fixes:
Fixes #2004
Special notes for your reviewer:
Is there a CI wizard in the house? We could use a similar test (build sinsp-example using pkgconfig) for static builds but I feel like I'd break more than fix if I tried that myself :)
Also, fingers crossed for all the build variants I was unable to test locally :)
Does this PR introduce a user-facing change?: