[EXT] Re: [PATCH 1/1] build: update link args and includes for libarchive

[Bruce Richardson]

On Mon, Oct 23, 2023 at 11:40:14AM +0000, Srikanth Yalavarthi wrote:
> > -----Original Message-----
> > From: Bruce Richardson <bruce.richardson at intel.com>
> > Sent: 23 October 2023 14:56
> > To: Srikanth Yalavarthi <syalavarthi at marvell.com>
> > Cc: Aaron Conole <aconole at redhat.com>; Igor Russkikh
> > <irusskikh at marvell.com>; David Marchand <david.marchand at redhat.com>;
> > dev at dpdk.org; Shivah Shankar Shankar Narayan Rao
> > <sshankarnara at marvell.com>; Jerin Jacob Kollanukkaran
> > <jerinj at marvell.com>; stable at 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: stable at dpdk.org
> > >
> > > Signed-off-by: Srikanth Yalavarthi <syalavarthi at 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