zsh.pl fails because libssl.so.1.0.0 cannot be found

[tiwoc]

Environment:

• cURL from git, tag curl-7_47_0
• OS: Fedora 23, x86_64
• OS-provided libssl: /usr/lib/libssl.so.10 (symlink), /usr/lib/libssl.so.1.0.2e (binary)
• my own OpenSSL build: 1.0.1, installed to /path/to/openssl (which has the necessary lib/ and include/openssl subdirectories)
• relevant cURL configure flag: --with-ssl="/path/to/openssl"

Configuration and building work fine up to the point when the zsh completion is generated. The latter fails:

Making all in scripts
make[1]: Entering directory '/path/to/curl/scripts'
/usr/bin/perl ./zsh.pl ../src/curl > _curl
../src/curl: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory
curl returned 127 with output:
Makefile:548: recipe for target '_curl' failed

I can fix the build by exporting LD_LIBRARY_PATH="/path/to/openssl/lib" before running make. Is this intended or should the build system set the LD_LIBRARY_PATH itself if I provide configure with the path to my OpenSSL installation? I'm asking because configure outputs the following, which seems to be limited to the configure run itself:

configure: Added /path/to/openssl/lib to LD_LIBRARY_PATH

The failure is detected by make since 92a2041. Before that, it would fail silently so that I didn't recognize the issue in 7.46.0.

[bagder]

This issue was also mentioned here: fb7cbf7#commitcomment-15705608

I don't have an immediate fix for this that doesn't just bring back the old problem again...

[bagder]

I vote that we remove this action from being done by default by the makefile as it produces problems no matter what.

[tiwoc]

Sounds good to me.

[danielshahaf]

Perhaps zsh.pl could run during make install and use the freshly-installed curl binary (${prefix}/bin/curl, or more accurately, ${bindir}/curl)?

(Sorry for late response, I haven't seen the issue until just now.)

[ghedo]

@danielshahaf I don't think that would solve the problem. We already use the just built curl binary, but that doesn't work if e.g. some of the shared libraries used are in non-standard paths.

This specific problem can be solved by passing LD_LIBRARY_PATH from autoconf to automake like any other AC_SUBST variable. Then we can use them when invoking the curl binary in the Makefile.

In any case I'm ok with disabling the zsh generation by default too.

[ghedo]

I imagine this also applies to the test suite, but since that is run as a separate target it can just be not run at all. While the zsh generation is run as part of the main build.

Another possible solution would be to just ignore the result from zsh.pl and check if the _zsh file has been generated before trying to install it, but I don't really like this kind of silent failures.

[jay]

I think I've already asked this somewhere but for you guys using autotools isn't libtool supposed to do all this automatically? In other words it creates some sort of stub and then loads the right shared libraries before they're installed?

[ghedo]

@jay If you look at configure.ac the non-standard LD_LIBRARY_PATH handling is done "manually", that is, it's not handled automatically by autotools. So it needs to be done manually for automake too.

libtool only handles LD_LIBRARY_PATH for libraries internal to the project (that is libcurl), but if that library or executable depend on a library external to the project (e.g. libssl) then libtool depends on the system linker to know where to find it. And if that library is in non'standard paths (like in this case) then everything just breaks down.

Of course there are ugly hacks like rpath that could solve this, but that's not really a proper solution.