> >>>Does it build?
>
> +gcc -m64 -shared -o libcrypto.so.0.9.7 -Wl,-soname=libcrypto.so.0.9.7
> -Wl,-Bsymbolic -Wl,--whole-archive libcrypto.a -Wl,--no-whole-archive
> -L. -lc
> libcrypto.a(dso_dlfcn.o)(.text+0x68): In function `dlfcn_load':
> : undefined reference to `dlopen'
Double oops:-) Of course there should have been -ldl in appropriate
place in the config-line! See any other Linux line in inject -ldl in the
same spot into the linux64-sparcv9 line.
> adding -ldl before last -m64 flag, build!
Great!
> >>> What does 'ldd apps/openssl' return?
> # LD_LIBRARY_PATH=./ ldd apps/openssl
> libssl.so.0.9.7 => ./libssl.so.0.9.7 (0xfffff8000011c000)
> libcrypto.so.0.9.7 => ./libcrypto.so.0.9.7 (0xfffff80000258000)
> libc.so.6 => /lib64/libc.so.6 (0xfffff800004b8000)
> libdl.so.2 => /lib64/libdl.so.2 (0xfffff8000071c000)
> /lib64/ld-linux.so.2 => /lib64/ld-linux.so.2 (0xfffff80000000000)
Great! Well, as long as we disregard the long-standing OpenSSL
deficiency such as lack of support for multiple-ABI platforms. I mean
one ultimately wants same headers working with either supported ABI and
linker to automatically locate appropriate libraries depending on
-m32/64 option.
> >>>Does 'make test' pass?
> >>>
> yes!, thanks for all
Great!
> related info:
> looking inside openssl-0.9.6b source rpm from Aurora (port of RedHat 7.3
> to sparc), it has this patch (I was not tested linux64-sparcv9, but
> other are distributed with Aurora):
> ...
> +"linux64-sparcv9","gcc:-m64 -DB_ENDIAN -DTERMIO $ENV{RPM_OPT_FLAGS}
> -Wall -DULTRASPARC -DBN_DIV2W::-D_REENTRANT:-ldl:BN_LLONG RC4_CHAR
> RC4_CHUNK DES_UNROLL
I find it hard to believe that it was ever tested/worked. BN_LLONG and
BN_DIV2W is impossible combination on LP64.
A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
