Re: more bogus meson warnings

[Peter Maydell]

On Wed, 3 Nov 2021 at 13:38, Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 11/3/21 13:19, Peter Maydell wrote:
> > They're two tests under the hood, but they both need to pass
> > for us to be able to use the feature. If they don't both pass,
> > then meson should just quietly say "OK, we don't have this thing"
> > (ie it could print a "Something or other: NO" line, but it should
> > not be printing a "WARNING" line).
>
> Of course it's possible to downgrade the warning line, but I'd rather
> first be sure that the warning is bogus.  If you _do_ have a header and
> static library, but somehow it cannot be used to link the test program,
> it would be correct to warn.

I don't really agree. There are lots and lots of things that
might put the user's system somewhere between "there is no
evidence of libfoo here at all" and "there is a working libfoo
we can use". We don't in general try to diagnose any of those,
we just say "no libfoo, move on".

> Unlike the configure script, Meson does
> have code to distinguish static vs shared libraries, so the compile test
> should be unnecessary; I would like to understand what causes it to
> fail, so that your system says "Library snappy found: YES" (and warns),
> whereas mine says "no".  I can check that using config-host.mak and
> meson-logs/meson-log.txt.

https://people.linaro.org/~peter.maydell/meson-log.txt
https://people.linaro.org/~peter.maydell/config-host.mak

The link of the test program against libsnappy.a fails because
it is being linked with cc and nothing is putting the C++ stdlib
that libsnappy needs on the link line, so you get errors like:

 
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libsnappy.a(snappy.cc.o):
In function `snappy::internal::WorkingMemory::GetHashTable(unsigned
long, int*)':
(.text+0x15b): undefined reference to `operator new[](unsigned long)'

This is (I suspect) another example of "distro does ship a
static .a file, but the shipped pkg-config file is only good for
dynamic linking, doesn't work for static linking". There's generally
nothing much the user can do about this, beyond file a bug report with
the distro if they're feeling enthusiastic.
("pkg-config --static --libs snappy" just outputs "-lsnappy".)

Note that Debian/Ubuntu pretty much always ships the .a
file in the libfoo-dev package, so "there's a .a file on the
disk but the pkg-config might or might not work" is pretty
common.

-- PMM