In article <[EMAIL PROTECTED]> you wrote:
> At last got a moment to test the openssl package. My initial intention
> was to generate an RPM package, but I found a little? problem, although
> dont know if it's my fault.
> Modified patches used with SSLeay-0.9.0b so that it could be RPMized,
> and when making shared libraries, I had duplicated symbols in bn_asm
> when linking libcrypto.so, and then undefined comp_lib symbols when
> building ssleay executable.
> Hacking into shlib/linux.sh (x86 Redhat 5.1, latest patches and such),
> found out that bn_asm was included twice (former as assembler object, and
> latter as C object, I guess), that explains the first thing, and I'd
> say the second one.
> I specified bn_asm.c as expection in process_subdir() and everything
> went ok. Now, I'm issuing a make after shlib/linux.sh...
> All seems to be correctly compiled. Moving towards RPM...
The shared library support in SSLeay/OpenSSL is still very ugly and
inconsistent. Actually in the future is should be integrated back into the
Configure script and the Makefiles as it's the case for Apache. When you've
good suggestions send them to us. My current idea is at least a "shlib" or
"dso" argument for Configure which triggers the generation of libcrypto.so and
libssl.so instead of libcrypto.a and libssl.a. Ben, you're already working the
Configure stuff, have you perhaos done something in this area, too?
In the meantime we've to at least fix the above double-definition problem. It
seems to be caused by Eric latest bn_mulw -> bn_asm changes.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
