From ueno at gnu.org  Thu Aug 15 09:39:40 2024
From: ueno at gnu.org (Daiki Ueno)
Date: Thu, 15 Aug 2024 16:39:40 +0900
Subject: [gnutls-help] gnutls 3.8.7
Message-ID: <874j7m44lf.fsf-ueno@gnu.org>

Hello,

We have just released gnutls-3.8.7. This is a bug fix and enhancement
release on the 3.8.x branch.

We would like to thank everyone who contributed in this release:
Alexander Sosedkin, Andreas Metzler, Zoltan Fridrich, and Daiki Ueno.

The detailed list of changes follows:

* Version 3.8.7 (released 2024-08-15)

** libgnutls: New configure option to compile out DSA support
   The --disable-dsa configure option has been added to completely disable DSA
   algorithm support.

** libgnutls: Experimental support for X25519Kyber768Draft00 key exchange in TLS
   For testing purposes, the hybrid post-quantum key exchange defined
   in draft-tls-westerbaan-xyber768d00 has been implemented using
   liboqs. Since the algorithm is still not finalized, the support of
   this key exchange is disabled by default and can be enabled with
   the --with-liboqs configure option.

** API and ABI modifications:
No changes since last version.


Getting the Software
================

GnuTLS may be downloaded directly from
https://www.gnupg.org/ftp/gcrypt/
A list of GnuTLS mirrors can be found at
http://www.gnutls.org/download.html

Here are the XZ compressed sources:
https://www.gnupg.org/ftp/gcrypt/gnutls/v3.8/gnutls-3.8.7.tar.xz

Here are OpenPGP detached signatures signed using key:
5D46CB0F763405A7053556F47A75A648B3F9220C
https://www.gnupg.org/ftp/gcrypt/gnutls/v3.8/gnutls-3.8.7.tar.xz.sig

Note that it has been signed with my openpgp key:
pub   rsa4096 2009-07-23 [SC] [expires: 2026-06-29]
      462225C3B46F34879FC8496CD605848ED7E69871
uid           [ultimate] Daiki Ueno <ueno at unixuser.org>
uid           [ultimate] Daiki Ueno <ueno at gnu.org>
sub   rsa4096 2010-02-04 [E]

Regards,
-- 
Daiki Ueno
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20240815/f76791c3/attachment.sig>

From ametzler at bebt.de  Thu Aug 15 10:51:52 2024
From: ametzler at bebt.de (Andreas Metzler)
Date: Thu, 15 Aug 2024 10:51:52 +0200
Subject: [gnutls-help] gnutls 3.8.7
In-Reply-To: <874j7m44lf.fsf-ueno@gnu.org>
References: <874j7m44lf.fsf-ueno@gnu.org>
Message-ID: <Zr3BqKtwLP65Aww3@argenau.bebt.de>

On 2024-08-15 Daiki Ueno <ueno at gnu.org> wrote:
> Hello,

> We have just released gnutls-3.8.7. This is a bug fix and enhancement
> release on the 3.8.x branch.
[...]

Hello,

the translation-update step seems to have gone wrong, po/ is essentially
empty.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From ueno at gnu.org  Thu Aug 15 12:28:52 2024
From: ueno at gnu.org (Daiki Ueno)
Date: Thu, 15 Aug 2024 19:28:52 +0900
Subject: [gnutls-help] gnutls 3.8.7
In-Reply-To: <Zr3BqKtwLP65Aww3@argenau.bebt.de> (Andreas Metzler's message of
 "Thu, 15 Aug 2024 10:51:52 +0200")
References: <874j7m44lf.fsf-ueno@gnu.org> <Zr3BqKtwLP65Aww3@argenau.bebt.de>
Message-ID: <87zfpe2i6z.fsf-ueno@gnu.org>

Hello,

Andreas Metzler <ametzler at bebt.de> writes:

> On 2024-08-15 Daiki Ueno <ueno at gnu.org> wrote:
>> Hello,
>
>> We have just released gnutls-3.8.7. This is a bug fix and enhancement
>> release on the 3.8.x branch.
> [...]
>
> Hello,
>
> the translation-update step seems to have gone wrong, po/ is essentially
> empty.

Sorry about that; I mistakenly ran bootstrap with --skip-po when
creating the distribution tarball.

