linking against shared libraries

Greetings!
Here's a hopefully simple question:

% cat test.c
#include <openssl/ssl.h>

int main(void)
{
/* just put some stuff here for the linker to link against the
libssl */
SSL_METHOD *meth = SSLv23_client_method();
return EXIT_SUCCESS;
}

% gcc -I /usr/local/ssl/include test.c -L /usr/local/ssl/lib -R /usr/
local/ssl/lib -lssl
% ldd a.out | grep libssl
libssl.so.0.9.8 => /usr/local/ssl/lib/libssl.so.0.9.8

% ls -l /usr/local/ssl/lib/*ssl*
lrwxrwxrwx 1 root root 15 Oct 2 15:38 /usr/local/ssl/
lib/libssl.so -> libssl.so.0.9.8
-r-xr-xr-x 1 bin bin 272264 Mar 20 2007 /usr/local/ssl/
lib/libssl.so.0.9.8

The question is: why does the linker link against libssl.so.0.9.8 and
not against the symlink, which is supposed to be a generic libssl
symlink in case we upgrade libssl? Why is the symlink even there if
it's ignored?

[email]noident@my-deja.com[/email] writes:
[color=blue]
> Here's a hopefully simple question:[/color]

The answer is not so simple. To understand what's happening, read
about external library versioning here:

[url]http://docs.sun.com/app/docs/doc/817-1984/6mhm7pl20?a=view[/url]
[color=blue]
> The question is: why does the linker link against libssl.so.0.9.8 and
> not against the symlink...
> Why is the symlink even there if it's ignored?[/color]

Who told you it's not "linking against symlink", and that symlink
is ignored?

In fact it *is* using the symlink. You can verify that with

gcc ... -Wl,--verbose # Linux
gcc ... -Wl,-D,files # Solaris

Or remove the symlink, and observe that your link will now fail.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

OK, that explains it.
I wrongly assumed that the symlink was there for the runtime, but it's
there for the linker to follow at the link time.
Thank you.