Date: Tue, 28 Nov 2023 06:37:27 +0000 From: Alexey Dokuchaev <danfe@freebsd.org> To: d@delphij.net Cc: freebsd-ports@freebsd.org, osa@freebsd.org Subject: Re: Best practice for port that are meant to be statically linked, or how should we handle boringssl Message-ID: <ZWWKp1KW6RgA2k57@FreeBSD.org> In-Reply-To: <7a92ad42-b45d-46d4-b2f2-54b4bfcf2e93@delphij.net> References: <7a92ad42-b45d-46d4-b2f2-54b4bfcf2e93@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Nov 26, 2023 at 11:07:21PM -0800, Xin Li wrote: > Hi, > > I recently noticed that security/boringssl is treated in a similar way > of OpenSSL and LibreSSL. Technically, `security/boringssl' cannot be treated similarly, i.e. it cannot be made one of possible SSL providers (via USES=ssl) because of circular dependency (it requires CMake which itself requires SSL). > Although boringssl is derived from OpenSSL, it's usually meant to be > statically linked into the resulting binary, because there is no > guarantee of ABI stability across different releases and the caller > is expected to evolve fast enough to follow the latest version of it. I was playing with that idea to get `www/envoy' packaged, later found out there is OpenSSL-based fork and decided to go that way, but could not complete the quest. :( > OpenBSD seems to be going though the statically linked route and they > install boringssl into ${PREFIX}/eboringssl instead of the regular > ${PREFIX}. This way, it's no longer conflicting with other OpenSSL/ > LibreSSL installation (technically, it still is, but only if the binary > links against both OpenSSL/LibreSSL _and_ boringssl). > > Should we follow this? And is using something like ${PREFIX}/eboringssl > a good model? (I think ultimately we need something like it). I wouldn't mind, albeit ultimately I'd rather see Google push their changes in the stock OpenSSL and bury their silly fork. ./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZWWKp1KW6RgA2k57>