I have regenerated and uploaded gnutls-3.8.7.1.tar.xz with po/ at:
https://www.gnupg.org/ftp/gcrypt/gnutls/v3.8/gnutls-3.8.7.1.tar.xz
https://www.gnupg.org/ftp/gcrypt/gnutls/v3.8/gnutls-3.8.7.1.tar.xz.sig

signed with the same key:
pub   rsa4096 2009-07-23 [SC] [expires: 2026-06-29]
      462225C3B46F34879FC8496CD605848ED7E69871
uid           [ultimate] Daiki Ueno <ueno at unixuser.org>
uid           [ultimate] Daiki Ueno <ueno at gnu.org>
sub   rsa4096 2010-02-04 [E]

Regards,
-- 
Daiki Ueno
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20240815/d5a185bc/attachment.sig>

From andyrtr at archlinux.org  Thu Aug 15 17:58:56 2024
From: andyrtr at archlinux.org (Andreas Radke)
Date: Thu, 15 Aug 2024 17:58:56 +0200
Subject: [gnutls-help] gnutls 3.8.7
In-Reply-To: <874j7m44lf.fsf-ueno@gnu.org>
References: <874j7m44lf.fsf-ueno@gnu.org>
Message-ID: <20240815175856.40406edd@workstation64.local>

This new release shows a new test failure when building for Arch Linux:

FAIL: ocsp-tests/ocsp-must-staple-connection.sh
============================================================================
Testsuite summary for GnuTLS 3.8.7
============================================================================
# TOTAL: 501
# PASS:  455
# SKIP:  45
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0


I'm attaching the test-suite.log. Is this a new test and failure
expected when building in a fakeroot chroot for packaging?

-Andy
Arch Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-suite.log
Type: text/x-log
Size: 18685 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20240815/04dabc52/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: Digitale Signatur von OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20240815/04dabc52/attachment-0001.sig>

From ametzler at bebt.de  Thu Aug 15 18:22:15 2024
From: ametzler at bebt.de (Andreas Metzler)
Date: Thu, 15 Aug 2024 18:22:15 +0200
Subject: [gnutls-help] gnutls 3.8.7
In-Reply-To: <20240815175856.40406edd@workstation64.local>
References: <874j7m44lf.fsf-ueno@gnu.org>
 <20240815175856.40406edd@workstation64.local>
Message-ID: <Zr4rNzXt0emNLkvf@argenau.bebt.de>

On 2024-08-15 Andreas Radke <andyrtr at archlinux.org> wrote:
> This new release shows a new test failure when building for Arch Linux:

> FAIL: ocsp-tests/ocsp-must-staple-connection.sh
[...]

Hello,

Sorry, my fault. This should fix it:
https://gitlab.com/gnutls/gnutls/-/merge_requests/1866/diffs?commit_id=f3e8eac0586a19f4dafd89f68006a536b826e65a

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From lists at schamschula.com  Thu Aug 15 19:22:24 2024
From: lists at schamschula.com (Marius Schamschula)
Date: Thu, 15 Aug 2024 12:22:24 -0500
Subject: [gnutls-help] gnutls 3.8.7
In-Reply-To: <Zr4rNzXt0emNLkvf@argenau.bebt.de>
References: <874j7m44lf.fsf-ueno@gnu.org>
 <20240815175856.40406edd@workstation64.local>
 <Zr4rNzXt0emNLkvf@argenau.bebt.de>
Message-ID: <17C6442C-CCC9-4A3D-BA7F-5478C818EE1E@schamschula.com>

Under MacPorts, I also saw a second test failure:

========================================
   GnuTLS 3.8.7: tests/test-suite.log
========================================

# TOTAL: 499
# PASS:  437
# SKIP:  60
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0

FAIL: gnutls-cli-debug
======================

Checking output of gnutls-cli-debug for TLS1.1 and TLS1.2 server
reserved port 17888
Failure: gnutls-cli-debug run should have succeeded!
unreserved port 17888
FAIL gnutls-cli-debug.sh (exit status: 1)

Further I noticed that under version 3.8.7/3.8.7.1 --without-brotli and --without-zstd are ignored. CI threw the following errors on all but Sonoma/arm_64 (which happens to be my test build machine):

