../dir/foo.exe.map]
                    -o foo.exe -Map=%                    [Creates ./foo.exe.map]
                    -o ../dir/foo.exe -Map=%             [Creates ../dir/foo.exe.map]
                    -o foo.exe -Map=%.bar                [Creates ./foo.exe.bar]
                    -o ../dir/foo.exe -Map=%.bar         [Creates ../dir/foo.exe.bar]
                    -o ../dir2/foo.exe -Map=../dir/%     [Creates ../dir/../dir2/foo.exe.map]
                    -o ../dir2/foo.exe -Map=../dir/%.bar [Creates ../dir/../dir2/foo.exe.bar]

           It is an error to specify more than one "%" character.

           If the map file already exists then it will be overwritten by this operation.

       --no-keep-memory
           ld normally optimizes for speed over memory usage by caching the symbol tables of input files in memory.  This option tells ld to instead optimize for memory usage, by rereading the  symbol  tables  as  necessary.
           This may be required if ld runs out of memory space while linking a large executable.

       --no-undefined
       -z defs
           Report  unresolved  symbol  references  from  regular  object  files.  This is done even if the linker is creating a non‐symbolic shared library.  The switch --[no-]allow-shlib-undefined controls the behaviour for
           reporting unresolved references found in shared libraries being linked in.

           The effects of this option can be reverted by using "-z undefs".

       --allow-multiple-definition
       -z muldefs
           Normally when a symbol is defined multiple times, the linker will report a fatal error. These options allow multiple definitions and the first definition will be used.

       --allow-shlib-undefined
       --no-allow-shlib-undefined
           Allows or disallows undefined symbols in shared libraries.  This switch is similar to --no-undefined except that it determines the behaviour when the undefined symbols are in a shared library rather than a regular
           object file.  It does not affect how undefined symbols in regular object files are handled.

           The default behaviour is to report errors for any undefined symbols referenced in shared libraries if the linker is being used to create an executable, but to allow them if the linker is being  used  to  create  a
           shared library.

           The reasons for allowing undefined symbol references in shared libraries specified at link time are that:

           •   A shared library specified at link time may not be the same as the one that is available at load time, so the symbol might actually be resolvable at load time.

           •   There are some operating systems, eg BeOS and HPPA, where undefined symbols in shared libraries are normal.

               The BeOS kernel for example patches shared libraries at load time to select whichever function is most appropriate for the current architecture.  This is used, for example, to dynamically select an appropriate
               memset function.

       --error-handling-script=scriptname
           If  this  option is provided then the linker will invoke scriptname whenever an error is encountered.  Currently however only two kinds of error are supported: missing symbols and missing libraries.  Two arguments
           will be passed to script: the keyword "undefined‐symbol" or ‘missing-lib" and the name of the undefined symbol or missing library.  The intention is that the script will provide suggestions to the user as to where
           the symbol or library might be found.  After the script has finished then the normal linker error message will be displayed.

           The availability of this option is controlled by a configure time switch, so it may not be present in specific implementations.

       --no-undefined-version
           Normally when a symbol has an undefined version, the linker will ignore it. This option disallows symbols with undefined version and a fatal error will be issued