error compiling curl with my own openssl version

[tessus]

I did this

• compiled OpenSSL 1.0.2k: ./config -fPIC
• configured curl 7.53.1: ./configure --with-ssl=/usr/local/ssl see config.log

make abended:

make V=1
Making all in lib
make[1]: Entering directory `/data/tessus/work/curl-7.53.1/lib'
make  all-am
make[2]: Entering directory `/data/tessus/work/curl-7.53.1/lib'
make[2]: Leaving directory `/data/tessus/work/curl-7.53.1/lib'
make[1]: Leaving directory `/data/tessus/work/curl-7.53.1/lib'
Making all in src
make[1]: Entering directory `/data/tessus/work/curl-7.53.1/src'
make  all-am
make[2]: Entering directory `/data/tessus/work/curl-7.53.1/src'
/bin/sh ../libtool  --tag=CC   --mode=link gcc  -O2 -Wno-system-headers   -L/usr/lib64 -L/usr/local/ssl/lib -o curl curl-slist_wc.o curl-tool_binmode.o curl-tool_bname.o curl-tool_cb_dbg.o curl-tool_cb_hdr.o curl-tool_cb_prg.o curl-tool_cb_rea.o curl-tool_cb_see.o curl-tool_cb_wrt.o curl-tool_cfgable.o curl-tool_convert.o curl-tool_dirhie.o curl-tool_doswin.o curl-tool_easysrc.o curl-tool_formparse.o curl-tool_getparam.o curl-tool_getpass.o curl-tool_help.o curl-tool_helpers.o curl-tool_homedir.o curl-tool_hugehelp.o curl-tool_libinfo.o curl-tool_main.o curl-tool_metalink.o curl-tool_mfiles.o curl-tool_msgs.o curl-tool_operate.o curl-tool_operhlp.o curl-tool_panykey.o curl-tool_paramhlp.o curl-tool_parsecfg.o curl-tool_strdup.o curl-tool_setopt.o curl-tool_sleep.o curl-tool_urlglob.o curl-tool_util.o curl-tool_vms.o curl-tool_writeenv.o curl-tool_writeout.o curl-tool_xattr.o ../lib/curl-strtoofft.o ../lib/curl-nonblock.o ../lib/curl-warnless.o  ../lib/libcurl.la   -lssl -lcrypto  -lz
libtool: link: gcc -O2 -Wno-system-headers -o .libs/curl curl-slist_wc.o curl-tool_binmode.o curl-tool_bname.o curl-tool_cb_dbg.o curl-tool_cb_hdr.o curl-tool_cb_prg.o curl-tool_cb_rea.o curl-tool_cb_see.o curl-tool_cb_wrt.o curl-tool_cfgable.o curl-tool_convert.o curl-tool_dirhie.o curl-tool_doswin.o curl-tool_easysrc.o curl-tool_formparse.o curl-tool_getparam.o curl-tool_getpass.o curl-tool_help.o curl-tool_helpers.o curl-tool_homedir.o curl-tool_hugehelp.o curl-tool_libinfo.o curl-tool_main.o curl-tool_metalink.o curl-tool_mfiles.o curl-tool_msgs.o curl-tool_operate.o curl-tool_operhlp.o curl-tool_panykey.o curl-tool_paramhlp.o curl-tool_parsecfg.o curl-tool_strdup.o curl-tool_setopt.o curl-tool_sleep.o curl-tool_urlglob.o curl-tool_util.o curl-tool_vms.o curl-tool_writeenv.o curl-tool_writeout.o curl-tool_xattr.o ../lib/curl-strtoofft.o ../lib/curl-nonblock.o ../lib/curl-warnless.o  -L/usr/lib64 -L/usr/local/ssl/lib ../lib/.libs/libcurl.so -lssl -lcrypto -lz
../lib/.libs/libcurl.so: undefined reference to `SSL_get0_alpn_selected'
../lib/.libs/libcurl.so: undefined reference to `SSL_COMP_free_compression_methods'
../lib/.libs/libcurl.so: undefined reference to `SSL_CTX_set_alpn_protos'
collect2: error: ld returned 1 exit status
make[2]: *** [curl] Error 1
make[2]: Leaving directory `/data/tessus/work/curl-7.53.1/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/data/tessus/work/curl-7.53.1/src'
make: *** [all-recursive] Error 1