libtool: compile:  /usr/bin/clang -DHAVE_CONFIG_H -I. -I.. -DLOCALEDIR=\"/opt/local/share/locale\" -I./../gl -I./../gl -I./includes -I./x509 -I./includes -I./includes -I./x509 -I/opt/local/include/p11-kit-1 -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -Wtype-limits -Wall -Wbad-function-cast -Wdate-time -Wdisabled-optimization -Wdouble-promotion -Wextra -Winit-self -Winvalid-pch -Wmissing-declarations -Wmissing-include-dirs -Wmissing-prototypes -Wnested-externs -Wnull-dereference -Wold-style-definition -Wpacked -Wpointer-arith -Wshadow -Wstrict-prototypes -Wuninitialized -Wunknown-pragmas -Wvariadic-macros -Wwrite-strings -Wformat=2 -Wno-missing-field-initializers -Wno-unused-parameter -fdiagnostics-show-option -fno-builtin-strcmp -I/opt/local/include/p11-kit-1 -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -arch arm64 -c tls13/encrypted_extensions.c  -fno-common -DPIC -o tls13/.libs/encrypted_extensions.o
In file included from dlwrap/zstd.c:12:
dlwrap/zstd.h:11:10: error: 'zstd.h' file not found with <angled> include; use "quotes" instead
#include <zstd.h>
         ^~~~~~~~
         "zstd.h"
In file included from dlwrap/brotlienc.c:12:
dlwrap/brotlienc.h:11:10: fatal error: 'brotli/encode.h' file not found
#include <brotli/encode.h>
         ^~~~~~~~~~~~~~~~~
11 error generated.
 error generated.
make[4]: *** [dlwrap/brotlienc.lo] Error 1
make[4]: *** Waiting for unfinished jobs....
make[4]: *** [dlwrap/zstd.lo] Error 1
In file included from dlwrap/brotlidec.c:12:
dlwrap/brotlidec.h:11:10: fatal error: 'brotli/decode.h' file not found
#include <brotli/decode.h>
         ^~~~~~~~~~~~~~~~~
1 error generated.
make[4]: *** [dlwrap/brotlidec.lo] Error 1

I did not see this build issue in previous versions of gnutls 3.8.x.

brotli had been offered as a variant (but was disabled by default), and zstd had been broken. I went ahead and enabled both, and CI built cleanly on all platforms

Marius
--
Marius Schamschula




> On Aug 15, 2024, at 11:22?AM, Andreas Metzler <ametzler at bebt.de> wrote:
> 
> On 2024-08-15 Andreas Radke <andyrtr at archlinux.org> wrote:
>> This new release shows a new test failure when building for Arch Linux:
> 
>> FAIL: ocsp-tests/ocsp-must-staple-connection.sh
> [...]
> 
> Hello,
> 
> Sorry, my fault. This should fix it:
> https://gitlab.com/gnutls/gnutls/-/merge_requests/1866/diffs?commit_id=f3e8eac0586a19f4dafd89f68006a536b826e65a
> 
> cu Andreas
> -- 
> `What a good friend you are to him, Dr. Maturin. His other friends are
> so grateful to you.'
> `I sew his ears on from time to time, sure'
> 
> _______________________________________________
> Gnutls-help mailing list
> Gnutls-help at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-help
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20240815/ed747210/attachment.html>

From ueno at gnu.org  Fri Aug 16 02:58:11 2024
From: ueno at gnu.org (Daiki Ueno)
Date: Fri, 16 Aug 2024 09:58:11 +0900
Subject: [gnutls-help] gnutls 3.8.7
In-Reply-To: <17C6442C-CCC9-4A3D-BA7F-5478C818EE1E@schamschula.com> (Marius
 Schamschula's message of "Thu, 15 Aug 2024 12:22:24 -0500")
References: <874j7m44lf.fsf-ueno@gnu.org>
 <20240815175856.40406edd@workstation64.local>
 <Zr4rNzXt0emNLkvf@argenau.bebt.de>
 <17C6442C-CCC9-4A3D-BA7F-5478C818EE1E@schamschula.com>
Message-ID: <877cchp9lo.fsf-ueno@gnu.org>

Hello,

Thank you for reporting those issues.

Marius Schamschula <lists at schamschula.com> writes:

> Under MacPorts, I also saw a second test failure:
[...]
> FAIL: gnutls-cli-debug
> ======================
>
> Checking output of gnutls-cli-debug for TLS1.1 and TLS1.2 server
> reserved port 17888
> Failure: gnutls-cli-debug run should have succeeded!
> unreserved port 17888
> FAIL gnutls-cli-debug.sh (exit status: 1)

I have no idea about this off-hand, as it passes on our macOS CI on
GitHub:
https://github.com/gnutls/gnutls/actions/runs/10407305734/job/28822285107

> Further I noticed that under version 3.8.7/3.8.7.1 --without-brotli and --without-zstd
> are ignored. CI threw the following errors on all but Sonoma/arm_64 (which happens
> to be my test build machine):

Yeah, this is indeed a bug.  The first commit of this MR should fix it:
https://gitlab.com/gnutls/gnutls/-/merge_requests/1867

Regards,
-- 
Daiki Ueno


From ametzler at bebt.de  Fri Aug 16 18:28:50 2024
From: ametzler at bebt.de (Andreas Metzler)
Date: Fri, 16 Aug 2024 18:28:50 +0200
Subject: [gnutls-help] How about some AC_MSG for dlopen?
Message-ID: <Zr9-QphUZT6obn6v@argenau.bebt.de>

Hello,

./configure is quiet about whether dlopening librariers is supported,
would it make sense to a) add messages and perhaps b) provide a switch
to force use of linking instead?

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From ueno at gnu.org  Sat Aug 17 07:10:27 2024
From: ueno at gnu.org (Daiki Ueno)
Date: Sat, 17 Aug 2024 14:10:27 +0900
Subject: [gnutls-help] How about some AC_MSG for dlopen?
In-Reply-To: <Zr9-QphUZT6obn6v@argenau.bebt.de> (Andreas Metzler's message of
 "Fri, 16 Aug 2024 18:28:50 +0200")
