From: Dennis P. <da...@be...> - 2022-05-17 13:38:02
|
On 5/16/2022 12:30 PM, Matthias Andree wrote: > 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. > Thanks for the reply. Just to be clear, I should omit --with-ssl and just use PKG_CONFIG_LIBDIR=/opt/openssl3/lib64/pkgconfig or do I need both? |