From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: Francis Laniel <flaniel@linux.microsoft.com>
Cc: buildroot@buildroot.org
Subject: Re: [Buildroot] [RFC PATCH v2 0/3] Bump sysdig and falco libs
Date: Sun, 13 Aug 2023 09:34:05 +0200 [thread overview]
Message-ID: <20230813073405.GU421096@scaer> (raw)
In-Reply-To: <20230811152710.43564-1-flaniel@linux.microsoft.com>
Francis, All,
On 2023-08-11 17:27 +0200, Francis Laniel spake thusly:
> With this contribution, I bumped sysdig and falcosecurity-libs.
> Sadly, I am not fully satisfied with the result, hence the fact I marked it as
> RFC because I would like to get your feedback to make it better.
>
> First of all, sysdig builds and runs:
> Welcome to Buildroot
> buildroot login: root
> # sysdig --version
> sysdig version 0.31.4
> # sysdig | head
> scap: loading out-of-tree module taints kernel.
> scap: driver loading, scap
> scap: adding new consumer (____ptrval____)
> scap: initializing ring buffer for CPU 0
> scap: CPU buffer initialized, size=8388608
> 26 15:12:28.226519423 0 sysdig (108) > switch next=0 pgft_maj=10 pgft_min=1348 vm_size=47288 vm_rss=19408 vm_swap=0
> 27 15:12:28.227409149 0 <NA> (0) > switch next=13 pgft_maj=0 pgft_min=0 vm_size=0 vm_rss=0 vm_swap=0
> ...
>
> Nonetheless, I had to increase the minimal size of the image as libsinsp.a is
> quite big:
> # du -sh /sysdig/libsinsp.a
> 171.4M /sysdig/libsinsp.a
> I am not forcefully sure where this library is used, I will investigate and
> maybe we can run everything without it.
There is no need to have static libs (.a files) on the target, as static
libs are only used at linking phase, which happens on the build machine.
So, unless sysdig embeds a linker and generates an executalbe from
those, it should be safe to remove.
> Secondly, I had to tweak heavily the libscap CMakeLists.txt to install several
> shared libraries.
> Indeed, the libraries are compiled as static, but the sysdig binary is not
> static, so it needs plenty of shared libraries to be run from the image.
> I am not really sure what is the best solution here (either compiling sysdig as
> static or not), but in any case my patch for CMakeLists.txt is not really clean.
I don't quite understand this part.
If the libraries are present as static libs at build time, then sysdig
would be statically linked to those, even if sysdig is not itself a
statically linked binary.
Indeed, it's possible to have, say;
ld libfoo.a libbar.so main.o -o myprogram
where myprogram would then be a dynamically linked executable,, which
would have been linked with libfoo.a and dynamically linked with
libbar.so.
So you'll have to expand a bit on that part...
Ah, I think I understand what you are trying to say: falcosecurity-libs
build libscap.a and does not install it, but sysdig needs to link
against it, right?
If so, then it has nothing to do with the fact that sysdig is not
static, but just about the fact that sysdig needs to link with those
libraries.
I'll also further reply to the sysdig bump...
> Finally, I had to modify the magical number in falcosecurity-libs.mk for
> API_VERSION and SCHEMA_VERSION.
> While this is not really a big pain, I am wondering if this is not possible to
> read the corresponding values from the corresponding files (i.e. API_VERSION and
> SCHEMA_VERSION).
> So, for future update we would not need to take care of it ourselves.
That is what I was going to suggest while reviewing patch 1/3. I'll
reply further there.
Regards,
Yann E. MORIN.
> Changes since:
> v1:
> * Removed everything regarding VALIJSON in sysdig.mk.
> * Bumped first falcosecurity-libs to avoid problem when building it.
> * Added runtime test for sysdig.
>
> Francis Laniel (3):
> package/falcosecurity-libs: bump to version 0.10.5
> package/sysdig: bump to version 0.31.4
> support/testing/package: add new test for sysdig
>
> .../0002-cmake-Install-shared-libraries.patch | 61 +++++++++++++++++++
> .../falcosecurity-libs.hash | 2 +-
> .../falcosecurity-libs/falcosecurity-libs.mk | 10 +--
> package/sysdig/sysdig.hash | 2 +-
> package/sysdig/sysdig.mk | 9 ++-
> .../testing/tests/package/test_sysdig.config | 1 +
> support/testing/tests/package/test_sysdig.py | 46 ++++++++++++++
> 7 files changed, 122 insertions(+), 9 deletions(-)
> create mode 100644 package/falcosecurity-libs/0002-cmake-Install-shared-libraries.patch
> create mode 100644 support/testing/tests/package/test_sysdig.config
> create mode 100644 support/testing/tests/package/test_sysdig.py
>
> --
> 2.34.1
>
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
prev parent reply other threads:[~2023-08-13 7:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-11 15:27 [Buildroot] [RFC PATCH v2 0/3] Bump sysdig and falco libs Francis Laniel
2023-08-11 15:27 ` [Buildroot] [RFC PATCH v2 1/3] package/falcosecurity-libs: bump to version 0.10.5 Francis Laniel
2023-08-13 7:52 ` Yann E. MORIN
2023-08-11 15:27 ` [Buildroot] [RFC PATCH v2 2/3] package/sysdig: bump to version 0.31.4 Francis Laniel
2023-08-13 7:59 ` Yann E. MORIN
2023-08-11 15:27 ` [Buildroot] [RFC PATCH v2 3/3] support/testing/package: add new test for sysdig Francis Laniel
2023-08-13 7:34 ` Yann E. MORIN [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230813073405.GU421096@scaer \
--to=yann.morin.1998@free.fr \
--cc=buildroot@buildroot.org \
--cc=flaniel@linux.microsoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox