>> For reference. I was always wondering why do our dlls have to export
>> things by ordinal and not by name? It would make sense if we maintained
>> backward binary compatibility [so that incompatible functions with same
>> name would be exported under different ordinals], but don't do that, at
>> least not at present...

> Well I can recall asking that ages ago and at IIRC the reason was precisely
> that changes made might break binary compatibility.
> Although we don't guarantee binary compatibility across major versions we do
> across minor ones (unless there is a *very* good reason not to) and possibly
> adding functions in a minor release might break things.

Adding functions won't break things regardless how they are exported, by
name or ordinal. The only use for ordinals is when you change interface
to some function, you *keep* even old implementation around and export
it under original ordinal, while modified interface is assigned new
ordinal. But you've *got to keep* the old implementation! As long as we
don't keep it, it doesn't really matter how we export, by name or
ordinal. Though it should be noted that it will break application in
different ways. Ordinals will prevent application from starting, while
names will cause unpredicted behaviour at run-time. So admittedly export
by ordinal is more appropriate, because the message is crystal clear:
"recompile!". *But* one can achieve the same clarity with export by name
*if* one embeds version number into .dll name, e.g. crypto099.dll. I
think we should do the latter regardless how we export, because it
allows multiple .dll versions to coexist.

To summarize. Let's change Windows .dll naming convention to embed
version number. Ordinals are then rendered meaningless in the context.

> BTW on the subject of cross compiling what are the thoughts on making this
> easier by adding a command line option to Configure which inserts a prefix to
> the relevant compiler tools?

Great idea! And if we say for example CC=$(CROSS_COMPILE)cc, we can also
use the prefix variable to determine whether or not to do such things as
c_rehash. A.
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org