I changed the order of the library paths and added -ldl:

/bin/sh ../libtool  --tag=CC   --mode=link gcc  -O2 -Wno-system-headers -L/usr/local/ssl/lib -L/usr/lib64 -o curl curl-slist_wc.o curl-tool_binmode.o curl-tool_bname.o curl-tool_cb_dbg.o curl-tool_cb_hdr.o curl-tool_cb_prg.o curl-tool_cb_rea.o curl-tool_cb_see.o curl-tool_cb_wrt.o curl-tool_cfgable.o curl-tool_convert.o curl-tool_dirhie.o curl-tool_doswin.o curl-tool_easysrc.o curl-tool_formparse.o curl-tool_getparam.o curl-tool_getpass.o curl-tool_help.o curl-tool_helpers.o curl-tool_homedir.o curl-tool_hugehelp.o curl-tool_libinfo.o curl-tool_main.o curl-tool_metalink.o curl-tool_mfiles.o curl-tool_msgs.o curl-tool_operate.o curl-tool_operhlp.o curl-tool_panykey.o curl-tool_paramhlp.o curl-tool_parsecfg.o curl-tool_strdup.o curl-tool_setopt.o curl-tool_sleep.o curl-tool_urlglob.o curl-tool_util.o curl-tool_vms.o curl-tool_writeenv.o curl-tool_writeout.o curl-tool_xattr.o ../lib/curl-strtoofft.o ../lib/curl-nonblock.o ../lib/curl-warnless.o  ../lib/libcurl.la   -lssl -lcrypto  -lz -ldl
libtool: link: gcc -O2 -Wno-system-headers -o .libs/curl curl-slist_wc.o curl-tool_binmode.o curl-tool_bname.o curl-tool_cb_dbg.o curl-tool_cb_hdr.o curl-tool_cb_prg.o curl-tool_cb_rea.o curl-tool_cb_see.o curl-tool_cb_wrt.o curl-tool_cfgable.o curl-tool_convert.o curl-tool_dirhie.o curl-tool_doswin.o curl-tool_easysrc.o curl-tool_formparse.o curl-tool_getparam.o curl-tool_getpass.o curl-tool_help.o curl-tool_helpers.o curl-tool_homedir.o curl-tool_hugehelp.o curl-tool_libinfo.o curl-tool_main.o curl-tool_metalink.o curl-tool_mfiles.o curl-tool_msgs.o curl-tool_operate.o curl-tool_operhlp.o curl-tool_panykey.o curl-tool_paramhlp.o curl-tool_parsecfg.o curl-tool_strdup.o curl-tool_setopt.o curl-tool_sleep.o curl-tool_urlglob.o curl-tool_util.o curl-tool_vms.o curl-tool_writeenv.o curl-tool_writeout.o curl-tool_xattr.o ../lib/curl-strtoofft.o ../lib/curl-nonblock.o ../lib/curl-warnless.o  -L/usr/local/ssl/lib -L/usr/lib64 ../lib/.libs/libcurl.so -lssl -lcrypto -lz -ldl

This worked.

However, as you can see the curl output still reports the wrong openssl version:

./curl -V
curl 7.53.1 (x86_64-pc-linux-gnu) libcurl/7.53.1 OpenSSL/1.0.1e zlib/1.2.8 libssh2/1.5.0
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: IPv6 Largefile NTLM NTLM_WB SSL libz UnixSockets HTTPS-proxy

The curl binary is static, so I have no idea which libraries were really linked.

Checking the shared library:

ldd libcurl.so
        linux-vdso.so.1 =>  (0x00007fff07964000)
        libssh2.so.1 => /lib64/libssh2.so.1 (0x00007ff45adc8000)
        libssl.so.10 => /lib64/libssl.so.10 (0x00007ff45ab5a000)
        libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007ff45a772000)
        liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007ff45a563000)
        libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007ff45a310000)
        libz.so.1 => /lib64/libz.so.1 (0x00007ff45a0fa000)
        libc.so.6 => /lib64/libc.so.6 (0x00007ff459d3c000)
        libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007ff459af1000)
        libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007ff459811000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007ff45960d000)
        libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007ff4593d7000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007ff4591d3000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007ff458fb9000)
        libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007ff458d9b000)
        libssl3.so => /lib64/libssl3.so (0x00007ff458b5c000)
        libsmime3.so => /lib64/libsmime3.so (0x00007ff458935000)
        libnss3.so => /lib64/libnss3.so (0x00007ff45860d000)
        libnssutil3.so => /lib64/libnssutil3.so (0x00007ff4583e1000)
        libplds4.so => /lib64/libplds4.so (0x00007ff4581dd000)
        libplc4.so => /lib64/libplc4.so (0x00007ff457fd7000)
        libnspr4.so => /lib64/libnspr4.so (0x00007ff457d99000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff457b7c000)
        /lib64/ld-linux-x86-64.so.2 (0x00000036d1e00000)
        libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007ff45796d000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007ff457769000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007ff457531000)
        librt.so.1 => /lib64/librt.so.1 (0x00007ff457329000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007ff457104000)
        libfreebl3.so => /lib64/libfreebl3.so (0x00007ff456e87000)
        libpcre.so.1 => /lib64/libpcre.so.1 (0x00007ff456c21000)
        liblzma.so.5 => /lib64/liblzma.so.5 (0x00007ff4569fb000)

As you can see, the shared library references my system's openssl libraries and not the ones which I specified in the configure option.

configure found my openssl libraries, but I can also see another issue here:

configure:22167: PKG_CONFIG_LIBDIR will be set to "/usr/local/ssl/lib/pkgconfig"
configure:22235: checking for pkg-config
configure:22266: result: /usr/bin/pkg-config
configure:22291: checking for openssl options with pkg-config
configure:22305: result: found
configure:22334: pkg-config: SSL_LIBS: "-lssl -lcrypto "
configure:22336: pkg-config: SSL_LDFLAGS: "-L/usr/local/ssl/lib "
configure:22338: pkg-config: SSL_CPPFLAGS: "-I/usr/local/ssl/include "
configure:22350: checking for HMAC_Update in -lcrypto
configure:22372: gcc -o conftest -O2 -Wno-system-headers   -I/usr/local/ssl/include  -L/usr/lib64   -L/usr/local/ssl/lib  conftest.c -lcrypto  -lssl -lcrypto  -llber -lldap -lz  >&5
configure:22372: $? = 0
configure:22381: result: yes
configure:22443: checking OpenSSL linking without -ldl
configure:22460: gcc -o conftest -O2 -Wno-system-headers   -I/usr/local/ssl/include  -L/usr/lib64   -L/usr/local/ssl/lib  conftest.c -lcrypto -lssl -lcrypto  -llber -lldap -lz  >&5
configure:22460: $? = 0
configure:22462: result: yes
configure:22514: checking for SSL_connect in -lssl
configure:22536: gcc -o conftest -O2 -Wno-system-headers   -I/usr/local/ssl/include  -L/usr/lib64   -L/usr/local/ssl/lib  conftest.c -lssl  -lcrypto -lssl -lcrypto  -llber -lldap -lz  >&5
configure:22536: $? = 0
configure:22545: result: yes

checking OpenSSL linking without -ldl -> result: yes

This can't be true, because I only have static openssl libraries in /usr/local/ssl/lib.

I also tried to create and use shared openssl libraries, but this changed nothing in regards to curl. The same error occurs and still only the system's openssl libs are referenced.

I expected the following

• a working curl version linked to my openssl
• a shared curl library that uses my openssl libs
  • dynamic openssl: libcurl.so should reference my openssl libs
  • static openssl: libcurl.so should include my static openssl and not reference any openssl libs at all

curl/libcurl version

curl-7.53.1 - https://curl.haxx.se/download/curl-7.53.1.tar.gz

operating system

Linux 3.16.3-200.fc20.x86_64 #1 SMP Wed Sep 17 22:34:21 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

[jay]

Ref: #1035

checking OpenSSL linking without -ldl -> result: yes

This can't be true, because I only have static openssl libraries in /usr/local/ssl/lib.

Are you sure, did you ls? -ldl is needed by -lssl in your case. The pkg-config for openssl needs the --static flag to return -ldl as part of the --libs output. curl configure script does not use pkg-config --static and cannot be expected to keep up with static lib dependencies (though technically you can assign it to PKG_CONFIG but that may create a whole other set of problems). However curl configure has a test for -ldl to determine whether or not it should be added for openssl. That test looks correct. What happens when you run this similar thing:

cat << EOF > a.c
#include <stdio.h>
#include <openssl/crypto.h>
#include <openssl/evp.h>
int main() {
  SSLeay_add_all_algorithms();
  printf("%s\n", SSLeay_version(SSLEAY_VERSION));
  return 0;
}
EOF
gcc -o a a.c `PKG_CONFIG_PATH=/usr/local/ssl/lib pkg-config --static --libs --cflags openssl`
./a
ldd a

That should compile and not show any dynamic libs. Take away the --static and it should fail to compile due to unknown dl stuff.

dynamic openssl: libcurl.so should reference my openssl libs
static openssl: libcurl.so should include my static openssl and not reference any openssl libs at all

If you have dynamic openssl in a non standard location and you want curl to use that version then you could add an rpath.

LDFLAGS="-Wl,-rpath,/usr/local/ssl/lib" ./configure --with-ssl=/usr/local/ssl

If you have static openssl you should be able to just build it, I think maybe some dynamic libs are found in the path first which is causing this problem. That could be an issue if say your zlib lib location /usr/lib64 also contains dynamic openssl libs, since zlib is detected before openssl and therefore -L/usr/lib64 comes before -L/usr/local/ssl/lib.

[jay]

On second thought that -ldl test may not be correct for OpenSSL 1.1.0 because it tests for SSLeay_add_all_algorithms which AFAICT isn't present in that version. Not sure how that would apply here though since you said OpenSSL 1.0.2.

[bagder]

dynamic openssl: libcurl.so should reference my openssl libs

It does - when building.

You need to make sure that those are then also used when you run curl/libcurl as the build process does not set a fixed search path. You must set that appropriately yourself with LD_LIBRARY_PATH, editing /etc/ld.so.conf or similar.

[tessus]

Disclaimer: I'm a developer myself and I know build systems, the autotools suite, the internals of a compiler and a linker.

I believe you missed a few critical pointers in my post, but maybe I just crammed to much info in a single post. This was my mistake, so let's forget about libcurl (dynamic library) for now and circle back later (or I can also create another ticket).

Are you sure, did you ls? -ldl is needed by -lssl in your case.

Yes I am sure. openssl prior to version 1.1.0 only builds a shared library, if explicitly set during ./config. But here's the proof:

[tessus@atvie01s 0 /usr/local/ssl]$ ls lib
engines  libcrypto.a  libssl.a  pkgconfig

The config.log output shows that it is testing OpenSSL linking without -ldl and returns yes.
This is a bug, because I have only static libraries and it will fail without -ldl.
It has to return no!

This means the build process is broken.

Here is the problem: configure:22460: gcc -o conftest -O2 -Wno-system-headers -I/usr/local/ssl/include -L/usr/lib64 -L/usr/local/ssl/lib conftest.c -lcrypto -lssl -lcrypto -llber -lldap -lz >&5

It does not use my libraries for the test at all, because -L/usr/lib64 is specified before -L/usr/local/ssl/lib.

This is also the reason why make abends. But I was able to get it to compile by going to the src directory and manually using the following command (I had to change the order of the library paths and add -ldl):

/bin/sh ../libtool  --tag=CC   --mode=link gcc  -O2 -Wno-system-headers -L/usr/local/ssl/lib -L/usr/lib64 -o curl curl-slist_wc.o curl-tool_binmode.o curl-tool_bname.o curl-tool_cb_dbg.o curl-tool_cb_hdr.o curl-tool_cb_prg.o curl-tool_cb_rea.o curl-tool_cb_see.o curl-tool_cb_wrt.o curl-tool_cfgable.o curl-tool_convert.o curl-tool_dirhie.o curl-tool_doswin.o curl-tool_easysrc.o curl-tool_formparse.o curl-tool_getparam.o curl-tool_getpass.o curl-tool_help.o curl-tool_helpers.o curl-tool_homedir.o curl-tool_hugehelp.o curl-tool_libinfo.o curl-tool_main.o curl-tool_metalink.o curl-tool_mfiles.o curl-tool_msgs.o curl-tool_operate.o curl-tool_operhlp.o curl-tool_panykey.o curl-tool_paramhlp.o curl-tool_parsecfg.o curl-tool_strdup.o curl-tool_setopt.o curl-tool_sleep.o curl-tool_urlglob.o curl-tool_util.o curl-tool_vms.o curl-tool_writeenv.o curl-tool_writeout.o curl-tool_xattr.o ../lib/curl-strtoofft.o ../lib/curl-nonblock.o ../lib/curl-warnless.o  ../lib/libcurl.la   -lssl -lcrypto  -lz -ldl

