Created attachment 555002 [details, diff] mupdf patch mupdf fails to build because libressl is missing: PKCS12_SAFEBAG_get0_safes and PKCS12_SAFEBAG_get0_p8inf. Since they're simple functions, I just copied them in mupdf to get it to build.
Thanks William, I'll look into it soon. Do you know if there's a bug upstream about this? We should also submit this patch upstream.
Hi Virgil: This patch won't be accepted as is, it's only to be applied if the user has the libressl useflag. To submit it upstream you'd at least need #if check the libressl version. And check if libressl doesn't provide equivalent functions with different names.
Disclaimer: I don't know the libressl world very well. Something is fishy here. These functions are in openssl 1.1.x, not 1.0.x. We can see that in upstream's "Makerules" file's selection of HAVE_LIBCRYPTO libressl isn't compatible with 1.1 yet. This tells me that the root cause for this build failure is the patch mupdf-1.14-openssl-curl-x11.patch wrongly sets HAVE_LIBCRYPTO to yes. In fact, it's my fault, because this requirement bump from 1.0 to 1.1 happened in mupdf 1.14 and I made that ebuild bump. I should have detected this dependency bump and removed libressl support right away. But then again, if the only thing missing are those 3 small functions, maybe we can maintain a patch set. But if upstreams goes further in its usage of openssl 1.1 functionality before libressl has the time to follow, we'll have to drop libressl support. William, have you been using the result of that build? did you actually use ssl-related functionalities?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a5247eb5569e7573eba63db4cf5e6012607e1a6d commit a5247eb5569e7573eba63db4cf5e6012607e1a6d Author: Virgil Dupras <vdupras@gentoo.org> AuthorDate: 2019-02-19 20:22:34 +0000 Commit: Virgil Dupras <vdupras@gentoo.org> CommitDate: 2019-02-19 21:01:02 +0000 app-text/mupdf: fix libressl and openssl openssl's requirements is actually 1.1+. prior to this change, mupdf compiled with openssl support unless openssl 1.1+ was installed. libressl support requires a patch to work properly. Also, other minor fixes. See closed bugs. Closes: https://bugs.gentoo.org/671062 Closes: https://bugs.gentoo.org/623732 Closes: https://bugs.gentoo.org/669698 Closes: https://bugs.gentoo.org/670832 Signed-off-by: Virgil Dupras <vdupras@gentoo.org> Package-Manager: Portage-2.3.51, Repoman-2.3.11 app-text/mupdf/files/mupdf-1.14-libressl.patch | 45 +++++++ .../files/mupdf-1.14-r3-openssl-curl-x11.patch | 35 ++++++ app-text/mupdf/mupdf-1.14.0-r3.ebuild | 132 +++++++++++++++++++++ 3 files changed, 212 insertions(+)
REQUIRED_USE="libressl? ( !openssl )" Is there a reason for this? I usually see this in ebuilds: openssl? ( !libressl? ( dev-libs/openssl:0= ) libressl? ( dev-libs/libressl:0= ) ) I don't want to be annoying but this https://wiki.gentoo.org/wiki/Project:LibreSSL says: The important point to note is that USE=libressl acts as a discriminating flag between OpenSSL and LibreSSL. As such, it is not a pure implementation USE flag and is analogous to USE=libav. That is, USE=libressl is never mutually exclusive to any other USE flag and should therefore never appear in REQUIRED_USE
I had started doing the typical "ssl? ( !libressl? () libressl? () )" work in the ebuild, but it felt wrong because mupdf doesn't use openssl as a communication transport like most ssl-enabled apps, but as a signing tool. Because things were already like this in the package (use of "openssl" instead of "ssl"), I left things as is, but added the REQUIRED_USE to fix other linked bugs in the commit. The "openssl? ( !libressl? () libressl? () )" scheme (not with "ssl", but "openssl") feels very weird. "you want libressl? you have to enable openssl first!" Maybe one day I'll rename "openssl" to "ssl", but because I will probably have to mask "openssl" on this package (it requires openssl 1.1+ which isn't likely to be stabilized any time soon) if I want to stabilize mupdf, I thought I'd leave things as is for the time being.
