Fix many MarkDown issues in {NOTES*,README*,HACKING,LICENSE}.md files

Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12109)

1 files changed, 29 insertions, 32 deletions

diff --git a/NOTES-Unix.md b/NOTES-Unix.md
index 0e3c099ea2..98f3a799cc 100644
--- a/NOTES-Unix.md
+++ b/NOTES-Unix.md
@@ -1,9 +1,8 @@
+NOTES FOR UNIX-LIKE PLATFORMS
+=============================
 
- NOTES FOR UNIX LIKE PLATFORMS
- =============================
-
- For Unix/POSIX runtime systems on Windows, please see NOTES.WIN.
-
+ For Unix/POSIX runtime systems on Windows,
+ please see [NOTES-Windows.txt](NOTES-Windows.txt).
 
  OpenSSL uses the compiler to link programs and shared libraries
  ---------------------------------------------------------------
@@ -13,21 +12,20 @@
  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
+ 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.
-
+ 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, 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
+ 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
@@ -42,15 +40,15 @@
  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
+    -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.)
+ 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
@@ -63,28 +61,27 @@
         '-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
+ 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.
+  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).
+ 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
+ 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
+ `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
+ 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:
 
@@ -93,7 +90,7 @@
 
  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
+ executable, by interpreting `$ORIGIN` along with some other internal
  variables. Consult your system documentation.
 
  Linking your application
@@ -104,7 +101,7 @@
  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
+ "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...
@@ -114,4 +111,4 @@
  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.
+ differently, add `_a` suffix to link with them, e.g. `-lcrypto_a`.