Re: LibreSSL 2.1.2 linking issues

2014-12-11 Thread Lukas Tribus
Many Lolz.. Lukas you just made my day.. They've been misused that way, and more than once, by more than one project. This is why we really want it to be just a string, and strongly discourage people from using it in the way it has been abused. ... we could always change it so the

Re: LibreSSL 2.1.2 linking issues

2014-12-10 Thread Lukas Tribus
I believe a not to be underestimated amount of applications #ifdef's certain functionality of openssl out, for example NPN (SSL_CTRL_SET_TLSEXT_HOSTNAME) or server preferential cipher ordering (SSL_OP_CIPHER_SERVER_PREFERENCE). That's rather different to checking using defines with

Re: LibreSSL 2.1.2 linking issues

2014-12-10 Thread Lukas Tribus
Sorry if this is long-winded: Dito :) One reason is that incrementing for sub-minor versions in the CVS source doesn’t mean anything, since the portable release schedule is independent in OpenBSD land. Agreed that this doesn't make much sense for CVS source, for the -portable tarballs

LibreSSL 2.1.2 linking issues

2014-12-09 Thread Lukas Tribus
Hi, I'm linking haproxy (current git master) against libressl 2.1.2 portable on linux, but seeing 2 issues (not present in previous libressl 2.1.1): Issue number one (not sure what happens here): include/openssl/ssl.h:503:2: error: unknown type name ‘uint8_t’   uint8_t

Re: LibreSSL 2.1.2 linking issues

2014-12-09 Thread Lukas Tribus
On 2014/12/09 07:37, Brent Cook wrote: If an app calls a function, it should probably check if that function exists during configuration time, rather than inferring if define A exists, function B and C must exist. Especially things that are just protocol constant definitions. If they are