Summary: | multimedia/pipewire: Unbreak build with DEFAULT_VERSIONS=ssl=openssl30 | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Craig Leres <leres> | ||||||||
Component: | Individual Port(s) | Assignee: | Gleb Popov <arrowd> | ||||||||
Status: | Closed DUPLICATE | ||||||||||
Severity: | Affects Only Me | CC: | arrowd, ctyz1999+bugzilla, cyberbotx, jbeich | ||||||||
Priority: | --- | Flags: | arrowd:
maintainer-feedback+
|
||||||||
Version: | Latest | ||||||||||
Hardware: | Any | ||||||||||
OS: | Any | ||||||||||
Bug Depends on: | 273961 | ||||||||||
Bug Blocks: | |||||||||||
Attachments: |
|
Description
Craig Leres
![]() ![]() Created attachment 245573 [details]
patch
security/openssl30 is going to be removed from ports shortly. Created attachment 245588 [details]
revised patch
I didn't realize OPENSSL_API_COMPAT worked with openssl > 3.0; given the impending demise of openssl30, adjust patch to work with openssl3X (I've tested it openssl31).
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=75ff86d0e516e6291be7e25cc30bb14fbda10bf1 commit 75ff86d0e516e6291be7e25cc30bb14fbda10bf1 Author: Craig Leres <leres@FreeBSD.org> AuthorDate: 2023-10-12 20:14:10 +0000 Commit: Craig Leres <leres@FreeBSD.org> CommitDate: 2023-10-12 20:14:10 +0000 multimedia/pipewire: Unbreak build with DEFAULT_VERSIONS=ssl=openssl3X Use OPENSSL_API_COMPAT to fix build on FreeBSD 13.2 with DEFAULT_VERSIONS=ssl=openssl3[012] PR: 274419 Approved by: arrowd (maintainer) multimedia/pipewire/Makefile | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) Why port OpenSSL 3.0 (in FreeBSD 13.2) needs OpenSSL 1.1 API compat but base OpenSSL 3.0 (in FreeBSD 14.0) does not? Looks like a workaround for an ABI mismatch: /usr/local/include/openssl vs. /usr/lib/libcrypto.so. This mainly affects libpipewire-module-raop-sink.so, so runtime may be tricky to test. $ pkg install openssl30 $ pkg-config --modversion openssl 1.1.1t diff --git a/multimedia/pipewire/Makefile b/multimedia/pipewire/Makefile index d5d154acd4e5..b3b9866e0514 100644 --- a/multimedia/pipewire/Makefile +++ b/multimedia/pipewire/Makefile @@ -111,8 +111,9 @@ post-install-MEDIASESSION-on: .include <bsd.port.pre.mk> -.if ${SSL_DEFAULT:C,3[0-9],3,} == openssl3 -CFLAGS+= -DOPENSSL_API_COMPAT=0x10100000L +.if ${SSL_DEFAULT} != base +# XXX Move into USES=ssl to fix for USES=meson and other USES=pkgconfig consumers +CONFIGURE_ENV+= PKG_CONFIG_PATH=${LOCALBASE}/libdata/pkgconfig .endif .include <bsd.port.post.mk> Created attachment 245601 [details] Help Meson detect security/openssl3* Oops, my patch in comment 5 had a bug breaking plist: Error: Missing: bin/pw-top > Why port OpenSSL 3.0 (in FreeBSD 13.2) needs OpenSSL 1.1 API compat but base OpenSSL 3.0 (in FreeBSD 14.0) does not? It might be related to the problem with OpenSSL 3 import that I described here: https://lists.freebsd.org/archives/freebsd-current/2023-August/004261.html and here https://reviews.freebsd.org/D41506 Jan, Craig, feel free to push any pipewire patches you think are sensible. I'm a nominal maintainer for this port and don't use it myself. I ported it as a dependency for xdg-desktop-portal (which I also don't use ATM). It might even make sense to give the maintainership to someone else. I'd like to point out that I ran into this failure on building multimedia/pipewire in poudriere with a git pull from October 16, after Craig's commit. My poudriere make.conf for the build has ssl=openssl in the DEFAULT_VERSIONS. That makes it use security/openssl, which is currently OpenSSL 3.0.11 as of this message, and thus would've been affected by this as the committed change only checks for a value matching openssl3 for ssl in DEFAULT_VERSIONS and not openssl. As the builder is still going, I am unable to currently test any changes, but I imagine that the patch submitted by Jan may work, while the patch submitted by Craig will not. There's a generic fix available, so my patch is obsolete and ports 75ff86d0e516 (aka comment 4) should be reverted. *** This bug has been marked as a duplicate of bug 273961 *** |