Finally, a working curl executable.

However, as you can see from the version info, it's using the wrong openssl:

curl 7.53.1 (x86_64-pc-linux-gnu) libcurl/7.53.1 OpenSSL/1.0.1e zlib/1.2.8 libssh2/1.5.0
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: IPv6 Largefile NTLM NTLM_WB SSL libz UnixSockets HTTPS-proxy

It says OpenSSL/1.0.1e, while it should say OpenSSL/1.0.2k.

So, let's summarize: I used a configure option to specify my openssl release, which results in an error during compilation of curl. After manual intervention the binary could be built, but it uses the wrong openssl release.

I am sorry to say, but the build process is broken.

---

Last but not least, I still owe you the result of your test:

What happens when you run this similar thing:

ldd still shows the 2 system's openssl libraries. But this was to be expected, because your compile command is wrong. It must look like this:

gcc -o a a.c -L/usr/local/ssl/lib `PKG_CONFIG_PATH=/usr/local/ssl/lib pkg-config --static --libs --cflags openssl`

[jay]

Oops I meant PKG_CONFIG_PATH=/usr/local/ssl/lib/pkgconfig/ pkg-config --static --libs --cflags openssl. Manually adding the -Lpath should not be necessary if it's reading from the right pc.

It does not use my libraries for the test at all, because -L/usr/lib64 is specified before -L/usr/local/ssl/lib.

I see. I don't know what we could do to make things better for you, short of moving the zlib detection after OpenSSL. But say we did that, then anyone who has the reverse situation may be affected, and the wrong zlib could be included. Also I think some other libs depend on zlib, and OpenSSL may be one of them depending on how it's built. So maybe it is right to be searched for first.

Try doing it manually like LIBS=-ldl LDFLAGS=-L/usr/local/ssl/lib ./configure --with-ssl=/usr/local/ssl. I will look into the -ldl test, something is fishy there.

[bagder]

The config.log output shows that it is testing OpenSSL linking without -ldl and returns yes.

My guess this is because the linker then already had found and used your shared one in your default paths and that worked fine to link without -ldl...

[tessus]

@jay

I see. I don't know what we could do to make things better for you, short of moving the zlib detection after OpenSSL. But say we did that, then anyone who has the reverse situation may be affected, and the wrong zlib could be included. Also I think some other libs depend on zlib, and OpenSSL may be one of them depending on how it's built. So maybe it is right to be searched for first.

I use my static OpenSSL library for Apache httpd, PHP, dovecot, sendmail, OpenSSH, and other projects.
All of these projects have other dependencies as well, but they still do not fail to use my openssl, which I specified via a configure option. curl does fail in that regard.

Try doing it manually like LIBS=-ldl LDFLAGS=-L/usr/local/ssl/lib ./configure --with-ssl=/usr/local/ssl.

It did not work. Same error as before.

[tessus]

@bagder

My guess this is because the linker then already had found and used your shared one in your default paths and that worked fine to link without -ldl...

Be it as it may, but it also means it is still broken. I specified the ssl directory. I do not care what a broken process found.

If I tell configure to use my ssl for a package, I can excpect the package to use my ssl. If it doesn't, something is broken.

Also, please note that setting a LD_LIBRARY_PATH or using and rpath linker flag will not work.

I am using a static OpenSSL library, and as you can see from my previous comment, it works just great for all other projects that I compile manually on my server.

[jay]

I use my static OpenSSL library for Apache httpd, PHP, dovecot, sendmail, OpenSSH, and other projects.
All of these projects have other dependencies as well, but they still do not fail to use my openssl, which I specified via a configure option. curl does fail in that regard.

That may be but what exactly do you want us to do here. You have two OpenSSLs and the library path for the one you don't want is used before the one you do.

It did not work. Same error as before.

I'll check on this, it may be because the zlib ldpath is prepended instead of appended for some reason.

[tessus]

That may be but what exactly do you want us to do here. You have two OpenSSLs and the library path for the one you don't want is used before the one you do.

