gcc is used to build with) don't take it too well if LD_LIBRARY_PATH
is messed with when linknig programs. I'm going to assume that it's
OK to leave it unchanged when linking non-shared.
what's worse, they seem to use LD_LIBRARY_PATH as the first
directories to look into. This is documented in the manual page for
ld on OpenUNIX 8. Therefore, we need to hack LD_LIBRARY_PATH to
include the directory where the newly built libcrypto and libssl are.
could be done automagically, much like the numbering in libeay.num and
ssleay.num. The solution works as follows:
- New object identifiers are inserted in objects.txt, following the
syntax given in objects.README.
- objects.pl is used to process obj_mac.num and create a new
obj_mac.h.
- obj_dat.pl is used to create a new obj_dat.h, using the data in
obj_mac.h.
This is currently kind of a hack, and the perl code in objects.pl
isn't very elegant, but it works as I intended. The simplest way to
check that it worked correctly is to look in obj_dat.h and check the
array nid_objs and make sure the objects haven't moved around (this is
important!). Additions are OK, as well as consistent name changes.
Also, "make update" has added some missing functions to libeay.num,
updated the TABLE for the alpha changes, and updated thousands of
dependancies that have changed from recent commits.
Extend the X509_PURPOSE structure to include shortnames for purposed and default
trust ids.
Still need some extendable trust checking code and integration with the SSL and
S/MIME code.
in cryptlib.h (which is often included as "../cryptlib.h"), then the
question remains relative to which directory this is to be interpreted.
gcc went one further directory up, as intended; but makedepend thinks
differently, and so probably do some C compilers. So the ../ must go away;
thus e_os.h goes back into include/openssl (but I now use
#include "openssl/e_os.h" instead of <openssl/e_os.h> to make the point) --
and we have another huge bunch of dependency changes. Argh.
