Hello Chris,
We have run into a similar problem with our NSAPI module on Solaris.
When using the SUN compiler, we found the following option that solves this
problem. Below is the explanation from the man page.
Regards,
Jack
-B symbolic
In dynamic mode only. When building a shared
object, binds references to global symbols to
their definitions, if available, within the
object. Normally, references to global symbols
within shared objects are not bound until run-
time, even if definitions are available, so that
definitions of the same symbol in an executable
or other shared object can override the object's
own definition. ld will issue warnings for
undefined symbols unless -z defs overrides.
---------------------------------------------------------------------
Jack Kabat [EMAIL PROTECTED]
ValiCert, Inc.
1215 Terra Bella Ave. http://www.valicert.com
Mountain View, CA 94043-1833
>-----Original Message-----
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of Chris Bongaarts
>Sent: Wednesday, May 26, 1999 2:30 PM
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]
>Subject:
>
>
>As Tri Phan once put it:
>
>> I'm using openSSL-0.9.1c's EVP_BytesToKey to generate a DES
>> encryption key for EVP_des_cbc() and EVP_des_ede3_ofb(). I can run
>> my application sucessfully as an NT application, NSAPI DLL within
>> NES 3.6.1 (on NT), Sun Solaris application, or Sun Solaris shared
>> object without NSAPI. The same encyption is derived for my given
>> password, salt, and iteration count.
>>
>> However, when I run my application as an NSAPI share object within
>> Netscape Enterprise Server (NES) 3.61 on Solaris, a different DES
>> encryption key is derived for the same password, salt, and iteration
>> count.
>
>Keep in mind when working with dynamically loaded object files that
>the symbols already found in the program will override any symbols
>present in your loaded code (or anything linked to it). NS Enterprise
>Server has several symbols that conflict with the symbols in
>ssleay/openssl. When such a conflict exists, the Netscape version of
>the routine (which likely has different calling conventions or
>semantics) is used in preference to the OpenSSL version.
>
>I ran into this problem when trying to use SSL calls from within an
>NSAPI. I solved it by hacking the OpenSSL source to tweak the names
>of the colliding routines, changing *_Update to *_update:
>
>find /src/openssl-0.9.1c -type f \( -name '*.[ch]' -o -name
>'*.org' \) -exec egrep -s '(MD2|MD5|SHA1)_Update' {} \; -print |
>xargs perl5 -i -pe 's/(MD2|MD5|SHA1)_Update/$1_update/g;'
>
>As the example3.c file appears to use MD5 for the BytesToKey routine,
>this is the likely culprit.
>
>%% Christopher A. Bongaarts %% [EMAIL PROTECTED]
>%% ADCS - Internet Enterprise %% http://umn.edu/~cab
>%% University of Minnesota %% +1 (612) 625-1809
>______________________________________________________________________
>OpenSSL Project http://www.openssl.org
>User Support Mailing List [EMAIL PROTECTED]
>Automated List Manager [EMAIL PROTECTED]
>
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
