Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

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

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

tiwoc opened this issue Jan 28, 2016 · 8 comments

Comments

@tiwoc
Copy link

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
Copy link
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
Copy link
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
Copy link
Author

tiwoc commented Feb 11, 2016

Sounds good to me.

@danielshahaf
Copy link
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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
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
Copy link
Contributor

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 closed this as completed in ccfa840 Mar 27, 2016
@lock lock bot locked as resolved and limited conversation to collaborators May 7, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@ghedo @bagder @jay @tiwoc @danielshahaf