table will normally contain only those symbols which  are  referenced  by  some
           dynamic object mentioned in the link.

           If  you use "dlopen" to load a dynamic object which needs to refer back to the symbols defined by the program, rather than some other dynamic object, then you will probably need to use this option when linking the
           program itself.

           You can also use the dynamic list to control what symbols should be added to the dynamic symbol table if the output format supports it.  See the description of --dynamic-list.

           Note that this option is specific to ELF targeted ports.  PE targets support a similar function to export all symbols from a DLL or EXE; see the description of --export-all-symbols below.

       --export-dynamic-symbol=glob
           When creating a dynamically linked executable, symbols matching glob will be added to the dynamic symbol table. When creating a shared library, references to  symbols  matching  glob  will  not  be  bound  to  the
           definitions within the shared library. This option is a no‐op when creating a shared library and -Bsymbolic or --dynamic-list are not specified. This option is only meaningful on ELF platforms which support shared
           libraries.

       --export-dynamic-symbol-list=file
           Specify a --export-dynamic-symbol for each pattern in the file.  The format of the file is the same as the version node without scope and node name.  See VERSION for more information.

       -EB Link big‐endian objects.  This affects the default output format.

       -EL Link little‐endian objects.  This affects the default output format.

       -f name
       --auxiliary=name
           When creating an ELF shared object, set the internal DT_AUXILIARY field to the specified name.  This tells the dynamic linker that the symbol table of the shared object should be used as an auxiliary filter on the
           symbol table of the shared object name.

           If  you  later  link a program against this filter object, then, when you run the program, the dynamic linker will see the DT_AUXILIARY field.  If the dynamic linker resolves any symbols from the filter object, it
           will first check whether there is a definition in the shared object name.  If there is one, it will be used instead of the definition in the filter object.  The shared object name need not exist.  Thus the  shared
           object name may be used to provide an alternative implementation of certain functions, perhaps for debugging or for machine‐specific performance.

           This option may be specified more than once.  The DT_AUXILIARY entries will be created in the order in which they appear on the command line.

       -F name
       --filter=name
           When  creating  an  ELF  shared  object, set the internal DT_FILTER field to the specified name.  This tells the dynamic linker that the symbol table of the shared object which is being created should be used as a
           filter on the symbol table of the shared object name.

           If you later link a program against this filter object, then, when you run the program, the dynamic linker will see the DT_FILTER field.  The dynamic linker will resolve symbols according to the  symbol  table  of
           the filter object as usual, but it will actually link to the definitions found in the shared object name.  Thus the filter object can be used to select a subset of the symbols provided by the object name.

           Some  older  linkers  used the -F option throughout a compilation toolchain for specifying object‐file format for both input and output object files.  The GNU linker uses other mechanisms for this purpose: the -b,
           --format, --oformat options, the "TARGET" command in linker scripts, and the "GNUTARGET" environment variable.  The GNU linker will ignore the -F option when not creating an ELF shared object.

       -fini=name
           When creating an ELF