Check your config.log file for lines that start with configure:[numbers]: pkg-config: SSL_ for some clues.

When I build OpenSSL with a custom dir I get this logged:

configure:19332: pkg-config: SSL_LIBS: "-lssl -lcrypto"
configure:19334: pkg-config: SSL_LDFLAGS: "-L/home/daniel/build-openssl/lib"
configure:19336: pkg-config: SSL_CPPFLAGS: "-I/home/daniel/build-openssl/include"

I get similar logs with the correct directories (i.e. the "-L" in the path is not ommited).

configure:19329: pkg-config: SSL_LIBS: "-lssl -lcrypto"
configure:19331: pkg-config: SSL_LDFLAGS: "-L/home/mosa/dev/Project-Linux/libs/openssl/lib"
configure:19333: pkg-config: SSL_CPPFLAGS: "-I/home/mosa/dev/Project-Linux/libs/openssl/include"

After that the build script keeps performing checks.. the very first check goes like this (with the correct path passed to the gcc command)..

configure:19345: checking for HMAC_Update in -lcrypto
configure:19367: gcc -o conftest -Werror-implicit-function-declaration -O2 -Wno-system-headers   -I/home/mosa/dev/Project-Linux/libs/openssl/include   -L/home/mosa/dev/Project-Linux/libs/openssl/lib conftest.c -lcrypto  -lssl -lcrypto -lz  >&5
/usr/bin/ld: /home/mosa/dev/Project-Linux/libs/openssl/lib/libcrypto.a(threads_pthread.o): in function `CRYPTO_THREAD_lock_new':
threads_pthread.c:(.text+0x45): undefined reference to `pthread_rwlock_init'
...

Then right after that this happens..

configure:19390: checking for HMAC_Init_ex in -lcrypto
configure:19412: gcc -o conftest -Werror-implicit-function-declaration -O2 -Wno-system-headers   -I/home/mosa/dev/Project-Linux/libs/openssl/include   -L/home/mosa/dev/Projectinux/libs/openssl/lib conftest.c -lcrypto  -lssl -lcrypto -lz  >&5
/usr/bin/ld: cannot find -lcrypto
/usr/bin/ld: cannot find -lssl
/usr/bin/ld: cannot find -lcrypto
collect2: error: ld returned 1 exit status

Notice the directory is supposed to be Project-Linux but the -L gets ommited.

I found this line in the configure file..

LIB_OPENSSL=`echo $SSL_LDFLAGS | sed -e 's/-L//g'`

which does ommit the -L in the path.

Removing the -L from LIB_OPENSSL is not an error which you see if you read configure.ac.

But the "checking for HMAC_Update in -lcrypto" looks suspicious and is the true reason for your problem. Why does that fail? It looks like a pthread problem: undefined reference to pthread_rwlock_init'. And as it doesn't find HMAC_Update`, it can't use OpenSSL...

Or perhaps it succeeds a little further down. in the later checks?

What OpenSSL version are you trying to link with like this?

Removing the first -L is not an error, but removing all the -L's is.

The build script as far as I understand, performs many checks that don't necessarily succeed, so the first check that fails is because of missing libraries (pthread and dl) in the compilation command.

I tried removing the line I mentioned above (the one that removes the -L) and the build succeeded.

I'm using OpenSSL version 1.1.1g

Again, the problem happens when the OpenSSL path contains -L in it.
e.g. /home/bagder/A-L/openssl/.
This is the path that contains the openssl library. It's not the linking command. It's the path only.

The linking command for this path should look like this -L/home/bagder/A-L/openssl/

but after performing this line

LIB_OPENSSL=`echo $SSL_LDFLAGS | sed -e 's/-L//g'`

it becomes /home/bagder/A/openssl/.

Notice the A-L became just A.

Oh.

So then isn't this the fix?

--- a/configure.ac
+++ b/configure.ac
@@ -1719,11 +1719,11 @@ if test -z "$ssl_backends" -o "x$OPT_SSL" != xno &&
       AC_SUBST(SSL_LIBS)
       AC_MSG_NOTICE([pkg-config: SSL_LIBS: "$SSL_LIBS"])
       AC_MSG_NOTICE([pkg-config: SSL_LDFLAGS: "$SSL_LDFLAGS"])
       AC_MSG_NOTICE([pkg-config: SSL_CPPFLAGS: "$SSL_CPPFLAGS"])
 
-      LIB_OPENSSL=`echo $SSL_LDFLAGS | sed -e 's/-L//g'`
+      LIB_OPENSSL=`echo $SSL_LDFLAGS | sed -e 's/^-L//'`
 
       dnl use the values pkg-config reported.  This is here
       dnl instead of below with CPPFLAGS and LDFLAGS because we only
       dnl learn about this via pkg-config.  If we only have
       dnl the argument to --with-ssl we don't know what

Assuming of course there's only one -L and that's firsrt...

I believe so, yes.
Thank you!