Le 1 août 2019 à 10:07, Willy Tarreau <w...@1wt.eu
> a écrit :
On Travis CI there was a fairly recent regression on BoringSSL which
happened between 03e09f3 and a7a0f99 a day ago. It breaks on definition
of EVP_PKEY_base_id() in openssl-compat.h, which was not modified, and
I guess this issue was hidden by the simultaneous breakage of libressl
by latest changes.
It looks like latest BoringSSL now defines this function and that the
definition above could be removed. Could you please have a look when
you have a moment and possibly propose a patch so that we can fix those
build reports (especially if you find that other places need to be
For reference, first breakage : https://travis-ci.com/haproxy/haproxy/builds/121281529
Last known good build: https://travis-ci.com/haproxy/haproxy/builds/121258130
Yep, i already built with the change. Fix included.
I'm looking at BORINGSSL_API_VERSION for compatibility evolution, but for now
is not incremented as i would expect.
// BORINGSSL_API_VERSION is a positive integer that increments as BoringSSL
// changes over time. The value itself is not meaningful. It will be incremented
// whenever is convenient to coordinate an API change with consumers. This will
// not denote any special point in development.
// A consumer may use this symbol in the preprocessor to temporarily build
// against multiple revisions of BoringSSL at the same time. It is not
// recommended to do so for longer than is necessary.
#define BORINGSSL_API_VERSION 9
Description: Binary data