On Thu, 2022-12-22 at 10:09 +0100, Martin Liška wrote:
> On 12/22/22 00:38, Mark Wielaard wrote:
> > Hi Martin,
> > 
> > On Wed, Dec 21, 2022 at 07:29:19PM +0100, Martin Liška wrote:
> > > > What goes wrong is that this debian old stable arm setup has
> > > > libzstd
> > > > containing a ZSTD_compressStream2 symbol...
> > > > 
> > > >     40: 0000d349   264 FUNC    GLOBAL DEFAULT   11
> > > > ZSTD_compressStream2
> > > > 
> > > > But the zstd.h header doesn't expose it...
> > > 
> > > Yeah, that's their way of how to move an API from "staging" into
> > > a stable state.
> > > It was changed in:
> > > https://github.com/facebook/zstd/commit/d7d89513d6a21
> > > 
> > > and so it's present in zstd since 1.4.0. Can we somehow specify
> > > library version
> > > in configure.ac?
> 
> Hi Mark.
> 
> > It isn't as nice, but since there seems to be a pkgconfig
> > libzstd.pc
> > you could use PKG_CHECK_MODULES. See for example how we check for
> > libcurl.
> 
> I can see it, however, it not easily addable to eu_ZIPLIB function :/
> I must confess,
> this autoconf machinery is always something that makes me crazy :)
> 
> Do you have an elegant way how to handle it?

Maybe we should simply split it from the "decompress" support. Trying
to make eu_ZIPLIB handle it means we also suddenly require a newer
libzstd for the simpler dwfl zstd file decompression support.

So lets keep the "normal" zstd detection in place and add something
like the attached (on top of your latest patch).

Cheers,

Mark