Having been bitten yet again by the problem where I delete libssl.a
and do a make and existing up-to-date .o's don't get added to the
library, and not being able to build shared libs at all, I'm looking
for a good solution...
Gnumake knows how to reference members in a library. It's called
"archive update" in the documentation. For example if in
crypto/err/Makefile.ssl we changed
err.o: err.h
to
$(LIB)(err.o): err.h
then gnumake would compare the date of err.o in the library to the
dependencies and if necessary compile err.c, put the new .o in the
library, and rm the .o from crypto/err/.
This also makes it easier to support static and dynamic (shared)
libs concurrently, without additional Makefiles, since the static
and dynamic .o files now have unique names. Conceptually, we'd add a
"dynamic" target which would pass different CFLAGS and a different LIB
value ($(TOP)/libcrypto_shared.a instead of $(TOP)/libcrypto.a) to
the lower level makes and then do an extract-link post-processing
step on libcrypto_shared.a to create libcrypto.0.9.so. And didn't
Ralf say the equivalent of libcrypto_shared.a helped mod_ssl?
Of course it ties the project to gnumake, at least for unix platforms.
Fine with me...
Before I go to the effort of implementing this and posting diffs
does anyone see a reason not to go this way?
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
