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.

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.

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.

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`

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.

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...

@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.

@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.

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.

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.

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"

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

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.

this is how a package should deal with dependencies and 3rd party libs

Thank you for the lecture. I think this will be much more productive if we instead work on fixing the bugs we see and improve the scripts to work better where we see room for improvement. You're help and assistance in doing that is appreciated.

Now, what I haven't worked out in your config.log and that seems to be the reason why the openssl lib detection finds the "wrong" library is this exact snippet:

configure:21432: checking for LDAP libraries
configure:21496: gcc -o conftest -O2 -Wno-system-headers   -L/usr/lib64   conftest.c -lz  >&5

Where does the -L/usr/lib64 come from? My Linux builds don't get that inserted there. The checking line is output here: https://github.com/curl/curl/blob/master/acinclude.m4#L766 but where is LDFLAGS modified to get that -L path?

Thank you for the lecture.

I thought I should mention it, because curl's build process ignores all of these guidelines.
And if you thought that anything I wrote made sense, I would have looked into changing configure.ac accordingly. I did not want to sound like a smart ass, but have an honest discussion. I say what I think and I hate sugar coating, so I am sorry if I have offended you.

I think this will be much more productive if we instead work on fixing the bugs we see and improve the scripts to work better where we see room for improvement. You're help and assistance in doing that is appreciated.

That is also why I wanted your opinion on what I wrote because I thought an objective discussion would be productive.

Where does the -L/usr/lib64 come from?

I checked my entire system and I do not know where it comes from. It is the standard lib directory on Fedora, Redhat and CentOS, but I did not specify it in an env variable nor is it set system wide.

But I think the autotools are responsible and did that in an earlier step. When configure checks for a library and it is found, the directory of the library is added to LDFLAGS or CPPFLAGS. I have to look into it, but there are ways to adjust the behaviour.

I thought I should mention it, because curl's build process ignores all of these guidelines.

No it doesn't. It did make you sound like a smartass because the configure script is the collected result of twenty years of tweaking and working on dozens of operating systems with dozens of third party libraries with numerous compilers and literally millions of build combinations and you come here with sweeping generalizations and talk, while actually making a working configure script that actually does what everyone wants everywhere is tricky. We can't ignore the edge cases and we can't ignore that everything isn't Linux. We can't ignore that linking with shared vs static libraries is often transparent and that building with static libs is icky. Nobody wants the configure script to be complicated or hard to command, but it is very hard to prevent it from becoming so.

So again, I ask you to instead select specific issues you think is wrong and suggest improvements on those. One by one preferably.

I checked my entire system and I do not know where it comes from. It is the standard lib directory on Fedora, Redhat and CentOS, but I did not specify it in an env variable nor is it set system wide.

Still something does, which effectively breaks configure's ability to detect openssl if it also exists in /usr/lib64 ...

For this case at least, a possible fix might be to prepend the OpenSSL LDFLAGS instead of appending them to the existing ones. Can you see if this makes any difference to you?

--- a/configure.ac
+++ b/configure.ac
@@ -1504,11 +1504,11 @@ if test "$curl_ssl_msg" = "$init_ssl_msg" && test X"$OPT_SSL" != Xno; then
     fi
   fi
 
   dnl finally, set flags to use SSL
   CPPFLAGS="$CPPFLAGS $SSL_CPPFLAGS"
-  LDFLAGS="$LDFLAGS $SSL_LDFLAGS"
+  LDFLAGS="$SSL_LDFLAGS $LDFLAGS"
 
   AC_CHECK_LIB(crypto, HMAC_Update,[
      HAVECRYPTO="yes"
      LIBS="-lcrypto $LIBS"
      ],[

@bagder I think we should consider always appending to LDFLAGS and never prepending, so that the user's LDFLAGS that they set beforehand will take precedence.

As I mentioned earlier it could be zlib pkg-config is returning -L/usr/lib64. This should be fairly simple to check, pkg-config --libs-only-L zlib. Why it's explicitly returning that system path I don't know if that's normal in Linux or what. My pkg-config in Ubuntu 16 doesn't seem to do that for libs in system directories.

I think the problem here, if we have any problem, is that we prepend to LDFLAGS and CPPFLAGS in some cases, and that stops the user's LDFLAGS from coming first and taking precedence. Which would best be solved by this, I think

diff --git a/configure.ac b/configure.ac
index b492a29..0637cd0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -898,8 +898,8 @@ else

     if test "$PKGCONFIG" != "no" ; then
       LIBS="`$PKGCONFIG --libs-only-l zlib` $LIBS"
-      LDFLAGS="`$PKGCONFIG --libs-only-L zlib` $LDFLAGS"
-      CPPFLAGS="`$PKGCONFIG --cflags-only-I zlib` $CPPFLAGS"
+      LDFLAGS="$LDFLAGS `$PKGCONFIG --libs-only-L zlib`"
+      CPPFLAGS="$CPPFLAGS `$PKGCONFIG --cflags-only-I zlib`"
       OPT_ZLIB=""
       HAVE_LIBZ="1"
     fi

If we changed all CPP/LDFLAGS like that then in a case like this the user can specify their own LDFLAGS on the command line to force their libdir order.

As I mentioned earlier it could be zlib pkg-config is returning -L/usr/lib64.

We actually know that isn't the case. If we check @tessus' config.log, we can see that there are several compile commands run after the zlib checks and they don't use that -L option so it is something later. The snippet I showed above (just after the LDAP libraries check) is the first occurance of it but I haven't figured out which particular logic that sets it.

We actually know that isn't the case. If we check @tessus' config.log, we can see that there are several compile commands run after the zlib checks and they don't use that -L option so it is something later.

I disagree. You're forgetting configure compile commands that don't link (eg testing for a header) don't include LDFLAGS. So it could be zlib. I don't know what else it could be except something in acinclude, but there's no mention of LDFLAGS there.

sorry for my late response. I've been very busy today and won't be able to run the tests now, but I will test both of your patches tomorrow (Friday).

I disagree. You're forgetting configure compile commands that don't link

Oh yes, thank you. You're right of course. So it can indeed be the pkg-config for zlib. @tessus could try ./configure --without-zlib to check if this is the case. If using that option makes the openssl detection work... But I agree that this is the most likely explanation that also makes sense.

Here are the results:

@bagder's patch: nope, see config.patch2.log
@jay's patch: nope, see config.patch3.log

original configure.ac with ./configure --without-zlib --with-ssl=/usr/local/ssl: no error in make, but still uses the wrong ssl. see config.wozlib.log

[tessus@atvie01s 0 ~/work/curl-7.53.1/src/.libs]$ ./curl -V
curl 7.53.1 (x86_64-unknown-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: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz UnixSockets HTTPS-proxy
[tessus@atvie01s 0 ~/work/curl-7.53.1/src/.libs]$ ldd curl
        linux-vdso.so.1 =>  (0x00007fff76b2c000)
        libcurl.so.4 => /lib64/libcurl.so.4 (0x000000363c000000)
        libssh2.so.1 => /lib64/libssh2.so.1 (0x0000003847600000)
        liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00000036dda00000)
        libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x0000003847200000)
        libc.so.6 => /lib64/libc.so.6 (0x00000036d2200000)
        libssl.so.10 => /lib64/libssl.so.10 (0x0000003845200000)
        libcrypto.so.10 => /lib64/libcrypto.so.10 (0x0000003843e00000)
        libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x0000003844a00000)
        libkrb5.so.3 => /lib64/libkrb5.so.3 (0x0000003844600000)
        libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x0000003844e00000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000003307e00000)
        libz.so.1 => /lib64/libz.so.1 (0x00000036d3200000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00000036d2600000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00000036d4a00000)
        libsasl2.so.3 => /lib64/libsasl2.so.3 (0x0000003846e00000)
        libssl3.so => /lib64/libssl3.so (0x0000003845e00000)
        libsmime3.so => /lib64/libsmime3.so (0x0000003846a00000)
        libnss3.so => /lib64/libnss3.so (0x0000003845600000)
        libnssutil3.so => /lib64/libnssutil3.so (0x0000003845a00000)
        libplds4.so => /lib64/libplds4.so (0x00000036d8e00000)
        libplc4.so => /lib64/libplc4.so (0x00000036d8a00000)
        libnspr4.so => /lib64/libnspr4.so (0x00000036d9200000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00000036d2a00000)
        /lib64/ld-linux-x86-64.so.2 (0x00000036d1e00000)
        libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x0000003844200000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00000036d5e00000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003846600000)
        librt.so.1 => /lib64/librt.so.1 (0x00000036d4200000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00000039f5c00000)
        libfreebl3.so => /lib64/libfreebl3.so (0x0000003846200000)
        libpcre.so.1 => /lib64/libpcre.so.1 (0x00000039f6000000)
        liblzma.so.5 => /lib64/liblzma.so.5 (0x00000036d3600000)

Right, my patch won't work alone since your zlib pkg-config probably messes up things and we know only --without-zlib won't work since the -ldl detection is broken which my patch tries to fix.

My patch (#1427) plus --without-zlib however could have a chance of actually detecting that static openssl of yours...

Oh, or alternatively you could try this without my patch:

LIBS="-ldl" ./configure --without-zlib --with-ssl=/usr/local/ssl

LIBS="-ldl" ./configure --without-zlib --with-ssl=/usr/local/ssl

configure finds the libraries, but make links against the dynamic libraries from the system.

see config.addLIBS.log

checking for OpenSSL headers version... 1.0.2 - 0x100020bfL
checking for OpenSSL library version... 1.0.2
checking for OpenSSL headers and library versions matching... yes

the version and ldd output is the same as in #1420 (comment)

Does curl use the right libcurl when you run src/curl -V?

Yes, it does.

src/curl -V
curl 7.54.1-DEV (x86_64-unknown-linux-gnu) libcurl/7.54.1-DEV OpenSSL/1.0.2k 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 TLS-SRP UnixSockets HTTPS-proxy

I also did a DESTDIR=/tmp/hello make install and the resulting binary there does not use my openssl.

You can fix that either by disabling shared build in libcurl

Ok, I can try to disable building a shared curl lib. In that case curl should be linked against the static one, right? But this only solves part of the issue, I think.

One question: if I want my static openssl libraries be used, shouldn't the static openssl libraries be included in the dynamic libcurl? I mean, let's say I didn't have any dynamic openssl libraries on the system, how would a dynamic libcurl (which is built by default) make use of openssl?

LDFLAGS="-Wl,-rpath,/usr/local/lib

Isn't the rpath only used for dynamic libraries?

LDFLAGS="-Wl,-rpath,/usr/local/lib

I see what you are saying:

LD_LIBRARY_PATH=/tmp/hello/usr/local/lib /tmp/hello/usr/local/bin/curl -V
curl 7.54.1-DEV (x86_64-unknown-linux-gnu) libcurl/7.54.1-DEV OpenSSL/1.0.2k 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 TLS-SRP UnixSockets HTTPS-proxy

Still my question remains: if I wanted my static openssl libraries be used, shouldn't the static openssl libraries be included in the dynamic libcurl? I mean, let's say I didn't have any dynamic openssl libraries on the system, how would a dynamic libcurl (which is built by default) make use of openssl?

LIBS=-ldl LDFLAGS=-L/usr/local/ssl/lib CPPFLAGS=-L/usr/local/ssl/lib ./configure --with-ssl=/usr/local/ssl

Your CPPFLAGS should be CPPFLAGS=-I/usr/local/ssl/include

LD_LIBRARY_PATH=/tmp/hello/usr/local/lib /tmp/hello/usr/local/bin/curl -V
curl 7.54.1-DEV (x86_64-unknown-linux-gnu) libcurl/7.54.1-DEV OpenSSL/1.0.2k zlib/1.2.8 libssh2/1.5.0

Your curl -V is now showing OpenSSL/1.0.2k.

if I wanted my static openssl libraries be used, shouldn't the static openssl libraries be included in the dynamic libcurl? I mean, let's say I didn't have any dynamic openssl libraries on the system, how would a dynamic libcurl (which is built by default) make use of openssl?

Yes, that's correct. I built a shared libcurl with static OpenSSL 1.0.2 in Ubuntu 16 x64 and do not have the same problem that you do, ie my system openssl was not used.

I wonder if because you have libssh2 if that's using your dynamic system OpenSSL and that's why you see it in ldd. Try running readelf -d ./lib/.libs/libcurl.so.4.4.0 | grep -i needed and check ldd -v ./lib/.libs/libcurl.so.4.4.0 for libssh2 section and see if that's what's using system openssl.

readelf -d ./lib/.libs/libcurl.so.4.4.0 | grep -i needed
 0x0000000000000001 (NEEDED)             Shared library: [libssh2.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [liblber-2.4.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libldap-2.4.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

hmm, libssl also needs the system's libcrypto...

        /lib64/libssh2.so.1:
                libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6
                libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
                libc.so.6 (GLIBC_2.3) => /lib64/libc.so.6
                libc.so.6 (GLIBC_2.3.4) => /lib64/libc.so.6
                libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
                libcrypto.so.10 (libcrypto.so.10) => /lib64/libcrypto.so.10

        /lib64/libssl.so.10:
                libk5crypto.so.3 (k5crypto_3_MIT) => /lib64/libk5crypto.so.3
                libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6
                libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
                libc.so.6 (GLIBC_2.17) => /lib64/libc.so.6
                libc.so.6 (GLIBC_2.3.4) => /lib64/libc.so.6
                libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
                libkrb5.so.3 (krb5_3_MIT) => /lib64/libkrb5.so.3
                libcrypto.so.10 (OPENSSL_1.0.1_EC) => /lib64/libcrypto.so.10
                libcrypto.so.10 (libcrypto.so.10) => /lib64/libcrypto.so.10
        /lib64/libcrypto.so.10:
                libdl.so.2 (GLIBC_2.2.5) => /lib64/libdl.so.2
                libc.so.6 (GLIBC_2.3) => /lib64/libc.so.6
                libc.so.6 (GLIBC_2.7) => /lib64/libc.so.6
                libc.so.6 (GLIBC_2.14) => /lib64/libc.so.6
                libc.so.6 (GLIBC_2.4) => /lib64/libc.so.6
                libc.so.6 (GLIBC_2.17) => /lib64/libc.so.6
                libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
                libc.so.6 (GLIBC_2.3.4) => /lib64/libc.so.6

sorry, clicked the wrong button

forget my previous comment that libssl also needs the system's libcrypto
of course it does. long day.

Your output shows shared libcrypto and libssl are not direct dependencies of libcurl. libssh2 is using shared libcrypto. If you go through the ldd -v output you can probably find what is using shared libssl.

It seems this has been largely a ghost chase lately and libcurl does indeed link with the correct openssl. A reminder that curl -V might be a better output than ldd for this.

@tessus do you have any more information on this?

it seems that libssh wants to use libcrypto. I've been trying to get rid of this dependency, but is seems more complicated than I thought.
I'll keep you in the loop. I hope I can do more testing tomorrow.

libssh2 can be built with different backends as well, and one of them is openssl/libcrypto indeed.

just tried to do the same thing with 7.54.0 and I get this during config:

checking for OpenSSL headers version... 1.0.2 - 0x100020bfL
checking for OpenSSL library version... 1.0.1

with 8b03436 both show 1.0.2.

(This git hash above marks the time when jay or you asked me to try from git master.)

Since 338f427 (added after 7.54) what you specify in CPPFLAGS and LDFLAGS should always come first. You could report the pkg-config adding -Lsyspath problem to Fedora but I think your OS is EOL (if judging by the fc20 it's Fedora 20). FWIW Fedora 25 doesn't have this problem.

The reason why I wanted to compile curl myself is because my OS is EOL and it's using ancient openssl and curl versions.
Now I can't compile it properly, because the OS itself has problems. ARGH!!!! Really?

I'm at a loss here. Apparently I can only get it working when using a package from a recent distro. Not really what I expected, but I guess I will have to live with it.

I know, it's not your fault. I'm just very disappointed.

I don't understand how you can't compile curl properly though. The changes already made should allow you to compile it the way you want. As mentioned you'll have to use LIBS/LDFLAGS/CPPFLAGS and I'd guess in your case with static openssl in /usr/local/ssl and curl install dest /usr/local it's going to look like this:

LIBS=-ldl \
CPPFLAGS=-I/usr/local/ssl/include \
LDFLAGS="-L/usr/local/ssl/lib -Wl,-rpath,/usr/local/lib" \
./configure --with-ssl=/usr/local/ssl

From your more recent output I see that libcurl does not directly depend on old dynamic OpenSSL, so it's some other library. If you need to build a revision earlier than 338f427 (eg 7.54) then you can cherry pick that commit.

Yep, it works with 8b03436 but not with git master. So you must have reverted something in between.

I think you misunderstood my earlier comment. It was workig at some point. That was with commit 8b03436. Then I was still using this commit for all the following tests.

Now I tried the same with git master, and it is not working anymore. So whatever you changed to make it work, is now gone, otherwise it would still work....

I think you misunderstood my earlier comment. It was workig at some point. That was with commit 8b03436. Then I was still using this commit for all the following tests.

Ah, I did. You've got me stumped. Check your master pointer, see if it's in sync with upstream/master, and that you run ./buildconf after checkout. There have only been two changes to configure since then, 4da846a and 6c7f1f7 but I don't see how they could affect this.

I actually used the 7.54.0 distribution tarball from https://curl.haxx.se/download/curl-7.54.0.tar.gz

I have two directories. one is the tarball 7.54.0 and the other is the above commit point. and if I run the same command I in the 7.54.0 dir, I get this:

checking for OpenSSL headers version... 1.0.2 - 0x100020bfL
checking for OpenSSL library version... 1.0.1

in the other directory, I get this:

checking for OpenSSL headers version... 1.0.2 - 0x100020bfL
checking for OpenSSL library version... 1.0.2

I'll try to check the config.log and try to figure out what's happening. but I'm a bit tired today. I'll do it tomorrow.

maybe you can re-open this issue until we have resolved this?

As far as I can tell this is resolved, if you can demonstrate there is still an issue that is reproducible in a commit later than 338f427 then we can reopen.