[PATCH v2] build: drop dependency on libbsd

[David Marchand]

On Mon, 29 Jun 2026 at 13:52, Bruce Richardson
<bruce.richardson at intel.com> wrote:
>
> On Mon, Jun 29, 2026 at 01:30:32PM +0200, David Marchand wrote:
> > On Thu, 25 Jun 2026 at 15:08, Bruce Richardson
> > <bruce.richardson at intel.com> wrote:
> > >
> > > Glibc added the strlcpy and strlcat functions to version 2.38, released
> > > in 2023, meaning they are natively available in modern linux distros. At
> > > this point, the value of having the libbsd provided versions of these
> > > functions is reduced, so let's simplify the code options here by
> > > providing just two options for strlcpy rather than three:
> > >
> > > 1. native implementation for BSD and recent Linux
> > > 2. DPDK-specific fallbacks using snprintf
> > >
> > > Since the strlcpy and strlcat functions are the only two items used from
> > > libbsd, we can then drop completely any DPDK dependency on libbsd.
> > >
> > > Signed-off-by: Bruce Richardson <bruce.richardson at intel.com>
> > >
> > > ---
> > > V2:
> > > * took the work further than v1, dropping libbsd dependency entirely.
> > >   Now DPDK just supports native strlcpy or it's own fallback version.
> >
> > We still have some references:
> >
> > $ git grep -i libbsd
> > .github/workflows/build.yml:        libbsd-dev \
> > .github/workflows/build.yml:        libbsd-devel \
> > devtools/process-iwyu.py:def uses_libbsd(builddir):
> > devtools/process-iwyu.py:    "return whether the build uses libbsd or not"
> > devtools/process-iwyu.py:    return bool(get_build_config(builddir,
> > lambda ln: 'RTE_USE_LIBBSD' in ln))
> > devtools/process-iwyu.py:    keep_str_fns = uses_libbsd(build_dir)  #
> > check for libbsd
> > devtools/process-iwyu.py:        print("Warning: libbsd is present,
> > build will fail to detect incorrect removal of rte_string_fns.h",
> > doc/guides/howto/af_xdp_dp.rst:          libbsd-devel \
> >
>
> Sure, will respin and try and clean these up a bit. I assume from the
> detailed feedback that there is no issue with the high-level approach here?

Consumers of dpdk may have been relying on the libbsd dependency (and
RTE_USE_LIBBSD config...) but I think we should proceed with this
removal.

https://xkcd.com/1172/


-- 
David Marchand