> From: Marchelm Bomers [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 02, 2001 9:01 PM
> cc -o bntest -I../include -DDSO_DLFCN -DHAVE_DLFCN_H -std1 -tune host
> -O4 -readonly_strings bntest.o -L.. -lcrypto
> ld:
> Unresolved:
> BN_CTX_init
> BN_init
> BN_RECP_CTX_init
> BN_RECP_CTX_free
> BN_RECP_CTX_set
> BN_div_recp
> BN_bntest_rand
BN_CTX_init and friends are defined in bn_*.o, which are included in the archive version of libcrypto (libcrypto.a) and also linked into the shared object version (libcrypto.so on ELF systems - I don't know what naming convention Tru64 uses for shared object) if you're building shared objects.
When you link bntest above, you should be picking up ../libcrypto.a, or possibly Tru64's shared object version in the same directory (depending on linker default behavior), thanks to the "-L.. -lcrypto" on the command line.
However, typically ld's -L option appends the specified directory to the search path, which means ".." is the *last* directory to be searched for libcrypto.a.
Does your system have another libcrypto.a, or shared object equivalent, that ld might be finding?
Michael Wojcik
Principal Software Systems Developer, Micro Focus
Department of English, Miami University
