Re: Compiling Fetchmail 7 with OpenSSL 3

Matthias Andree <[email protected]> Mon, 16 May 2022 18:30:24 +0200
Newsgroups gmane.mail.fetchmail.user
Message-ID <[email protected]>
Am 15.05.22 um 23:20 schrieb Dennis Putnam:
> After successfully installing OpenSSL 3.0.3 on my CentOS 7 system, I
> tried to compile fetchmail 7, It was cloned from gitlab. The compile
> failed with these messages:
>
> undefined reference to `OpenSSL_version'
> undefined reference to `OpenSSL_version_num'
> undefined reference to `OPENSSL_sk_num'
> undefined reference to `OPENSSL_sk_value'
> undefined reference to `OPENSSL_sk_free'
> undefined reference to `TLS_client_method'
> undefined reference to `SSL_CTX_set_options'
>
> I went to the OpenSSL forum to see what was wrong and got this reply:
>
> *After checking the ssl.so library I observed Id don't define the
> function OpenSSL_version but into the header file opensslv.h you found
> a define that give you the version of your ssl library **
> **# define OPENSSL_VERSION_NUMBER  0x101010cfL **
> **# define OPENSSL_VERSION_TEXT    "OpenSSL 1.1.1l  24 Aug 2021" **
> ****
> **To resolve your problem don’t call the method OpenSSL_version, but
> use directly the define in header file opensslv.h.*
>
>
> I guess the implication is that the fetchmail source needs to be
> modified somewhere, right?

The forum suggestion "don’t call the method OpenSSL_version, but use
directly the define in header file opensslv.h." is bullshit.
It is someone telling you to superficially cure a symptom without
knowing intentions or researching the actual cause.

One more rant item: OpenSSL 3.0.0 and 3.0.2 both documented this method
(and OpenSSL's policies will not deprecate this in any 3.0.x version)
and I deliberately wrote fetchmail to inquire headers and library and
complain if they obviously do not match.

Rant aside, the cause I can currently only surmise that your fetchmail
ends up picking up pieces of both the 1.1.1 and 3.0 installations of
OpenSSL,
and I found one way that I can reproduce such a failure, which is
however specific to systems with multiple OpenSSL versions installed.


The _workaround_ for me seems to be (assuming OpenSSL 3 in
/opt/openssl3, else adjust):

./configure PKG_CONFIG_LIBDIR=/opt/openssl3/lib64/pkgconfig

and it prints (the first line is a cosmetic bug)

> configure: Enabling OpenSSL support in /usr.
> configure: SSL-check: trying pkg-config for openssl
> checking for SSL... yes
> checking how to link with libssl... /opt/openssl3/lib64/libssl.so
> /opt/openssl3/lib64/libcrypto.so -Wl,-rpath -Wl,/opt/openssl3/lib64
> configure: From pkg-config: Adding /opt/openssl3/lib64/libssl.so
> /opt/openssl3/lib64/libcrypto.so -Wl,-rpath -Wl,/opt/openssl3/lib64 to
> LIBS. LDFLAGS= -L/opt/openssl3/lib64
> configure: Enabling OpenSSL support.
> configure:
>   CC:       gcc
>   CPPFLAGS: -I/opt/openssl3/include
>   CFLAGS:   -g -O2 -I/usr/kerberos/include
>   LDFLAGS:   -L/opt/openssl3/lib64
>   LIBS:       /opt/openssl3/lib64/libssl.so
> /opt/openssl3/lib64/libcrypto.so -Wl,-rpath -Wl,/opt/openssl3/lib64
> checking whether LIBRESSL_VERSION_NUMBER is declared... no
> checking whether TLS1_3_VERSION is declared... yes
> checking whether TLS1_2_VERSION is declared... yes
> checking whether SSLv3_client_method is declared... no
> checking whether TLS_MAX_VERSION is declared... yes

and ends up with a working fetchmail that prints, when run with -V:

> $  ./fetchmail -V
> This is fetchmail release 7.0.0-alpha10+SSL-SSLv2-SSLv3+NLS.
> Compiled with SSL library 0x30000020 "OpenSSL 3.0.2 15 Mar 2022"
> Run-time uses SSL library 0x30000020 "OpenSSL 3.0.2 15 Mar 2022"
> OpenSSL: OPENSSLDIR: "/etc/pki/tls"
> Engines: ENGINESDIR: "/opt/openssl3/lib64/engines-3"
> ...
 From Git, ./configure --with-ssl seems to wind up mixing both versions
for me, I need to check that or forward-port configure.ac fixes from the
6.x stuff.



_______________________________________________
Fetchmail-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fetchmail-users