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

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

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-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

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 *tlsext_ecpointformatlist