On 2009.10.19 at 17:13:19 +0100, Steve Hay wrote:
> >
> > Note that if you are trying to build 64-bit application on solaris, it
> > should link with /lib/amd64/libcrypto.so rather than /lib/libcrypto.so
> > (on Solaris 64-bit libraries are stored in the ${prefix}/lib/`isainfo
> > -k` rather than just ${prefix}/lib, where 32-bit libraries are kept.
> > Command isainfo -k returns amd64 for 64-bit Solaris Intel and sparcv9
> > for 64-bit Solaris Sparc.
>
> Yes, it's doing a 64-bit build, so it's the amd64/ or sparcv9/ bit
> that's missing: it only checks in ${prefix}/lib64 and ${prefix}/lib at
> the moment.
>
> Note that it is the location of the libcrypto.a file that I'm after (not
> the .so file). Does that change anything?
Yes, it does. Sun since Solaris 10 discourages static linking by all
means it can. I've encountered this problem when I want to create
static version of gostsum to check our product integrity. I've thought
that the less runtime dependencies my program have, the less chance
attacker have to hide his traces.
But I have to compile and link solaris version on Solaris 9, because
solaris 10 doesn't ship libc.a.
So, Solaris 11 just doesn't ship static libraries for OpenSSL.
Link with .so.
> Where would the 'openssl' executable be in that case? Is there a
> /usr/sfw/bin? The build script looks for a 'openssl' somewhere and takes
Yes, it is here. But it wouldn't help you with Solaris 11, where openssl
is in /usr/bin, but libraries in /lib, unless you'll do ldd on openssl
binary.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
