On May 22, 2005 08:17 am, Corinna Vinschen wrote:
> now that I had first contact with engines, I thought it might be
> better to give them some testing.

Yes, thanks for doing so :-)

> However, I found that lib4758_cca.so and libncipher.so don't load,
> because the engine id differs from the engine name.
>
> The engine id of lib4758_cca.so is "4758cca" instead of "4758_cca",
> the id of libncipher.so is "chil" instead of "ncipher".

Yes, this is unfortunate. I've just committed a fix to the 0.9.8-stable 
and HEAD branches that will tolerate both names when binding as a dynamic 
engine. It'd still be preferable to change the names of the generated 
shared libraries too so that the default name with static and dynamic use 
is the same (ie. using 'chil' for a built-in engine and 'ncipher' for an 
external engine make much sense). Right now the existing change will just 
allow you to dynamically bind using 'ncipher'. Please try out the next 
nightly snapshot if you're able.

Richard, any idea of how safe it would be to change the names of the two 
shared librariesy at this stage of the 0.9.8 betas? I'm reluctant to 
charge ahead for fear of breaking the strange builds (win32, VMS, 
cygwin, ...) Oh that reminds me too - the build I tried earlier got a 
duplicate symbol in libcrypto and so "make install" ended up without the 
shared-library version of libcrypto installed - everything seemed to work 
anyway (presumably everything linked to libcrypto.a instead) so this goes 
unnoticed quite easily. I'll try to dig up more info tomorrow when I get 
back to the machine I was on.

Cheers,
Geoff

-- 
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/

Greedy Genghis George, Guru of God and Guns.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [email protected]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to