DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: David Marchand <david.marchand@redhat.com>
Cc: <dev@dpdk.org>, Nicolas Chautru <nicolas.chautru@intel.com>,
	"Dariusz Sosnowski" <dsosnowski@nvidia.com>,
	Viacheslav Ovsiienko <viacheslavo@nvidia.com>,
	Bing Zhao <bingz@nvidia.com>, Ori Kam <orika@nvidia.com>,
	Suanming Mou <suanmingm@nvidia.com>,
	Matan Azrad <matan@nvidia.com>,
	Srikanth Yalavarthi <syalavarthi@marvell.com>,
	"Ciara Loftus" <ciara.loftus@intel.com>,
	Maryam Tahhan <mtahhan@redhat.com>,
	Long Li <longli@microsoft.com>, Wei Hu <weh@microsoft.com>,
	Anatoly Burakov <anatoly.burakov@intel.com>,
	David Hunt <david.hunt@intel.com>,
	"Sivaprasad Tummala" <sivaprasad.tummala@amd.com>,
	Rosen Xu <rosen.xu@altera.com>,
	"Tomasz Kantecki" <tomasz.kantecki@intel.com>,
	Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>,
	Tyler Retzlaff <roretzla@linux.microsoft.com>
Subject: Re: [PATCH v2] build: validate libraries returned from meson find function
Date: Thu, 2 Oct 2025 09:06:47 +0100	[thread overview]
Message-ID: <aN4yl66c5ftB_EpB@bricha3-mobl1.ger.corp.intel.com> (raw)
In-Reply-To: <CAJFAV8ztEthzEhjCYy-L0T98F7zb2qECG+2Cd0-HavPEBUQnAg@mail.gmail.com>

On Thu, Oct 02, 2025 at 09:53:15AM +0200, David Marchand wrote:
> Hello Bruce,
> 
> On Wed, 24 Sept 2025 at 13:13, Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > The meson find_library() API call sometimes finds a library that is
> > actually incompatible with the current build, for example, returning a
> > 64-bit library when doing a 32-bit build. To avoid problems with this,
> > check each library returned from a find_library() call and treat the
> > library as unfound if its incompatible.
> 
> meson should have all it needs to double check itself that the "found"
> library links fine...
> But well, we need to live with existing behavior.
> 

Yes, it's annoying and it should be something I think meson does, but even
if it was added today to meson, we'd have to live with current behaviour
for a long time. :-(

> It's a pity meson refuses to define user helpers... so much copy/paste
> in this patch.
> 

Yes, though if we want to reduce it I can remove some that is currently
unnecessary. For example, windows support doesn't have any cross-compile
options and only supports a single target so the checks there probably
aren't necessary. I added them for consistency.

The other thing we could do to help out here, is check to see if any more
libraries can be switched to using pkg-config. I noticed some libs have
fallbacks after a pkg-config call - we could remove the fallbacks and just
mandate use of pkg-config for those.

> 
> >
> > This checking is not necessary (or should not be necessary) for
> > dependencies got using pkg-config, since the .pc files for each build
> > type are stored in a different directory on the system.
> 
> Would it affect the library lookup if we pass has_headers to find_library()?
>

I don't think it would affect things, since the headers are common in many
cases, only the binary files differ (thinking especially of the 32-bit vs
64-bit case here).

/Bruce

  reply	other threads:[~2025-10-02  8:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-23 16:58 [PATCH] examples/l2fwd-cat: check compatibility of dependency lib Bruce Richardson
2025-09-24 10:54 ` [PATCH v2] build: validate libraries returned from meson find function Bruce Richardson
2025-10-02  7:53   ` David Marchand
2025-10-02  8:06     ` Bruce Richardson [this message]
2025-10-02 11:58       ` David Marchand
2025-10-02 11:54   ` David Marchand
2025-10-02 12:45     ` David Marchand

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=aN4yl66c5ftB_EpB@bricha3-mobl1.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=bingz@nvidia.com \
    --cc=ciara.loftus@intel.com \
    --cc=david.hunt@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=dmitry.kozliuk@gmail.com \
    --cc=dsosnowski@nvidia.com \
    --cc=longli@microsoft.com \
    --cc=matan@nvidia.com \
    --cc=mtahhan@redhat.com \
    --cc=nicolas.chautru@intel.com \
    --cc=orika@nvidia.com \
    --cc=roretzla@linux.microsoft.com \
    --cc=rosen.xu@altera.com \
    --cc=sivaprasad.tummala@amd.com \
    --cc=suanmingm@nvidia.com \
    --cc=syalavarthi@marvell.com \
    --cc=tomasz.kantecki@intel.com \
    --cc=viacheslavo@nvidia.com \
    --cc=weh@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;
as well as URLs for NNTP newsgroup(s).