From 036cbb6bbf30955abdcffaf6e52cd926d8d8ee75 Mon Sep 17 00:00:00 2001 From: "Dr. David von Oheimb" Date: Wed, 10 Jun 2020 14:15:28 +0200 Subject: Rename NOTES*, README*, VERSION, HACKING, LICENSE to .md or .txt Reviewed-by: Tim Hudson (Merged from https://github.com/openssl/openssl/pull/12109) --- NOTES.UNIX | 117 ------------------------------------------------------------- 1 file changed, 117 deletions(-) delete mode 100644 NOTES.UNIX (limited to 'NOTES.UNIX') diff --git a/NOTES.UNIX b/NOTES.UNIX deleted file mode 100644 index 0e3c099ea2..0000000000 --- a/NOTES.UNIX +++ /dev/null @@ -1,117 +0,0 @@ - - NOTES FOR UNIX LIKE PLATFORMS - ============================= - - For Unix/POSIX runtime systems on Windows, please see NOTES.WIN. - - - OpenSSL uses the compiler to link programs and shared libraries - --------------------------------------------------------------- - - OpenSSL's generated Makefile uses the C compiler command line to - link programs, shared libraries and dynamically loadable shared - objects. Because of this, any linking option that's given to the - configuration scripts MUST be in a form that the compiler can accept. - This varies between systems, where some have compilers that accept - linker flags directly, while others take them in '-Wl,' form. You need - to read your compiler documentation to figure out what is acceptable, - and ld(1) to figure out what linker options are available. - - - Shared libraries and installation in non-default locations - ---------------------------------------------------------- - - Every Unix system has its own set of default locations for shared - libraries, such as /lib, /usr/lib or possibly /usr/local/lib. If - libraries are installed in non-default locations, dynamically linked - binaries will not find them and therefore fail to run, unless they get - a bit of help from a defined runtime shared library search path. - - For OpenSSL's application (the 'openssl' command), our configuration - scripts do NOT generally set the runtime shared library search path for - you. It's therefore advisable to set it explicitly when configuring, - unless the libraries are to be installed in directories that you know - to be in the default list. - - Runtime shared library search paths are specified with different - linking options depending on operating system and versions thereof, and - are talked about differently in their respective documentation; - variations of RPATH are the most usual (note: ELF systems have two such - tags, more on that below). - - Possible options to set the runtime shared library search path include - the following: - - -Wl,-rpath,/whatever/path # Linux, *BSD, etc. - -R /whatever/path # Solaris - -Wl,-R,/whatever/path # AIX (-bsvr4 is passed internally) - -Wl,+b,/whatever/path # HP-UX - -rpath /whatever/path # Tru64, IRIX - - OpenSSL's configuration scripts recognise all these options and pass - them to the Makefile that they build. (In fact, all arguments starting - with '-Wl,' are recognised as linker options.) - - Please do not use verbatim directories in your runtime shared library - search path! Some OpenSSL config targets add an extra directory level - for multilib installations. To help with that, the produced Makefile - includes the variable LIBRPATH, which is a convenience variable to be - used with the runtime shared library search path options, as shown in - this example: - - $ ./Configure --prefix=/usr/local/ssl --openssldir=/usr/local/ssl \ - '-Wl,-rpath,$(LIBRPATH)' - - On modern ELF based systems, there are two runtime search paths tags to - consider, DT_RPATH and DT_RUNPATH. Shared objects are searched for in - this order: - - 1. Using directories specified in DT_RPATH, unless DT_RUNPATH is - also set. - 2. Using the environment variable LD_LIBRARY_PATH - 3. Using directories specified in DT_RUNPATH. - 4. Using system shared object caches and default directories. - - This means that the values in the environment variable LD_LIBRARY_PATH - won't matter if the library is found in the paths given by DT_RPATH - (and DT_RUNPATH isn't set). - - Exactly which of DT_RPATH or DT_RUNPATH is set by default appears to - depend on the system. For example, according to documentation, - DT_RPATH appears to be deprecated on Solaris in favor of DT_RUNPATH, - while on Debian GNU/Linux, either can be set, and DT_RPATH is the - default at the time of writing. - - How to choose which runtime search path tag is to be set depends on - your system, please refer to ld(1) for the exact information on your - system. As an example, the way to ensure the DT_RUNPATH is set on - Debian GNU/Linux systems rather than DT_RPATH is to tell the linker to - set new dtags, like this: - - $ ./Configure --prefix=/usr/local/ssl --openssldir=/usr/local/ssl \ - '-Wl,--enable-new-dtags,-rpath,$(LIBRPATH)' - - It might be worth noting that some/most ELF systems implement support - for runtime search path relative to the directory containing current - executable, by interpreting $ORIGIN along with some other internal - variables. Consult your system documentation. - - Linking your application - ------------------------ - - Third-party applications dynamically linked with OpenSSL (or any other) - shared library face exactly the same problem with non-default locations. - The OpenSSL config options mentioned above might or might not have bearing - on linking of the target application. "Might" means that under some - circumstances it would be sufficient to link with OpenSSL shared library - "naturally", i.e. with -L/whatever/path -lssl -lcrypto. But there are - also cases when you'd have to explicitly specify runtime search path - when linking your application. Consult your system documentation and use - above section as inspiration... - - Shared OpenSSL builds also install static libraries. Linking with the - latter is likely to require special care, because linkers usually look - for shared libraries first and tend to remain "blind" to static OpenSSL - libraries. Referring to system documentation would suffice, if not for - a corner case. On AIX static libraries (in shared build) are named - differently, add _a suffix to link with them, e.g. -lcrypto_a. -- cgit v1.2.3