Hi Andrew,
Normally I'd just reply to this on the openssl-users list, but this may
actually be of interest (or at least mildly amusing) to OpenSSL developers
too ...
On Wed, 18 Oct 2000, Andrew Rickard wrote:
[snip]
> I've run into some symbol clashes with openssl v.0.9.5 and linking
> with the iPlanet Web Server. Below is a partial list of symbols from
> opensslv.0.9.5 which clash with iPlanet. Just wanted to inform
> developers and users of this issue. My solution to this dilema was to
> rename these symbols in the openssl.v.0.9.5 code.
[snip]
> SHA1_Init
> SHA1_Update
> SHA1_Final
> SHA1_Transform
>
> SHA_Init
> SHA_Update
> SHA_Final
> SHA_Transform
> SHA
[snip]
I just tested an idea for a way around this and it seems to work ... I
only tested the SHA cases but I'd assume it would generalise (but you may
have to put the OSSL macro inside a common header file). In the
crypto/sha/sha.h header file, just before the declarations of the function
I did;
#define OSSL(a) OSSL_##a
then I changed all the function declarations to use this macro, eg.
void SHA_Init(SHA_CTX *c);
void SHA_Update(SHA_CTX *c, const void *data, unsigned long len);
became;
void OSSL(SHA_Init)(SHA_CTX *c);
void OSSL(SHA_Update)(SHA_CTX *c, const void *data, unsigned long len);
then afterwards, (without the #ifndef NO_SHA*** stuff, it's not required),
added matching conversions back, eg;
/* Conversion macros so existing unprefixed names can be used in source */
#ifndef DO_NOT_CONVERT_API_SYMBOLS
#define SHA_Init OSSL(SHA_Init)
#define SHA_Update OSSL(SHA_Update)
#endif
The result is that OpenSSL gets compiled with all the "SHA***" functions
compiled with symbols of the form "OSSL_SHA***". However the other
conversions back mean that all the existing source code can be compiled
using the original SHA*** names because the precompiler converts them on
the fly ... the result should allow you to only make this change in the
headers and then the library, applications, and your C code should compile
and link using the existing source code, but the new symbols will be
generated and used by the compiler/linker.
As to whether this stuff could be reformulated in a way that would be
usable in the base code itself for the whole library ... I have no idea.
The merest thought of the consequences it might have for the win32 or vms
builds gives me shivers (libeay.num and "make update" ... eurgh). However,
this symbol conflict stuff has come up once or twice and it would
certainly be handy if we had some way of avoiding it like this (ie.
scoping all compiled symbols within some hopefully conflict-free prefix,
eg. "OSSL" or whatever - this is something normally taken for granted in
other APIs).
Thoughts anyone?
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
