Configuration and building work fine up to the point when the zsh completion is generated. The latter fails:
Making all in scripts
make: 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.
The text was updated successfully, but these errors were encountered:
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.
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?
@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.