Clifford Heath wrote:
>
> > Easiest is to ignore it: SSLeay didn't do anything about this.
>
> Not true - I remember Eric announcing at some time that from the "next
> version" on, there should be no further arbitrary incompabibilities between
> binaries, because he built the .DEF files to set the ordinal position of
> each entry point. You might remember me announcing patent-free binaries
> which are still on the SSLeay ftp site. These come with hand-edited .DEF
> files that I made.
>
I think you may have misunderstood me here. I wasn't saying SSLeay
ignored the problem of binary incompatability (well it did if you took
any notice of error codes and a new one was inserted but thats a
different issue).
The fact that you needed hand edited DEF files under Win32 illustrates
the problem I'm referring to. Ideally there should be a mechanism where
any symbols corresponding to an excluded algorithm should be
automtically excluded from the DEF file. How is another matter entirely.
There is some of this going in in util\mkdef.pl where some things are
excluded by hard coding the names into the script and yanking them out
when the architecture didn't support them. There is also a kind of tiny
C pre-processor in there but it only handles some hard coded stuff.
Expanding this to provide the functionality needed would be rather
tricky.
What might work is to dump the .h files through the preprocessor with
appropriate flags and parse the output to get a list of function names.
This would need appropriate #ifdefs round function prototypes to work
where they don't exist already.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Senior crypto engineer, Celo Communications: http://www.celocom.com/
OpenSSL core developer. Email: [EMAIL PROTECTED]
PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]