References: <Zr9-QphUZT6obn6v@argenau.bebt.de>
Message-ID: <8734n3ybss.fsf-ueno@gnu.org>

Andreas Metzler <ametzler at bebt.de> writes:

> ./configure is quiet about whether dlopening librariers is supported,
> would it make sense to a) add messages and perhaps b) provide a switch
> to force use of linking instead?

That sounds sensible to me, though I'm not sure what it is like a good
interface for (b).  Maybe --with-zstd, etc., could take a tri-state
argument (no/yes/[dlopen]) and if "yes", the library is linked at build
time?

Regards,
-- 
Daiki Ueno


From ametzler at bebt.de  Sat Aug 17 18:23:14 2024
From: ametzler at bebt.de (Andreas Metzler)
Date: Sat, 17 Aug 2024 18:23:14 +0200
Subject: [gnutls-help] How about some AC_MSG for dlopen?
In-Reply-To: <8734n3ybss.fsf-ueno@gnu.org>
References: <Zr9-QphUZT6obn6v@argenau.bebt.de>
 <8734n3ybss.fsf-ueno@gnu.org>
Message-ID: <ZsDOcjMvIYuP3lqY@argenau.bebt.de>

On 2024-08-17 Daiki Ueno <ueno at gnu.org> wrote:
> Andreas Metzler <ametzler at bebt.de> writes:

> > ./configure is quiet about whether dlopening librariers is supported,
> > would it make sense to a) add messages and perhaps b) provide a switch
> > to force use of linking instead?

> That sounds sensible to me, though I'm not sure what it is like a good
> interface for (b).  Maybe --with-zstd, etc., could take a tri-state
> argument (no/yes/[dlopen]) and if "yes", the library is linked at build
> time?

Hello,

I think it would need to be 4-state,  [dlopen / link / yes (which
prefers dlopen but does not require it) / no].

Alternatively a global setting could be used.

AC_ARG_ENABLE ([dlopen],
  [AS_HELP_STRING([--disable-dlopen],
    [link against instead of dlopening some helper libraries]),
  [ac_dlopen=$withval], [ac_dlopen=no])

I do not have a strong preference. I can try to come up with a patch
once a choice has been made.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From ueno at gnu.org  Mon Aug 19 03:54:38 2024
From: ueno at gnu.org (Daiki Ueno)
Date: Mon, 19 Aug 2024 10:54:38 +0900
Subject: [gnutls-help] How about some AC_MSG for dlopen?
In-Reply-To: <ZsDOcjMvIYuP3lqY@argenau.bebt.de> (Andreas Metzler's message of
 "Sat, 17 Aug 2024 18:23:14 +0200")
References: <Zr9-QphUZT6obn6v@argenau.bebt.de> <8734n3ybss.fsf-ueno@gnu.org>
 <ZsDOcjMvIYuP3lqY@argenau.bebt.de>
Message-ID: <87bk1pqntt.fsf-ueno@gnu.org>

Andreas Metzler <ametzler at bebt.de> writes:

> On 2024-08-17 Daiki Ueno <ueno at gnu.org> wrote:
>> Andreas Metzler <ametzler at bebt.de> writes:
>
>> > ./configure is quiet about whether dlopening librariers is supported,
>> > would it make sense to a) add messages and perhaps b) provide a switch
>> > to force use of linking instead?
>
>> That sounds sensible to me, though I'm not sure what it is like a good
>> interface for (b).  Maybe --with-zstd, etc., could take a tri-state
>> argument (no/yes/[dlopen]) and if "yes", the library is linked at build
>> time?
>
> I think it would need to be 4-state,  [dlopen / link / yes (which
> prefers dlopen but does not require it) / no].

