eclipse / mosquitto

Eclipse Mosquitto - An open source MQTT broker
https://mosquitto.org
Other
8.61k stars 2.33k forks source link

Fix multiple build warnings (raises cmake_minimum_required and sets OPENSSL_API_COMPAT) #3050

Open carstenandrich opened 1 month ago

carstenandrich commented 1 month ago

Thank you for contributing your time to the Mosquitto project!

Before you go any further, please note that we cannot accept contributions if you haven't signed the Eclipse Contributor Agreement. If you aren't able to do that, or just don't want to, please describe your bug fix/feature change in an issue. For simple bug fixes it is can be just as easy for us to be told about the problem and then go fix it directly.

Then please check the following list of things we ask for in your pull request:


This PR fixes multiple build warnings I stumbled upon integrating libmosquitto into a project of mine. Changes are split into 4 separate commits that address individual issues, to enable cherry picking:

  1. raise cmake_minimum_required(VERSION 3.1) to 3.5 to resolve a deprecation warning with CMake 3.27 and above. CMake 3.5 is from April 2016.
  2. fix unused parameter warning in mosquitto_void_option() that only occurs when building without TLS support
  3. fix unused variable warning in net__socket_connect_tls() by removing 2 entirely unused variables
  4. set OpenSSL API version compatibilty macro OPENSSL_API_COMPAT to OpenSSL 1.1. currently mosquitto uses the ENGINE API, which was deprecated with OpenSSL 3.0, causing deprecation warnings when compiling with GCC: src/net.c:566:9: warning: ‘ENGINE_free’ is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations]

Nr. 4 is related to #2944 and #2779. In the latter it was suggested to define OPENSSL_NO_ENGINE to silence the warning, but for lack of documentation on OPENSSL_NO_ENGINE and its possible side effects, setting OPENSSL_API_COMPAT appears to be the cleaner approach. However, migrating from OpenSSL ENGINE to Providers API is probably the only long-term solution to address the TLS handshake issues in #2779 and possibly #2907.