Re: problem from out of the blue: can't connect via libcurl
Date: Fri, 11 Dec 2009 09:53:53 -0800 (PST)
--- On Thu, 12/10/09, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Thu, 10 Dec 2009, Pete Wilson wrote:
> > client: error while loading shared libraries:
> libcurl.so.4: cannot open shared object file: No such file
> or directory
> This happens because your run-time linker - that is used to
> find all the libs (which btw are .so files when they are
> shared) when you invoke your application - doesn't find your
> locally installed library.
> You can fix this several ways. One is to use the -rpath
> option with ld when you link your app and another is to set
> the LD_LIBRARY_PATH environment variable to point to the
> lib's dir.
The original problem was that I got "protocol not supported: https" from libcurl on my Linux ISP. It appears there was/is something funny about libcurl.a (libcurl.so.3).
Daniel advised me to build libcurl from scratch locally, in my directory, and use that. I followed his advice, starting with curl-7.19.7.tar.gz found on:
It was a treat -- libcurl built without any problems in about ten seconds with with output = libcurl.a symlinked to libcurl.so.4.1.1.
The next issue was that the run-time loader could not find the libcurl.so that's referenced in my executable. That's the problem at the top of this email.
To that, Daniel responded as above. I first tried -rpath but Linux then wanted to use /lib64/ld64.so as the run-time loader. There's no such file on my server.
So I took the second approach: I set the environment variable LD_LIBRARY_PATH to point to the libcurl.a directory.
*** Please note I have to set LD_LIBRARY_PATH every single time before my app runs.
The one and only problem with that was that my app, called 'client', will sometimes be run with no way to set LD_LIBRARY_PATH beforehand. So I renamed the executable 'client' to be 'client.out' and wrote a tiny script named 'client' that sets up LD_LIBRARY_PATH, then exec( )s client.out.
The one small remaining issue is that libcurl reports:
* getaddrinfo(3) failed for the.remote.server.com:443
* Couldn't resolve host 'the.remote.server.com'
* Closing connection #0
I get around that by using the IP address of the.remote.server.com. I'll worry about that getaddrinfo( ) problem later.
For now, it works great!
What did I learn? Just like everybody else, I *knew* that rebuilding libcurl.a would be a nightmare of undefined symbols, missing files, and all the rest of the cruft that comes with the usual 85%-done, 10%-documented (and that 10% way out of date) free software package.
Not so! libcurl built flawlessly the first time. And it's written in plain, well-designed, modular, straightforward, easily-understood C! Like I say, it was a treat.
Daniel, thank you so, so much!
And now on to multi, leaving (pfah!) easy by the wayside :-)
List admin: http://cool.haxx.se/list/listinfo/curl-library
Received on 2009-12-11