Right, that sounds better.

> Alternatively a global setting could be used.
>
> AC_ARG_ENABLE ([dlopen],
>   [AS_HELP_STRING([--disable-dlopen],
>     [link against instead of dlopening some helper libraries]),
>   [ac_dlopen=$withval], [ac_dlopen=no])

I would prefer to have the option per library, because some of the
libraries are less likely to be available than the others (e.g.,
tpm2-tss vs. zlib).

> I do not have a strong preference. I can try to come up with a patch
> once a choice has been made.

That would be appreciated.

Regards,
-- 
Daiki Ueno


From ametzler at bebt.de  Tue Aug 20 13:48:49 2024
From: ametzler at bebt.de (Andreas Metzler)
Date: Tue, 20 Aug 2024 13:48:49 +0200
Subject: [gnutls-help] How about some AC_MSG for dlopen?
In-Reply-To: <87bk1pqntt.fsf-ueno@gnu.org>
References: <Zr9-QphUZT6obn6v@argenau.bebt.de> <8734n3ybss.fsf-ueno@gnu.org>
 <ZsDOcjMvIYuP3lqY@argenau.bebt.de> <87bk1pqntt.fsf-ueno@gnu.org>
Message-ID: <ZsSCoYIZRe99gfQO@argenau.bebt.de>

On 2024-08-19 Daiki Ueno <ueno at gnu.org> wrote:
> Andreas Metzler <ametzler at bebt.de> writes:
> > On 2024-08-17 Daiki Ueno <ueno at gnu.org> wrote:
> >> Andreas Metzler <ametzler at bebt.de> writes:

> >> > ./configure is quiet about whether dlopening librariers is supported,
> >> > would it make sense to a) add messages and perhaps b) provide a switch
> >> > to force use of linking instead?
[...]
> I would prefer to have the option per library, because some of the
> libraries are less likely to be available than the others (e.g.,
> tpm2-tss vs. zlib).
[...]

Hello,

Per-library quadstate ends up being rather wordy, see attached example
for handling zlib that way. I have thought about it but cannot see a
substantial abbreviation potential ad_hoc, there are 8 cases to handle.
- Do you want me follow-up, extending this approach to brotli/zstd/tpm?

The global switch is obviously simpler.

cu Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zlib-select-dlopen.diff
Type: text/x-diff
Size: 4043 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20240820/cf63f730/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: global_dlopen_yesno_option.diff
Type: text/x-diff
Size: 2243 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20240820/cf63f730/attachment-0001.diff>

From ueno at gnu.org  Wed Aug 21 02:49:11 2024
From: ueno at gnu.org (Daiki Ueno)
Date: Wed, 21 Aug 2024 09:49:11 +0900
Subject: [gnutls-help] How about some AC_MSG for dlopen?
In-Reply-To: <ZsSCoYIZRe99gfQO@argenau.bebt.de> (Andreas Metzler's message of
 "Tue, 20 Aug 2024 13:48:49 +0200")
References: <Zr9-QphUZT6obn6v@argenau.bebt.de> <8734n3ybss.fsf-ueno@gnu.org>
 <ZsDOcjMvIYuP3lqY@argenau.bebt.de> <87bk1pqntt.fsf-ueno@gnu.org>
 <ZsSCoYIZRe99gfQO@argenau.bebt.de>
Message-ID: <87r0aig0oo.fsf-ueno@gnu.org>

Andreas Metzler <ametzler at bebt.de> writes:

