-
Notifications
You must be signed in to change notification settings - Fork 164
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
PATCH: fix missing DSO tags for libdriver-event-schema.so #1201
Comments
Hi! Would you mind opening the PR? |
Also, as @geraldcombs pointed out (#762 (comment)) i see you have got multiple patches downstream in debian; would you mind upstreaming them? |
Hi. Would you mind doing the PR yourself? It's quite a bit of typing on
my end.
Thanks
|
Also, as @geraldcombs pointed out (#762 (comment)) i see you have got
multiple patches downstream in debian; would you mind upstreaming
them?
Absolutely. Please open PRs as needed.
We have
- fix-library-install-path.patch
Fixes library install paths. I don't know why it was set up the way it
was set up. If you want to be more "normal", you should take the patch
- properties-for-driver-event-schema.patch
The patch in this report
- specify-curl-library-correctly.patch
Probably not appropriate for you. In my builds nothing is bundled and
all libraries live in standard locations, so -lcurl works. There was
something broken about the CURL_LIBRARIES definition, which wasn't
worth the effor to fix for me
- use-shared-libelf.patch
The patch probably isn't appropriate for you as is. You can't link a
static library into a shared library, so if you're building a shared
libscap (or libsinsp), your dependencies all need to be shared. A
solution you should consider: remove all static library support from
your build system. Otherwise I guess you can look for libelf.so first,
and then libelf.a. You should test that if you do it that way.
|
Mmh you mean because we are using a subfolder for our libraries? It is not that uncommon as far as i know (eg:
This is 100% an issue :) Thank you! I am going to open the PR! |
Opened: #1215 |
Federico Di Pierro ***@***.***> writes:
* fix-library-install-path.patch
Fixes library install paths. I don't know why it was set up the way it
was set up. If you want to be more "normal", you should take the patch
Mmh you mean because we are using a subfolder for our libraries? It is
not that uncommon as far as i know (eg: pipewire installs its .so
under /usr/lib/pipewire-0.3/ ).
By necessity libraries are placed in subdirectories only if they will
never be loaded using the normal dynamic linking mechanism. Today we
have this:
***@***.***:~$ objdump -p /usr/bin/sysdig | grep scap
NEEDED libscap_event_schema.so.0
So if I run "sysdig" it will need to find "libscap_event_schema.so.0".
The list of search paths includes "/usr/lib" and "/usr/lib/ARCH" but not
"/usr/lib/falco". So by putting your libraries into a weird place, you
either broke sysdig, or you had to do extra work for sysdig to find your
libraries.
For Debian, this patch makes sense. I think it also makes sense for
everyone else, but you can decide.
|
Hello. There's a bug in the build system: DSO tags for
libscap-event-schema.so
are set twice, but never forlibdriver-event-schema.so
. There should be one for each. I'm the Debian maintainer, and I just fixed this for the distro:https://salsa.debian.org/debian/falcosecurity-libs/-/blob/master/debian/patches/properties-for-driver-event-schema.patch
I think you should take the patch.
Thanks
The text was updated successfully, but these errors were encountered: