Hi Oscar,
> There's a few other issues at hand, I think. Would it be
> enough to just
> release a "static library" build target? I know I'm personally mainly
> interested in static library builds that are linked /MT & /MTd, but
> somebody might conceivably prefer static libs linked /MD & /MDd, which
> is after all the current OpenSSL default behaviour.
I think it is good to have a choice of dynamic libraries. Some people
might want to use them when building multiple components.
Although I have always been curios if, by using them for such delicate
reason as encryption, your are really opening a backdoor for a sophisticated
cracker, or is it just paranoia.
> Same thing goes for dynamic libraries, only the other way around. I've
> had problems I've yet to address trying to link these /MT & /MTd, so
> I've had to settle for /MD & /MDd.
I can�t remeber any particular problems with building static libraries,
except that I did have to fiddle with the options, I�ll have to look up the
exact options string at home.
> > 2. to have a dedicated directory for all build results, may
> be with separate
> This shouldn't be too hard to accomplish. Would we really
> need separate
> build directories if we used a library naming convention?
Probably yes, unless you append suffixes to the object files,
which is probably too much trouble for the gain you get.
Besides, to force a complete rebuild, you can just remove appropriate
directory and be sure it�ll be rebuilt.
> My vote would be for something like (I hope I'm making at least some
> sense here) "lib(eay|ssl)(32|nt)(MD|MT)[d].lib".
Sounds good to me.
I�ll organise somewhere a place to put my version of make files so you
could have a look.
Regards,
Alexei
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
