--- On Thu, 12/10/09, Daniel Stenberg <[email protected]> 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.

SOLVED!

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:

  http://curl.haxx.se/download.html

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 :-) 

-- Pete

 

  



 










      
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Reply via email to