{"schema":"libjg2-1", "vpath":"/git/", "avatar":"/git/avatar/", "alang":"", "gen_ut":1756236900, "reponame":"openssl", "desc":"OpenSSL", "owner": { "name": "Andy Green", "email": "andy@warmcat.com", "md5": "c50933ca2aa61e0fe2c43d46bb6b59cb" },"url":"https://warmcat.com/repo/openssl", "f":3, "items": [ {"schema":"libjg2-1", "cid":"0c2c1f725836e39256d194b7420b6d64", "oid":{ "oid": "01b7851aa27aa144372f5484da916be042d9aa4f", "alias": []},"blobname": "INSTALL.NW", "blob": "\nINSTALLATION ON THE NETWARE PLATFORM\n------------------------------------\n\nNotes about building OpenSSL for NetWare.\n\n\nBUILD PLATFORM:\n---------------\nThe build scripts (batch files, perl scripts, etc) have been developed and\ntested on W2K. The scripts should run fine on other Windows platforms\n(NT, Win9x, WinXP) but they have not been tested. They may require some\nmodifications.\n\n\nSupported NetWare Platforms - NetWare 5.x, NetWare 6.x:\n-------------------------------------------------------\nOpenSSL can either use the WinSock interfaces introduced in NetWare 5,\nor the BSD socket interface. Previous versions of NetWare, 4.x and 3.x,\nare only supported if OpenSSL is build for CLIB and BSD sockets;\nWinSock builds only support NetWare 5 and up.\n\nOn NetWare there are two c-runtime libraries. There is the legacy CLIB \ninterfaces and the newer LIBC interfaces. Being ANSI-C libraries, the \nfunctionality in CLIB and LIBC is similar but the LIBC interfaces are built \nusing Novell Kernal Services (NKS) which is designed to leverage \nmulti-processor environments.\n\nThe NetWare port of OpenSSL can be configured to build using CLIB or LIBC.\nThe CLIB build was developed and tested using NetWare 5.0 sp6.0a. The LIBC \nbuild was developed and tested using the NetWare 6.0 FCS. \n\nThe necessary LIBC functionality ships with NetWare 6. However, earlier \nNetWare 5.x versions will require updates in order to run the OpenSSL LIBC\nbuild (NetWare 5.1 SP8 is known to work).\n\nAs of June 2005, the LIBC build can be configured to use BSD sockets instead\nof WinSock sockets. Call Configure (usually through netware\u005cbuild.bat) using\na target of \u0022netware-libc-bsdsock\u0022 instead of \u0022netware-libc\u0022.\n\nAs of June 2007, support for CLIB and BSD sockets is also now available\nusing a target of \u0022netware-clib-bsdsock\u0022 instead of \u0022netware-clib\u0022;\nalso gcc builds are now supported on both Linux and Win32 (post 0.9.8e).\n\nREQUIRED TOOLS:\n---------------\nBased upon the configuration and build options used, some or all of the\nfollowing tools may be required:\n\n* Perl for Win32 - required (http://www.activestate.com/ActivePerl)\n Used to run the various perl scripts on the build platform.\n\n* Perl 5.8.0 for NetWare v3.20 (or later) - required \n (http://developer.novell.com) Used to run the test script on NetWare \n after building.\n\n* Compiler / Linker - required:\n Metrowerks CodeWarrior PDK 2.1 (or later) for NetWare (commercial):\n Provides command line tools used for building.\n Tools:\n mwccnlm.exe - C/C++ Compiler for NetWare\n mwldnlm.exe - Linker for NetWare\n mwasmnlm.exe - x86 assembler for NetWare (if using assembly option)\n\n gcc / nlmconv Cross-Compiler, available from Novell Forge (free):\n http://forge.novell.com/modules/xfmod/project/?aunixnw\n\n* Assemblers - optional:\n If you intend to build using the assembly options you will need an\n assembler. Work has been completed to support two assemblers, Metrowerks\n and NASM. However, during development, a bug was found in the Metrowerks\n assembler which generates incorrect code. Until this problem is fixed,\n the Metrowerks assembler cannot be used.\n\n mwasmnlm.exe - Metrowerks x86 assembler - part of CodeWarrior tools.\n (version 2.2 Built Aug 23, 1999 - not useable due to code\n generation bug)\n\n nasmw.exe - Netwide Assembler NASM\n version 0.98 was used in development and testing\n\n* Make Tool - required:\n In order to build you will need a make tool. Two make tools are\n supported, GNU make (gmake.exe) or Microsoft nmake.exe.\n\n make.exe - GNU make for Windows (version 3.75 used for development)\n http://gnuwin32.sourceforge.net/packages/make.htm\n\n nmake.exe - Microsoft make (Version 6.00.8168.0 used for development)\n http://support.microsoft.com/kb/132084/EN-US/\n\n* Novell Developer Kit (NDK) - required: (http://developer.novell.com)\n\n CLIB - BUILDS:\n\n WinSock2 Developer Components for NetWare:\n For initial development, the October 27, 2000 version was used.\n However, future versions should also work.\n\n NOTE: The WinSock2 components include headers \u0026 import files for\n NetWare, but you will also need the winsock2.h and supporting\n headers (pshpack4.h, poppack.h, qos.h) delivered in the\n Microsoft SDK. Note: The winsock2.h support headers may change\n with various versions of winsock2.h. Check the dependencies\n section on the NDK WinSock2 download page for the latest\n information on dependencies. These components are unsupported by\n Novell. They are provided as a courtesy, but it is strongly\n suggested that all development be done using LIBC, not CLIB.\n\n As of June 2005, the WinSock2 components are available at:\n http://forgeftp.novell.com//ws2comp/\n\n\n NLM and NetWare libraries for C (including CLIB and XPlat):\n If you are going to build a CLIB version of OpenSSL, you will\n need the CLIB headers and imports. The March, 2001 NDK release or \n later is recommended.\n\n Earlier versions should work but haven't been tested. In recent\n versions the import files have been consolidated and function\n names moved. This means you may run into link problems\n (undefined symbols) when using earlier versions. The functions\n are available in earlier versions, but you will have to modifiy\n the make files to include additional import files (see\n openssl\u005cutil\u005cpl\u005cnetware.pl).\n\n\n LIBC - BUILDS:\n \n Libraries for C (LIBC) - LIBC headers and import files\n If you are going to build a LIBC version of OpenSSL, you will\n need the LIBC headers and imports. The March 14, 2002 NDK release or\n later is required. \n \n NOTE: The LIBC SDK includes the necessary WinSock2 support.\n It is not necessary to download the WinSock2 NDK when building for\n LIBC. The LIBC SDK also includes the appropriate BSD socket support\n if configuring to use BSD sockets.\n\n\nBUILDING:\n---------\nBefore building, you will need to set a few environment variables. You can\nset them manually or you can modify the \u0022netware\u005cset_env.bat\u0022 file.\n\nThe set_env.bat file is a template you can use to set up the path\nand environment variables you will need to build. Modify the\nvarious lines to point to YOUR tools and run set_env.bat.\n\n netware\u005cset_env.bat \u003ctarget\u003e [compiler]\n\n target - \u0022netware-clib\u0022 - CLIB NetWare build\n - \u0022netware-libc\u0022 - LIBC NetWare build\n\n compiler - \u0022gnuc\u0022 - GNU GCC Compiler\n - \u0022codewarrior\u0022 - MetroWerks CodeWarrior (default)\n\nIf you don't use set_env.bat, you will need to set up the following\nenvironment variables:\n\n PATH - Set PATH to point to the tools you will use.\n\n INCLUDE - The location of the NDK include files.\n \n CLIB ex: set INCLUDE\u003dc:\u005cndk\u005cnwsdk\u005cinclude\u005cnlm\n LIBC ex: set INCLUDE\u003dc:\u005cndk\u005clibc\u005cinclude\n\n PRELUDE - The absolute path of the prelude object to link with. For\n a CLIB build it is recommended you use the \u0022clibpre.o\u0022 files shipped\n with the Metrowerks PDK for NetWare. For a LIBC build you should \n use the \u0022libcpre.o\u0022 file delivered with the LIBC NDK components.\n\n CLIB ex: set PRELUDE\u003dc:\u005cndk\u005cnwsdk\u005cimports\u005cclibpre.o\n LIBC ex: set PRELUDE\u003dc:\u005cndk\u005clibc\u005cimports\u005clibcpre.o\n\n IMPORTS - The locaton of the NDK import files.\n\n CLIB ex: set IMPORTS\u003dc:\u005cndk\u005cnwsdk\u005cimports\n LIBC ex: set IMPORTS\u003dc:\u005cndk\u005clibc\u005cimports\n\n\nIn order to build, you need to run the Perl scripts to configure the build\nprocess and generate a make file. There is a batch file,\n\u0022netware\u005cbuild.bat\u0022, to automate the process.\n\nBuild.bat runs the build configuration scripts and generates a make file.\nIf an assembly option is specified, it also runs the scripts to generate \nthe assembly code. Always run build.bat from the \u0022openssl\u0022 directory.\n\n netware\u005cbuild [target] [debug opts] [assembly opts] [configure opts]\n\n target - \u0022netware-clib\u0022 - CLIB NetWare build (WinSock Sockets)\n - \u0022netware-clib-bsdsock\u0022 - CLIB NetWare build (BSD Sockets)\n - \u0022netware-libc\u0022 - LIBC NetWare build (WinSock Sockets)\n - \u0022netware-libc-bsdsock\u0022 - LIBC NetWare build (BSD Sockets)\n \n debug opts - \u0022debug\u0022 - build debug\n\n assembly opts - \u0022nw-mwasm\u0022 - use Metrowerks assembler\n \u0022nw-nasm\u0022 - use NASM assembler\n \u0022no-asm\u0022 - don't use assembly\n\n configure opts- all unrecognized arguments are passed to the\n perl 'configure' script. See that script for\n internal documentation regarding options that\n are available.\n\n examples:\n\n CLIB build, debug, without assembly:\n netware\u005cbuild.bat netware-clib debug no-asm\n\n LIBC build, non-debug, using NASM assembly, add mdc2 support:\n netware\u005cbuild.bat netware-libc nw-nasm enable-mdc2\n\n LIBC build, BSD sockets, non-debug, without assembly:\n netware\u005cbuild.bat netware-libc-bsdsock no-asm\n\nRunning build.bat generates a make file to be processed by your make \ntool (gmake or nmake):\n\n CLIB ex: gmake -f netware\u005cnlm_clib_dbg.mak \n LIBC ex: gmake -f netware\u005cnlm_libc.mak \n LIBC ex: gmake -f netware\u005cnlm_libc_bsdsock.mak \n\n\nYou can also run the build scripts manually if you do not want to use the\nbuild.bat file. Run the following scripts in the \u0022\u005copenssl\u0022\nsubdirectory (in the order listed below):\n\n perl configure no-asm [other config opts] [netware-clib|netware-libc|netware-libc-bsdsock]\n configures no assembly build for specified netware environment\n (CLIB or LIBC).\n\n perl util\u005cmkfiles.pl \u003eMINFO\n generates a listing of source files (used by mk1mf)\n\n perl util\u005cmk1mf.pl no-asm [other config opts] [netware-clib|netware-libc|netware-libc-bsdsock \u003enetware\u005cnlm.mak\n generates the makefile for NetWare\n\n gmake -f netware\u005cnlm.mak\n build with the make tool (nmake.exe also works)\n\nNOTE: If you are building using the assembly option, you must also run the\nvarious Perl scripts to generate the assembly files. See build.bat\nfor an example of running the various assembly scripts. You must use the\n\u0022no-asm\u0022 option to build without assembly. The configure and mk1mf scripts\nalso have various other options. See the scripts for more information.\n\n\nThe output from the build is placed in the following directories:\n\n CLIB Debug build:\n out_nw_clib.dbg - static libs \u0026 test nlm(s)\n tmp_nw_clib.dbg - temporary build files\n outinc_nw_clib - necessary include files\n\n CLIB Non-debug build:\n out_nw_clib - static libs \u0026 test nlm(s)\n tmp_nw_clib - temporary build files\n outinc_nw_clib - necesary include files\n\n LIBC Debug build:\n out_nw_libc.dbg - static libs \u0026 test nlm(s)\n tmp_nw_libc.dbg - temporary build files\n outinc_nw_libc - necessary include files\n\n LIBC Non-debug build:\n out_nw_libc - static libs \u0026 test nlm(s)\n tmp_nw_libc - temporary build files\n outinc_nw_libc - necesary include files\n\n\nTESTING:\n--------\nThe build process creates the OpenSSL static libs ( crypto.lib, ssl.lib,\nrsaglue.lib ) and several test programs. You should copy the test programs\nto your NetWare server and run the tests.\n\nThe batch file \u0022netware\u005ccpy_tests.bat\u0022 will copy all the necessary files\nto your server for testing. In order to run the batch file, you need a\ndrive mapped to your target server. It will create an \u0022OpenSSL\u0022 directory\non the drive and copy the test files to it. CAUTION: If a directory with the\nname of \u0022OpenSSL\u0022 already exists, it will be deleted.\n\nTo run cpy_tests.bat:\n\n netware\u005ccpy_tests [output directory] [NetWare drive]\n\n output directory - \u0022out_nw_clib.dbg\u0022, \u0022out_nw_libc\u0022, etc.\n NetWare drive - drive letter of mapped drive\n\n CLIB ex: netware\u005ccpy_tests out_nw_clib m:\n LIBC ex: netware\u005ccpy_tests out_nw_libc m:\n\n\nThe Perl script, \u0022do_tests.pl\u0022, in the \u0022OpenSSL\u0022 directory on the server\nshould be used to execute the tests. Before running the script, make sure\nyour SEARCH PATH includes the \u0022OpenSSL\u0022 directory. For example, if you\ncopied the files to the \u0022sys:\u0022 volume you use the command:\n\n SEARCH ADD SYS:\u005cOPENSSL\n\n\nTo run do_tests.pl type (at the console prompt):\n\n perl \u005copenssl\u005cdo_tests.pl [options]\n\n options:\n -p - pause after executing each test\n\nThe do_tests.pl script generates a log file \u0022\u005copenssl\u005ctest_out\u005ctests.log\u0022\nwhich should be reviewed for errors. Any errors will be denoted by the word\n\u0022ERROR\u0022 in the log.\n\nDEVELOPING WITH THE OPENSSL SDK:\n--------------------------------\nNow that everything is built and tested, you are ready to use the OpenSSL\nlibraries in your development.\n\nThere is no real installation procedure, just copy the static libs and\nheaders to your build location. The libs (crypto.lib \u0026 ssl.lib) are\nlocated in the appropriate \u0022out_nw_XXXX\u0022 directory \n(out_nw_clib, out_nw_libc, etc). \n\nThe headers are located in the appropriate \u0022outinc_nw_XXX\u0022 directory \n(outinc_nw_clib, outinc_nw_libc). \n\nOne suggestion is to create the following directory \nstructure for the OpenSSL SDK:\n\n \u005copenssl\n |- bin\n | |- openssl.nlm\n | |- (other tests you want)\n |\n |- lib\n | | - crypto.lib\n | | - ssl.lib\n |\n |- include\n | | - openssl\n | | | - (all the headers in \u0022outinc_nw\u005copenssl\u0022)\n\n\nThe program \u0022openssl.nlm\u0022 can be very useful. It has dozens of\noptions and you may want to keep it handy for debugging, testing, etc.\n\nWhen building your apps using OpenSSL, define \u0022NETWARE\u0022. It is needed by\nsome of the OpenSSL headers. One way to do this is with a compile option,\nfor example \u0022-DNETWARE\u0022.\n\n\n\nNOTES:\n------\n\nResource leaks in Tests\n------------------------\nSome OpenSSL tests do not clean up resources and NetWare reports\nthe resource leaks when the tests unload. If this really bugs you,\nyou can stop the messages by setting the developer option off at the console\nprompt (set developer option \u003d off). Or better yet, fix the tests to\nclean up the resources!\n\n\nMulti-threaded Development\n---------------------------\nThe NetWare version of OpenSSL is thread-safe, however multi-threaded\napplications must provide the necessary locking function callbacks. This\nis described in doc\u005cthreads.doc. The file \u0022openssl-x.x.x\u005ccrypto\u005cthreads\u005cmttest.c\u0022\nis a multi-threaded test program and demonstrates the locking functions.\n\n\nWhat is openssl2.nlm?\n---------------------\nThe openssl program has numerous options and can be used for many different\nthings. Many of the options operate in an interactive mode requiring the\nuser to enter data. Because of this, a default screen is created for the\nprogram. However, when running the test script it is not desirable to\nhave a separate screen. Therefore, the build also creates openssl2.nlm.\nOpenssl2.nlm is functionally identical but uses the console screen.\nOpenssl2 can be used when a non-interactive mode is desired.\n\nNOTE: There are may other possibilities (command line options, etc)\nwhich could have been used to address the screen issue. The openssl2.nlm\noption was chosen because it impacted only the build not the code.\n\n\nWhy only static libraries?\n--------------------------\nGlobals, globals, and more globals. The OpenSSL code uses many global\nvariables that are allocated and initialized when used for the first time.\n\nOn NetWare, most applications (at least historically) run in the kernel.\nWhen running in the kernel, there is one instance of global variables.\nFor regular application type NLM(s) this isn't a problem because they are\nthe only ones using the globals. However, for a library NLM (an NLM which\nexposes functions and has no threads of execution), the globals cause\nproblems. Applications could inadvertently step on each other if they\nchange some globals. Even worse, the first application that triggers a\nglobal to be allocated and initialized has the allocated memory charged to\nitself. Now when that application unloads, NetWare will clean up all the\napplicaton's memory. The global pointer variables inside OpenSSL now\npoint to freed memory. An abend waiting to happen!\n\nTo work correctly in the kernel, library NLM(s) that use globals need to\nprovide a set of globals (instance data) for each application. Another\noption is to require the library only be loaded in a protected address\nspace along with the application using it.\n\nModifying the OpenSSL code to provide a set of globals (instance data) for\neach application isn't technically difficult, but due to the large number\nglobals it would require substantial code changes and it wasn't done. Hence,\nthe build currently only builds static libraries which are then linked\ninto each application.\n\nNOTE: If you are building a library NLM that uses the OpenSSL static\nlibraries, you will still have to deal with the global variable issue.\nThis is because when you link in the OpenSSL code you bring in all the\nglobals. One possible solution for the global pointer variables is to\nregister memory functions with OpenSSL which allocate memory and charge it\nto your library NLM (see the function CRYPTO_set_mem_functions). However,\nbe aware that now all memory allocated by OpenSSL is charged to your NLM.\n\n\nCodeWarrior Tools and W2K\n---------------------------\nThere have been problems reported with the CodeWarrior Linker\n(mwldnlm.exe) in the PDK 2.1 for NetWare when running on Windows 2000. The\nproblems cause the link step to fail. The only work around is to obtain an\nupdated linker from Metrowerks. It is expected Metrowerks will release\nPDK 3.0 (in beta testing at this time - May, 2001) in the near future which\nwill fix these problems.\n\n\nMakefile \u0022vclean\u0022\n------------------\nThe generated makefile has a \u0022vclean\u0022 target which cleans up the build\ndirectories. If you have been building successfully and suddenly\nexperience problems, use \u0022vclean\u0022 (gmake -f netware\u005cnlm_xxxx.mak vclean) and retry.\n\n\n\u0022Undefined Symbol\u0022 Linker errors\n--------------------------------\nThere have been linker errors reported when doing a CLIB build. The problems\noccur because some versions of the CLIB SDK import files inadvertently \nleft out some symbols. One symbol in particular is \u0022_lrotl\u0022. The missing\nfunctions are actually delivered in the binaries, but they were left out of\nthe import files. The issues should be fixed in the September 2001 release \nof the NDK. If you experience the problems you can temporarily\nwork around it by manually adding the missing symbols to your version of \n\u0022clib.imp\u0022.\n\n","s":{"c":1756147129,"u": 648}} ],"g": 1410,"chitpc": 0,"ehitpc": 0,"indexed":0 , "ab": 0, "si": 0, "db":0, "di":0, "sat":0, "lfc": "7d0a"}