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

Closed
tiwoc opened this Issue Jan 28, 2016 · 8 comments

Projects

None yet

5 participants

@tiwoc
tiwoc commented Jan 28, 2016

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
Member
bagder commented Jan 28, 2016

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
Member
bagder commented Feb 11, 2016

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

@tiwoc
tiwoc commented Feb 11, 2016

Sounds good to me.

@danielshahaf
Contributor

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
Member
ghedo commented Feb 19, 2016

@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
Member
ghedo commented Feb 19, 2016

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
Member
jay commented Feb 19, 2016

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
Member
ghedo commented Feb 20, 2016

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

@bagder bagder added a commit that closed this issue Mar 27, 2016
@bagder bagder Makefile.am: skip the scripts dir
Skipping the scripts dir is primarily done for 'make install' so that it
does not attempt to install the zsh completion script as we've not yet
found a proper way to do/run that at install time.

By leaving the script dir's Makefile in place, a user can still opt to
run make install manually in there.

Closes #620
ccfa840
@bagder bagder closed this in ccfa840 Mar 27, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment