> I entirely agree with the idea of following the standard set in the
> environment you work in. However, if we look at the file name without
> the extension, I'm only aware of a naming standard on Unix (libraries
> start with "lib")
But what does this naming convention on Unix means *exactly*? Is it
actually a requirement that all .a archives or .so objects are prefixed
with lib? No. Is it possible to link with a.a? Yes. With a.so? Yes. With
a.whatever? Yes! As long as we explicitly name it by full patch. Why do
we prepend the name with lib* then? For a sole reason to use it with -l
flag at link-time, where it essentialy means "prepend the name with lib
and look for it *around*," right? This "look around" is the keyword...
Now note that in Windows it is .lib extention which implies "looking
around," meaning that .lib extension in Windows is essentially equvalent
to lib prefix in Unix. This is why you can't observe any Windows naming
standard if you disregard extention.
> On Windows, there's the added complexity of using different run-time
> libraries depending on if you're using threads or not,
Note that this applies exclusively to LIBC (which is a static library!).
There is no MT-versions of USER32, KERNEL32 or even MSVCRT.
> if you built in debug mode or not
Note that this applies exclusively to LIBC and MSVCRT, there're no
"debug" counterpart of USER32, KERNEL32 or any other system run-time
component needed to execute program compiled for debugging. In other
words this MT and "debugging" naming convention exists exclusively in
compiler driver's mind, cl.exe in Microsoft case, and applies
exclusively to components tightly coupled to compiler run-time
environment [such as LIBC and MSVCRT]. This is another reason why one
can't observe any Windows library naming convention.
> and other details I'm not aware of. I've heard
> suggestions of creating several variants of the OpenSSL libraries that
> would be used in parallell with the different MSVC libraries, and
> that's where a naming convention is becoming even more important.
I'd say that we should rather strive for being more like USER32 or any
other system component, i.e. being MT-safe and neutral to any particular
compiler run-time environment.
> Added to this problem, we have the different register sizes on
> different CPUs (32-bit, 64-bit, and whatever will follow), which seems
> to be difficult to intermix in the same library,
^^^^^^^^^??? It's impossible. You can't intermix 64- and 32-bit
objects in same library nor in address space of any particular process.
Well, the latter is possible from hardware point of view, but it
requires kernel support and there is no any [as far as I know]. Naming
convention for 32- vs. 64-bit objects is provided rather through search
pathes [at both link- and run-time], than name of the object module per
se.
A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