Everybody, who uses their own openssl, also has the system's ssl libraries in the system's library location. (Most people use their own ssl, because the system's ssl is way too old. Still there are a few dependencies that do not allow you to just replace the openssl that comes with the system.)
And most projects (like the ones I mentioned earlier) have other dependencies as well. So how do they handle it? Why is it working there? They use my static openssl library.

What I could ascertain so far is that curl seems to exclusively use dynamic libraries and it doesn't care about the location someone specifies at all. So I still don't understand what your ssl options do or are supposed to do. If they are supposed to change the ssl curl is using, it is not working.

Everybody can use a LD_LIBRARY_PATH hack after the fact, but if one uses a configure option, one shouldn't have to do that. Furthermore, this hack won't work for static libraries.

So what I want is rather simple and should be obvious: I want curl to use the OpenSSL I specified.

[bagder]

Everybody, who uses their own openssl, also has the system's ssl libraries

Many, sure, but far from "everybody". Remember that curl builds and runs on virtually any operating system you can think of. Many do not ship openssl as a system library.

Everybody can use a LD_LIBRARY_PATH hack after the fact, but if one uses a configure option, one shouldn't have to do that.

We don't impose people "this hack", but we don't build libcurl to use hard-coded paths to shared libraries.

this hack won't work for static libraries

Fixing so that you load the right shared library at run-time is not a hack. But as @jay described before: the configure script really sets it out to fix shared builds, as hunting dependencies for static builds is a really tough job we've just not tried to keep up with.

When building statically, the easiest way is to simply provide the extra deps as "LIBS=blablabla ./configure"

[bagder]

@tessus, #1427 might fix this issue for you. Would be nice if you tried it out!

[tessus]

This comment is quite long, so please bear with me.

Many, sure, but far from "everybody". Remember that curl builds and runs on virtually any operating system you can think of. Many do not ship openssl as a system library.

This is true, but when it comes to Linux I have disagree. Every Linux distro (even Linux from Scratch and Gentoo variants) have their own openssl packages. That's because a lot of other packages rely on them. Openssl is an integral part of every Linux distro and it is almost impossible to replace them, except for updates created by the distro packagers (and they won't do upgrades from 1.0.1 to 1.0.2). The only chance you have is to use a newer version in parallel.

but we don't build libcurl to use hard-coded paths to shared libraries.

This is fine, unless people specify their own OpenSSL, in which case you have to hard-code the path to their libs, because you want curl to use the libs they specified. Otherwise the configure options to specify your own openssl is of no use.

Fixing so that you load the right shared library at run-time is not a hack. But as @jay described before: the configure script really sets it out to fix shared builds, as hunting dependencies for static builds is a really tough job we've just not tried to keep up with.

The point is you don't have to hunt for dependencies with static libraries, because you know what is needed. I will explain this a bit further down (in the separate section).

When building statically, the easiest way is to simply provide the extra deps as "LIBS=blablabla ./configure"

As you can see from my previous comments, I tried that and it didn't work.

#1427 might fix this issue for you. Would be nice if you tried it out!

Unfortunately it didn't work. Here's the new config.log.

---

Maybe I'm ignorant, or biased when it comes to standards as a former IBM employee for almost 2 decades, but this is how a package should deal with dependencies and 3rd party libs:

I will use curl/libcurl and openssl as an example.

There are 2 options, when it comes to 3rd party libs: static and dynamic

static

If your package creates a shared object / dynamic library (libcurl), the static openssl libraries must be linked to that shared object (hint: -Wl,--whole-archive linker flag). This is crucial, because libcurl needs openssl and if the builder of libcurl only has static openssl libraries (which they specified in the configure option) you must not reference libraries from the system instead.

The same is true for the binary (curl). The binary must not reference a dynamic openssl library (which was never specified in the configure option), but include the static openssl libraries.

In this case you have a valid curl/libcurl package that uses the specified openssl (3rd party libs).

dynamic

This is more straight forward than dealing with static libs, but it still requires you to reference the libraries which were specified in the configure option. As a builder you define what to use, thus the binay and shared object must reference (hard-coded paths) the libraries that are supposed to be used. Otherwise curl and libcurl will use libraries you have never specified nor wanted to be used.

Again, in this case you have a valid curl/libcurl package that uses the specified openssl libraries.

I really would like your input on this. Doesn't this make sense? There are no drawbacks in this approach. Everything will still be contained and in perfect working order.
It won't change anything for people who compile and use curl/libcurl.