cURL / Mailing Lists / curl-library / Single Mail


RE: trying to link directly in executable *.x

From: CHEN Xiaolei A <>
Date: Wed, 18 Aug 2010 14:36:32 +0800

Thanks a lot, Dan.

-----Original Message-----
From: [] On Behalf Of Dan Fandrich
Sent: 2010818 14:29
Subject: Re: trying to link directly in executable *.x

On Wed, Aug 18, 2010 at 11:34:18AM +0800, CHEN Xiaolei A wrote:
> After I succeeding in compiling libcurl-7.21.0, the "lib" directory
> lists as
> follow:
> -rw-r--r-- 1 someone bjumts 1718756 Jul 1 17:42 libcurl.a
> -rwxr-xr-x 1 someone bjumts 1166 Jul 1 17:42
> lrwxrwxrwx 1 someone bjumts 16 Jul 1 17:42 ->
> lrwxrwxrwx 1 someone bjumts 16 Jul 1 17:42 ->
> -rwxr-xr-x 1 someone bjumts 1384988 Jul 1 17:42
> drwxr-xr-x 2 someone bjumts 4096 Jul 1 17:42 pkgconfig
> And under my design environment, I only use actual dynamic lib
> ( I wrote a demo program, it can compile and link
> successfully.
> But before executing it, I use "ldd" command, it displays as follow:
> > ldd FTPSession.x
> => (file not found)
> => (file not found)
> => /usr/lib/
> => /lib/
> ......
> so when the program is begin execution, the name it want to find to
> load dynamic lib is -it's a symbol link refer to actual
> dynamic lib ( But I don't need that, I hope the name
> it want to find is
> My question is:
> 1) What should I do? If I need only actual dynamic
> lib( after compiling and installing, and when
> executing a program, it can find actual dynamic lib name(, not the symbol link

When you link against libcurl, the linker uses the SONAME that's built-in to the .so file to know what to link to at run-time. The SONAME is, which is the most general name that by convention maintains binary compatibility in future releases. You might be able to work some trickery with linker flags to use a different name, like, but why? If you ever want to upgrade libcurl to a new release to fix a security problem or bug, the new name is guaranteed to be different (e.g. and your program will fail to run. If you insist on having no hard or symbolic links to the library, you'd probably be better off calling the library file instead of
If you are never going to upgrade libcurl without also upgrading the application, then just statically link it instead.

> 2) As we known, libcurl compiling is depending on libssh2, so for my
> question 1), Is there any change when compiling libssh2?

The dynamic library itself calls upon the SONAME of libssh2, which is So you're going to encounter the same issue there if you don't want any links to libraries.

> 3) Does libcurl provide some interfaces to download a whole directory
> recursively from a FTP server?

Recent versions of libcurl support CURLOPT_WILDCARDMATCH that may do what you want. Otherwise, you'll have to have the directory recursion logic in the app.

>>> Dan
List admin:
List admin:
Received on 2010-08-18