On Mon, Oct 23, 2023 at 11:40:14AM +0000, Srikanth Yalavarthi wrote:
> > -----Original Message-----
> > From: Bruce Richardson <bruce.richard...@intel.com>
> > Sent: 23 October 2023 14:56
> > To: Srikanth Yalavarthi <syalavar...@marvell.com>
> > Cc: Aaron Conole <acon...@redhat.com>; Igor Russkikh
> > <irussk...@marvell.com>; David Marchand <david.march...@redhat.com>;
> > dev@dpdk.org; Shivah Shankar Shankar Narayan Rao
> > <sshankarn...@marvell.com>; Jerin Jacob Kollanukkaran
> > <jer...@marvell.com>; sta...@dpdk.org
> > Subject: [EXT] Re: [PATCH 1/1] build: update link args and includes for
> > libarchive
> >
> > External Email
> >
> > ----------------------------------------------------------------------
> > On Fri, Oct 20, 2023 at 10:01:35AM -0700, Srikanth Yalavarthi wrote:
> > > In order to avoid linking with all libraries listed as Libs.private in
> > > libarchive.pc, libarchive is not added to ext_deps during meson setup.
> > >
> > > Since libarchive is not added to ext_deps, cross-compilation or native
> > > compilation with libarchive installed in non-standard location fails
> > > with errors related to "cannot find -larchive"
> > > or "archive.h: No such file or directory". In order to fix the build
> > > failures, user is required to define the 'c_args' and 'c_link_args'
> > > with '-I<includedir>' and '-L<libdir>'.
> > >
> > > This patch updates meson build files to add libarchive's includedir
> > > and libdir to compiler flags and would not require setting c_args and
> > > c_link_args externally.
> > >
> > > Fixes: 40edb9c0d36b ("eal: handle compressed firmware")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Srikanth Yalavarthi <syalavar...@marvell.com>
> > > ---
> >
> > Checking back through the mail archives I'm still a little unclear as to
> > what
> > breaks when we try using libarchive as any other package with a pkg-config
> > file? I would have thought the best solution was just to add libarchive as
> > an
> > external dependency, found using pkg-config, to EAL. When we add it as a
> > dependency, rather than using c/ldflags, we should get all this path fixup
> > for
> > free?
> > Can you clarify what breaks when we add libarchive as a libeal dependency
> > only?
>
> Below is my observation.
>
> In current implementation, we are looking for libarchive's availability
> through pkg-config.
> When found, we are setting RTE_HAS_LIBARCHIVE=1 and adding '-larchive' to
> ldflags.
>
> Since, we are not adding libarchive to ext_deps (to avoid linking with
> deps.private), the
This is the bit I'm a bit stuck on. What is the issues with adding
libarchive to ext_deps? For other libs, when doing static builds we have to
link with deps.private and it's the correct behaviour AFAIK. Not doing so
would surely lead to problematic builds, no?
/Bruce
