Compatibility with mbedtls v3 broken?

[LigH-de]

I did this

compiling libcurl using mbedtls in an MSYS2/MinGW environment (media-autobuild suite) which is kept up-to-date each time before building ffmpeg and other tools failed:

relevant parts of curl-git/build-32bit/ab-suite.make.log from logs.zip

CPPFLAGS: -D_FORTIFY_SOURCE=0 -D__USE_MINGW_ANSI_STDIO=1 -DGNUTLS_INTERNAL_BUILD -DNGHTTP2_STATICLIB -DPSL_STATIC
CFLAGS: -mthreads -mtune=generic -O2 -pipe
CXXFLAGS: -mthreads -mtune=generic -O2 -pipe
LDFLAGS: -pipe -static-libgcc -static-libstdc++
make -j1 
Making all in lib

...

  CC       vtls/libcurl_la-mbedtls.lo
../../lib/vtls/mbedtls.c: In function 'mbed_connect_step2':
../../lib/vtls/mbedtls.c:818:43: error: 'ALPN_H2_LEN' undeclared (first use in this function); did you mean 'ALPN_H2_LENGTH'?
  818 |       if(!strncmp(next_protocol, ALPN_H2, ALPN_H2_LEN) &&
      |                                           ^~~~~~~~~~~
      |                                           ALPN_H2_LENGTH

I expected the following

libcurl compiling successfully

curl/libcurl version

https://github.com/curl/curl.git#tag=LATEST
curl-7_83_0 # 1669b17

operating system

MSYS2/MinGW on Windows

[LigH-de]

Possibly of interest: Mbed-TLS 3.0 migration guide

[bagder]

We build against mbedTLS 3.1.0 in our CI builds, which are still green as of the latest commit... ?

[LigH-de]

Then it might be related to mbedtls libraries shipped with MSYS2?

var/log/pacman.log:
[2022-04-21T12:02:14+0200] [ALPM] upgraded mingw-w64-x86_64-mbedtls (2.28.0-1 -> 3.1.0-1)

[bagder]

No, I think it is because the CI job we run isn't h2 enabled...

[LigH-de]

👍 Quick solution. Confirming it's solved also in MABS.