From: Stephen Hemminger <stephen@networkplumber.org>
To: "Stefan Mätje" <stefan.maetje@esd.eu>
Cc: David Ahern <dsahern@gmail.com>, netdev@vger.kernel.org
Subject: Re: [PATCH 0/2] iproute2: ss: clarify build warnings when building with libbpf 0.5.0
Date: Sun, 11 Aug 2024 16:25:52 -0700 [thread overview]
Message-ID: <20240811162552.75adee22@hermes.local> (raw)
In-Reply-To: <20240811223135.1173783-1-stefan.maetje@esd.eu>
On Mon, 12 Aug 2024 00:31:33 +0200
Stefan Mätje <stefan.maetje@esd.eu> wrote:
> Hi,
> when building current iproute2 source on Ubuntu 22.04 with libbpf0
> 0.5.0 installed, I stumbled over the warning "libbpf version 0.5 or
> later is required, ...". This prompted me to look closer having the
> version 0.5.0 installed which should suppress this warning.
> The warning lured me into the impression that building without
> warning should be possible using libbpf 0.5.0.
Why is using new iproute2 on 2 year old distro going to add
anything here? Especially when BPF has under gone breaking API changes
over the recent past.
>
> I found out that this warning came from ss.c where a conditional
> compile path depends on LIBBPF_MAJOR_VERSION and LIBBPF_MINOR_VERSION.
> Newer libbpf versions define these in libbpf_version.h but the library
> version 0.5.0 and earlier on Ubuntu and Debian don't package this header.
> The version 0.7.0 on Debian packages the header libbpf_version.h.
>
> Therefore these defines were undefined during the build and prompted
> the output of the warning message. I derived these version defines
> from the library version in the configure script and provided them
> via CFLAGS. This is the first patch.
>
> Now building ss.c against the libbpf 0.5.0 with ENABLE_BPF_SKSTORAGE_SUPPORT
> enabled, triggered compilation errors. The function btf_dump__new is
> used there with a calling convention that was introduced with libbpf
> version 0.6.0. Therefore ENABLE_BPF_SKSTORAGE_SUPPORT shall only be
> enabled for libbpf versions >= 0.6.0.
Might be better just to drop support for old libbpf and also
the legacy mode. Having multiple versions means there is more code
that doesn't get covered by tests.
Also, configure shell script is getting to be so messy, it is time for a redo.
Maybe give up on make and go to meson?
next prev parent reply other threads:[~2024-08-11 23:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-11 22:31 [PATCH 0/2] iproute2: ss: clarify build warnings when building with libbpf 0.5.0 Stefan Mätje
2024-08-11 22:31 ` [PATCH 1/2] configure: provide surrogates for possibly missing libbpf_version.h Stefan Mätje
2024-08-11 22:31 ` [PATCH 2/2] ss: fix libbpf version check for ENABLE_BPF_SKSTORAGE_SUPPORT Stefan Mätje
2024-08-11 23:25 ` Stephen Hemminger [this message]
2024-08-12 9:46 ` [PATCH 0/2] iproute2: ss: clarify build warnings when building with libbpf 0.5.0 Stefan Mätje
2024-08-15 15:30 ` patchwork-bot+netdevbpf
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=20240811162552.75adee22@hermes.local \
--to=stephen@networkplumber.org \
--cc=dsahern@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=stefan.maetje@esd.eu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.