On Mon, 4 Dec 2006, Ginn Chen wrote:
hi Ginn,
> I want to my library work smoothly on both Solaris 10 and Nevada.
>
> My library links with libssl and libcrypto, I use -L/usr/sfw/lib
> -R/usr/sfw/lib
> -lssl -lcrypto.
> I got libssl.so.0.9.8 => /usr/sfw/libssl.so.0.9.8 when I ldd my library.
> But Solaris 10 has libssl.so.0.9.7 not libssl.so.0.9.8.
the real filename is put into the ELF object header, not the name of
a symbolic link so that's the reason why you have that suffix there. BTW
check out whatever you want to see for example 'libc.so.1' in ELF header and
not 'libc.so' which is a symbolic link, too.
$ ldd /bin/ls
libsec.so.1 => /lib/libsec.so.1
libc.so.1 => /lib/libc.so.1
libavl.so.1 => /lib/libavl.so.1
libm.so.2 => /lib/libm.so.2
> So my program can't run on Solaris 10 unless user creates a symbol link
>for libssl.so.0.9.8.
and then it's quite probable that it will crash, depending on what
part of OpenSSL your app uses. 0.9.8/0.9.7 are not binary compatible, that's
the reason why you have that suffix in ELF object header so that you don't
mix them. Never link 0.9.8 to 0.9.7 or vice versa.
> If I dump -vL libssl.so.0.9.8, I got
> SONAME libssl.so.0.9.8
> Maybe it's the cause.
>
> How can I solve this issue or workaround it?
rebuild separately for S10 and Nevada. Some systems ship both 0.9.7
and 0.9.8 versions (many linux distros), some not (for example. *BSD
systems as far as I know). Solaris don't either.
simple workaround should be to copy libssl.so.0.9.8 and
libcrypto.so.0.9.8 from Nevada to S10.. Or the other way around - put 0.9.7
files to Nevada. Note that neither of them is a supported configuration. I
suggest to rebuild you app for S10 (on S10).
cheers, Jan.
--
Jan Pechanec
