1. 06 3月, 2001 2 次提交
  2. 22 2月, 2001 1 次提交
  3. 20 2月, 2001 1 次提交
    • R
      Make all configuration macros available for application by making · cf1b7d96
      Richard Levitte 提交于
      sure they are available in opensslconf.h, by giving them names starting
      with "OPENSSL_" to avoid conflicts with other packages and by making
      sure e_os2.h will cover all platform-specific cases together with
      opensslconf.h.
      
      I've checked fairly well that nothing breaks with this (apart from
      external software that will adapt if they have used something like
      NO_KRB5), but I can't guarantee it completely, so a review of this
      change would be a good thing.
      cf1b7d96
  4. 11 1月, 2001 2 次提交
  5. 01 12月, 2000 1 次提交
  6. 14 11月, 2000 1 次提交
  7. 13 11月, 2000 2 次提交
    • L
      HP-UX shared libraries do not build any longer, as EX_LIBS contains · 305db17b
      Lutz Jänicke 提交于
      "-Wl,+s" instead of +s:
      * Hardcoded necessary references to -ldld/-ldl into the build rules and
        removed EX_LIBS.
      
      HP-UX records the pathnames of dependent libraries when the shared libs
      are built, so that ./libcrypto.sl... is recorded in libssl.sl..., with
      "./" not being resolvable when running an application linked against -lssl:
      * Build libssl without explicit reference to libcrypto, applications will
        be linked with "-lssl -lcrypto" anyway.
      
      Document these informations in Makefile.org.
      305db17b
    • R
      For a long time, I've wanted to be able to easily run one or a few · f777408f
      Richard Levitte 提交于
      individual tests.  I finally got myself to implement it...
      f777408f
  8. 09 11月, 2000 1 次提交
  9. 06 11月, 2000 1 次提交
  10. 01 11月, 2000 2 次提交
  11. 27 10月, 2000 2 次提交
  12. 23 10月, 2000 2 次提交
  13. 22 10月, 2000 1 次提交
  14. 15 10月, 2000 1 次提交
  15. 13 10月, 2000 1 次提交
    • R
      Rework the system to generate shared libraries: · a22fb399
      Richard Levitte 提交于
        - Make note of the expected extension for the shared libraries and
          if there is a need for symbolic links from for example libcrypto.so.0
          to libcrypto.so.0.9.7.  There is extended info in Configure for
          that.
      
        - Make as few rebuilds of the shared libraries as possible.
      
        - Still avoid linking the OpenSSL programs with the shared libraries.
      
        - When installing, install the shared libraries separately from the
          static ones.
      a22fb399
  16. 09 10月, 2000 1 次提交
  17. 26 9月, 2000 1 次提交
  18. 21 9月, 2000 1 次提交
  19. 17 8月, 2000 1 次提交
  20. 14 8月, 2000 1 次提交
  21. 02 8月, 2000 2 次提交
  22. 25 7月, 2000 2 次提交
  23. 21 7月, 2000 1 次提交
    • R
      Redo and enhance the support for building shared libraries. Currently · b436a982
      Richard Levitte 提交于
      there's support for building under Linux and True64 (using examples
      from the programming manuals), including versioning that is currently
      the same as OpenSSL versions but should really be a different series.
      
      With this change, it's up to the users to decide if they want shared
      libraries as well as the static ones.  This decision now has to be
      done at configuration time (well, not really, those who know what they
      do can still do it the same way as before).
      
      The OpenSSL programs (openssl and the test programs) are currently
      always linked statically, but this may change in the future in a
      configurable manner.  The necessary makefile variables to enable this
      are in place.
      
      Also note that I have done absolutely nothing about the Windows target
      to get something similar.  On the other hand, DLLs are already the
      default there, but without versioning, and I've no idea what the
      possibilities for such a thing are there...
      b436a982
  24. 05 7月, 2000 1 次提交
    • R
      I got sick and tired of having to keep track of NIDs when such a thing · c2bbf9cf
      Richard Levitte 提交于
      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.
      c2bbf9cf
  25. 18 6月, 2000 1 次提交
  26. 01 6月, 2000 1 次提交
    • G
      This change will cause builds (by default) to not use different STACK · e41c8d6a
      Geoff Thorpe 提交于
      structures and functions for each stack type. The previous behaviour
      can be enabled by configuring with the "-DDEBUG_SAFESTACK" option.
      This will also cause "make update" (mkdef.pl in particular) to
      update the libeay.num and ssleay.num symbol tables with the number of
      extra functions DEBUG_SAFESTACK creates.
      
      The way this change works is to accompany each DECLARE_STACK_OF()
      macro with a set of "#define"d versions of the sk_##type##_***
      functions that ensures all the existing "type-safe" stack calls are
      precompiled into the underlying stack calls. The presence or abscence
      of the DEBUG_SAFESTACK symbol controls whether this block of
      "#define"s or the DECLARE_STACK_OF() macro is taking effect. The
      block of "#define"s is in turn generated and maintained by a perl
      script (util/mkstack.pl) that encompasses the block with delimiting
      C comments. This works in a similar way to the auto-generated error
      codes and, like the other such maintenance utilities, is invoked
      by the "make update" target.
      
      A long (but mundane) commit will follow this with the results of
      "make update" - this will include all the "#define" blocks for
      each DECLARE_STACK_OF() statement, along with stripped down
      libeay.num and ssleay.num files.
      e41c8d6a
  27. 18 5月, 2000 1 次提交
  28. 05 4月, 2000 1 次提交
    • G
      This commit ties the new DSO code (crypto/dso/) into the build for a · 9ec0126e
      Geoff Thorpe 提交于
      variety of platforms. A few are missing, and they will be added in
      eventually, but as this is new stuff, it was better to not break lots of
      platforms in one go that we can't easily test. The changes to "Configure"
      should illustrate how to add support to other systems if you feel like
      having a go.
      
      NB: I'll add something shortly to allow you to add "dlfcn.h" support on
      those platforms that don't have (or need) a dlfcn.h header file. (The
      symbol for Configure will probably by "dlfcn_no_h").
      
      Thanks to Richard Levitte, who is responsible for the dso_dl.c support,
      understanding the trickier aspects of the build process, and giving great
      feedback on everything else.
      
      [Don't use this stuff if you're easily offended by changes to the
      interface or behaviour - it's still work in progress.]
      
      PR:
      9ec0126e
  29. 15 3月, 2000 1 次提交
  30. 09 3月, 2000 1 次提交
  31. 29 2月, 2000 1 次提交
  32. 25 2月, 2000 1 次提交