But I'll take up the cue and see what we can do that works
everywhere.
Then it would have to be the least common denominator: 97, 98, 100 or
independent numbers such as 1, 2, 3.
The above was referring to file suffixes. It should be noted that
there're platforms, which has no notion of versioning through file
suffix, most notably Windows. The only way to get it working on Windows
and similar platforms [if any] would be to encode the version into .DLL
file name, e.g. crypto098.dll, ...099.dll, ...100.dll [note that at
least in Windows context it doesn't prevent us from calling
corresponding .lib import library for crypto.lib]. In other words least
common denominator would be embedding version number into shared object
file name, not its extension. As it's unlikely to be accepted that Unix
developers would have link with -lcrypto100, we're stuck with multiple
versioning schemes in either case:-(
On a side note in respect to problem with cross-polution of global name
table from different versions of OpenSSL. Windows would be free from
this, because import tables are private to every mapped module, meaning
that two modules, one linked with 0.9.7 and another with 0.9.8, would
not interfere with each other. Just a side note! A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
