s2n-tls: add wrap for v1.5.24

[apache-hb]

Adds a wrap for Amazon S2N version 1.5.24

elliothb@ELLIOT-SERVER:~/github/wrapdb$ meson setup builddir -Dwraps=s2n-tls
The Meson build system
Version: 1.8.2
Source dir: /home/elliothb/github/wrapdb
Build dir: /home/elliothb/github/wrapdb/builddir
Build type: native build
Project name: wrapdb
Project version: undefined
Host machine cpu family: x86_64
Host machine cpu: x86_64
Using s2n-tls source from cache.

Executing subproject s2n-tls 

s2n-tls| Project name: s2n-tls
s2n-tls| Project version: 1.5.24
s2n-tls| C compiler for the host machine: cc (clang 21.0.0 "clang version 21.0.0git (https://github.com/apache-hb/llvm-project 59613ac2371badc5ada8ddb17446a985ec1eca9a)")
s2n-tls| C linker for the host machine: cc ld.bfd 2.44.50.20250511
s2n-tls| Found pkg-config: YES (/usr/bin/pkg-config) 1.8.0
s2n-tls| Run-time dependency libcrypto found: YES 3.0.2
s2n-tls| Run-time dependency threads found: YES
s2n-tls| Library m found: YES
s2n-tls| Compiler for C supports arguments -Wno-strict-prototypes: YES
s2n-tls| Compiler for C supports arguments -Wno-unused-parameter: YES
s2n-tls| Compiler for C supports arguments -Wno-deprecated-declarations: YES
s2n-tls| Build targets in project: 1
s2n-tls| Subproject s2n-tls finished.

Build targets in project: 2

wrapdb undefined

  Subprojects
    s2n-tls: YES

  User defined options
    wraps  : s2n-tls

Found ninja-1.10.1 at /usr/bin/ninja
elliothb@ELLIOT-SERVER:~/github/wrapdb$ meson compile -C builddir                           
INFO: autodetecting backend as ninja
INFO: calculating backend command to run: /usr/bin/ninja -C /home/elliothb/github/wrapdb/builddir
ninja: Entering directory `/home/elliothb/github/wrapdb/builddir'
[174/174] Linking target subprojects/s2n-tls-1.5.24/libs2n.so

[apache-hb]

S2N doesn't support windows, and the alpine sanity check is failing because the openssl wrap also doesn't work on alpine

[eli-schwartz]

Install the openssl development headers in the CI config for this wrap, then!

[apache-hb]

Annoying that the msys2 and windows builds still show as failed despite disabling them in ci_config.json :(

[neheb]

Correct. You're supposed to add an unsupported message for windows.

[neheb]

ERROR: C shared or static library 'm' not found

should be optional, no?

[eli-schwartz]

Definitely if you intend to support Windows, yes. math.h exists but the library provider is built-in rather than being an external libm.a or libm.so

There are some Unix systems where it's built-in as well, but those generally provide a stub libm.a to satisfy the posix requirement that "the -lm argument to the compiler shall be accepted, and if passed, the linked program will have access to the math symbols" (which technically doesn't require a disk file to exist, but then the compiler will have to special case the argument).

[apache-hb]

Third times the charm

[bgilbert]

It's not required, but if upstream has some basic self-tests that could be added as Meson tests, that'd be good. (Especially for a crypto library.)

[bgilbert]

It's potentially clearer to move build directives for subdirectories into subdirectory meson.build files, but that isn't required.

[apache-hb]

@eli-schwartz Any blockers for merging this changeset?

[eli-schwartz]

Haven't looked closely (yet) but that is a suspiciously large number of commits, some of which definitely roll back changes made earlier in this patch series. Please squash commits.