A local copy of OpenSSL from GitHub
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

117 lines
5.4 KiB

  2. =============================
  3. For Unix/POSIX runtime systems on Windows, please see NOTES.WIN.
  4. OpenSSL uses the compiler to link programs and shared libraries
  5. ---------------------------------------------------------------
  6. OpenSSL's generated Makefile uses the C compiler command line to
  7. link programs, shared libraries and dynamically loadable shared
  8. objects. Because of this, any linking option that's given to the
  9. configuration scripts MUST be in a form that the compiler can accept.
  10. This varies between systems, where some have compilers that accept
  11. linker flags directly, while others take them in '-Wl,' form. You need
  12. to read your compiler documentation to figure out what is acceptable,
  13. and ld(1) to figure out what linker options are available.
  14. Shared libraries and installation in non-default locations
  15. ----------------------------------------------------------
  16. Every Unix system has its own set of default locations for shared
  17. libraries, such as /lib, /usr/lib or possibly /usr/local/lib. If
  18. libraries are installed in non-default locations, dynamically linked
  19. binaries will not find them and therefore fail to run, unless they get
  20. a bit of help from a defined runtime shared library search path.
  21. For OpenSSL's application (the 'openssl' command), our configuration
  22. scripts do NOT generally set the runtime shared library search path for
  23. you. It's therefore advisable to set it explicitly when configuring,
  24. unless the libraries are to be installed in directories that you know
  25. to be in the default list.
  26. Runtime shared library search paths are specified with different
  27. linking options depending on operating system and versions thereof, and
  28. are talked about differently in their respective documentation;
  29. variations of RPATH are the most usual (note: ELF systems have two such
  30. tags, more on that below).
  31. Possible options to set the runtime shared library search path include
  32. the following:
  33. -Wl,-rpath,/whatever/path # Linux, *BSD, etc.
  34. -R /whatever/path # Solaris
  35. -Wl,-R,/whatever/path # AIX (-bsvr4 is passed internally)
  36. -Wl,+b,/whatever/path # HP-UX
  37. -rpath /whatever/path # Tru64, IRIX
  38. OpenSSL's configuration scripts recognise all these options and pass
  39. them to the Makefile that they build. (In fact, all arguments starting
  40. with '-Wl,' are recognised as linker options.)
  41. Please do not use verbatim directories in your runtime shared library
  42. search path! Some OpenSSL config targets add an extra directory level
  43. for multilib installations. To help with that, the produced Makefile
  44. includes the variable LIBRPATH, which is a convenience variable to be
  45. used with the runtime shared library search path options, as shown in
  46. this example:
  47. $ ./config --prefix=/usr/local/ssl --openssldir=/usr/local/ssl \
  48. '-Wl,-rpath,$(LIBRPATH)'
  49. On modern ELF based systems, there are two runtime search paths tags to
  50. consider, DT_RPATH and DT_RUNPATH. Shared objects are searched for in
  51. this order:
  52. 1. Using directories specified in DT_RPATH, unless DT_RUNPATH is
  53. also set.
  54. 2. Using the environment variable LD_LIBRARY_PATH
  55. 3. Using directories specified in DT_RUNPATH.
  56. 4. Using system shared object caches and default directories.
  57. This means that the values in the environment variable LD_LIBRARY_PATH
  58. won't matter if the library is found in the paths given by DT_RPATH
  59. (and DT_RUNPATH isn't set).
  60. Exactly which of DT_RPATH or DT_RUNPATH is set by default appears to
  61. depend on the system. For example, according to documentation,
  62. DT_RPATH appears to be deprecated on Solaris in favor of DT_RUNPATH,
  63. while on Debian GNU/Linux, either can be set, and DT_RPATH is the
  64. default at the time of writing.
  65. How to choose which runtime search path tag is to be set depends on
  66. your system, please refer to ld(1) for the exact information on your
  67. system. As an example, the way to ensure the DT_RUNPATH is set on
  68. Debian GNU/Linux systems rather than DT_RPATH is to tell the linker to
  69. set new dtags, like this:
  70. $ ./config --prefix=/usr/local/ssl --openssldir=/usr/local/ssl \
  71. '-Wl,--enable-new-dtags,-rpath,$(LIBRPATH)'
  72. It might be worth noting that some/most ELF systems implement support
  73. for runtime search path relative to the directory containing current
  74. executable, by interpreting $ORIGIN along with some other internal
  75. variables. Consult your system documentation.
  76. Linking your application
  77. ------------------------
  78. Third-party applications dynamically linked with OpenSSL (or any other)
  79. shared library face exactly the same problem with non-default locations.
  80. The OpenSSL config options mentioned above might or might not have bearing
  81. on linking of the target application. "Might" means that under some
  82. circumstances it would be sufficient to link with OpenSSL shared library
  83. "naturally", i.e. with -L/whatever/path -lssl -lcrypto. But there are
  84. also cases when you'd have to explicitly specify runtime search path
  85. when linking your application. Consult your system documentation and use
  86. above section as inspiration...
  87. Shared OpenSSL builds also install static libraries. Linking with the
  88. latter is likely to require special care, because linkers usually look
  89. for shared libraries first and tend to remain "blind" to static OpenSSL
  90. libraries. Referring to system documentation would suffice, if not for
  91. a corner case. On AIX static libraries (in shared build) are named
  92. differently, add _a suffix to link with them, e.g. -lcrypto_a.