> On 2024-08-19 Daiki Ueno <ueno at gnu.org> wrote:
>> Andreas Metzler <ametzler at bebt.de> writes:
>> > On 2024-08-17 Daiki Ueno <ueno at gnu.org> wrote:
>> >> Andreas Metzler <ametzler at bebt.de> writes:
>
>> >> > ./configure is quiet about whether dlopening librariers is supported,
>> >> > would it make sense to a) add messages and perhaps b) provide a switch
>> >> > to force use of linking instead?
> [...]
>> I would prefer to have the option per library, because some of the
>> libraries are less likely to be available than the others (e.g.,
>> tpm2-tss vs. zlib).
> [...]
>
> Per-library quadstate ends up being rather wordy, see attached example
> for handling zlib that way. I have thought about it but cannot see a
> substantial abbreviation potential ad_hoc, there are 8 cases to handle.
> - Do you want me follow-up, extending this approach to brotli/zstd/tpm?

Thanks.  A couple of comments:

- It would be simpler to use AC_MSG_CHECKING/AC_MSG_RESULT for
  ENABLE_DLOPEN rather than AC_MSG_NOTICE
- Perhaps we could drop the non-pkgconfig detection logic for zlib, as
  the library supports pkgconfig since August 2006
- I would first normalize the argument for --with-*, something like:

  AC_ARG_WITH(zstd,
              AS_HELP_STRING([--without-zstd], [disable zstd compression support]),
              with_zstd=$withval, with_zstd=yes)

  AS_CASE([$with_zstd],
          [yes], [AM_COND_IF([ENABLE_DLOPEN], [with_zstd=dlopen], [with_zstd=link])],
          [dlopen], [AM_COND_IF([ENABLE_DLOPEN], [:], [AC_MSG_ERROR([[
  ***
  *** Unable to dlopen ZSTD, try --with-zstd=link.
  *** ]])])],
          [link], [:],
          [no], [:],
          [AC_MSG_ERROR([[Unknown argument $with_zstd for --with-zstd]])])

  So afterwards $with_zstd should only be dlopen, link, or no.

- Perhaps we might want to provide a autoconf macro or two for common
  tasks, in m4/hooks.m4, to avoid code duplication

Regards,
-- 
Daiki Ueno


From ametzler at bebt.de  Wed Aug 21 13:40:15 2024
From: ametzler at bebt.de (Andreas Metzler)
Date: Wed, 21 Aug 2024 13:40:15 +0200
Subject: [gnutls-help] How about some AC_MSG for dlopen?
In-Reply-To: <87r0aig0oo.fsf-ueno@gnu.org>
References: <Zr9-QphUZT6obn6v@argenau.bebt.de> <8734n3ybss.fsf-ueno@gnu.org>
 <ZsDOcjMvIYuP3lqY@argenau.bebt.de> <87bk1pqntt.fsf-ueno@gnu.org>
 <ZsSCoYIZRe99gfQO@argenau.bebt.de> <87r0aig0oo.fsf-ueno@gnu.org>
Message-ID: <ZsXSHyN3CvYfj1Rn@argenau.bebt.de>

On 2024-08-21 Daiki Ueno <ueno at gnu.org> wrote:
> Andreas Metzler <ametzler at bebt.de> writes:
[...]
>> Per-library quadstate ends up being rather wordy, see attached example
>> for handling zlib that way. I have thought about it but cannot see a
>> substantial abbreviation potential ad_hoc, there are 8 cases to handle.
>> - Do you want me follow-up, extending this approach to brotli/zstd/tpm?

> Thanks.  A couple of comments:
[...]
> - I would first normalize the argument for --with-*, something like:

>   AC_ARG_WITH(zstd,
>               AS_HELP_STRING([--without-zstd], [disable zstd compression support]),
>               with_zstd=$withval, with_zstd=yes)

>   AS_CASE([$with_zstd],
>           [yes], [AM_COND_IF([ENABLE_DLOPEN], [with_zstd=dlopen], [with_zstd=link])],
>           [dlopen], [AM_COND_IF([ENABLE_DLOPEN], [:], [AC_MSG_ERROR([[
>   ***
>   *** Unable to dlopen ZSTD, try --with-zstd=link.
>   *** ]])])],
>           [link], [:],
>           [no], [:],
>           [AC_MSG_ERROR([[Unknown argument $with_zstd for --with-zstd]])])

>   So afterwards $with_zstd should only be dlopen, link, or no.
[...]

Hello,

Thanks for the handholding, that helped quite a bit.

It is not quite that simple, I would expect
./configure --with-zstd
to abort with an error if zstd support cannot be enabled, i.e.
--with-zstd and not specifiying --with-zstd are not the same.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zlib-select-dlopen.v2.diff
Type: text/x-diff
Size: 4074 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnutls-help/attachments/20240821/109a27b5/attachment.diff>