From: Eric Biggers <email@example.com> To: Aleksander Adamowski <firstname.lastname@example.org> Cc: "Tomasz Kłoczko" <email@example.com>, "firstname.lastname@example.org" <email@example.com> Subject: Re: [fsverity-utils] 1.4: test suite does not build Date: Mon, 20 Sep 2021 14:19:39 -0700 [thread overview] Message-ID: <YUj667bPkKxM4Lfirstname.lastname@example.org> (raw) In-Reply-To: <SA1PR15MB48247A9238700C0A1B12CCB6DDA09@SA1PR15MB4824.namprd15.prod.outlook.com> On Mon, Sep 20, 2021 at 08:05:25PM +0000, Aleksander Adamowski wrote: > On Saturday, September 18, 2021 1:04 PM, Eric Biggers wrote: > > Aleksander, can you look into these? > > These look like compiler warnings, why did they break the build? > > The reason for the warnings is that the Engines API that we use with OpenSSL <= > 1.1 has started to be deprecated with OpenSSL release 3.0. > > The replacement that OpenSSL offers is called "Providers": > https://www.openssl.org/docs/man3.0/man7/migration_guide.html#Engines-and-METHOD-APIs > > Unfortunately, the Providers API is only available starting with version 3.0, > the same version that deprecates Engines: > > https://www.openssl.org/docs/manmaster/man3/OSSL_PROVIDER_load.html > > So, our options here are: > > 1. Tolerate deprecation warnings from the compiler until the OpenSSL version > that provides the new replacement API is widespread enough to stop supporting > OpenSSL versions <= 1.1 (I think this is the most reasonable approach, after > all that's how deprecation mechanisms are meant to be used). > > 2. Use a bunch of preprocessor conditional #ifdefs to support both OpenSSL > pre-3.0 with Engines and post-3.0 with Providers. This would make code pretty > messy IMHO, but should be doable. I can start working on a patch if we get > consensus; however, my opinion is that we should withhold from that until > OpenSSL 3 is the standard release on mainstream distros. > Sorry, it looks like I misread Tomasz's email; the build break wasn't from those warnings but rather from the test programs not being linked to libfsverity. Tomasz, are you using the provided Makefile? In the Makefile, the test programs are linked correctly, so this isn't an issue. How can I reproduce your issue? Aleksander: there still shouldn't be any compiler warnings. In my test script (scripts/run-tests.sh) I actually use -Werror. If there isn't a good way to avoid these deprecation warnings (and I'd prefer not to have code that's conditional on different OpenSSL versions), we can just add -Wno-deprecated-declarations to the Makefile for now. - Eric
next prev parent reply other threads:[~2021-09-20 21:21 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-18 13:20 Tomasz Kłoczko 2021-09-18 20:04 ` [fsverity-utils] " Eric Biggers 2021-09-20 20:05 ` Aleksander Adamowski 2021-09-20 21:19 ` Eric Biggers [this message] 2021-09-20 21:52 ` Aleksander Adamowski 2021-09-22 18:57 ` Eric Biggers
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YUj667bPkKxM4Lemail@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [fsverity-utils] 1.4: test suite does not build' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).