探讨背景:
最近编译xcode的工程,pod install之后,总是经常提示某个库找不到什么的,导致工程无法编译起来,但是看路径和工程下目录都是在的,所以猜测是不是xcode的缓存相关的问题,因为有时候是拉取了新的代码或者变动了Podfile,
image.png
解决这种明明在,却编译不过的问题,我自己发现可以通过Build Setting选项里面的Other Link Flag选项将找不到的库移除,然后本地目录也移除,然后重新pod install即可解决这个问题.
Other Link Flag参数
image.png
但是打开工程配置的一些参数的时候,发现里面对frameWork的引用方法不同,详情可以看上面的参数,有的frameWork前面带着-l, 有的就是-framework,还有-Objc,这分别代表什么区别呢吗,一直没有注意过,-objc和all_load大家可能了解的比较多,但是这几个参数的区别是什么呢,经过请教技术群的一些朋友,发现是代表的系统底层的一个命令对应的函数
终端执行 man ld即可看到对应的含义及介绍
General Commands Manual ld(1)
NAME
ld – linker
SYNOPSIS
ld files... [options] [-o outputfile]
DESCRIPTION
The ld command combines several object files and libraries, resolves
references, and produces an output file. ld can produce a final linked
image (executable, dylib, or bundle), or with the -r option, produce
another object file. If the -o option is not used, the output file
produced is named "a.out".
Universal
The linker accepts universal (multiple-architecture) input files, but
always creates a "thin" (single-architecture), standard Mach-O output file.
The architecture for the output file is specified using the -arch option.
If this option is not used, ld attempts to determine the output
architecture by examining the object files in command line order. The
first "thin" architecture determines that of the output file. If no input
object file is a "thin" file, the native 32-bit architecture for the host
is used.
The architecture for the output file is specified using the -arch option.
If this option is not used, ld attempts to determine the output
architecture by examining the object files in command line order. The
first "thin" architecture determines that of the output file. If no input
object file is a "thin" file, the native 32-bit architecture for the host
is used.
Usually, ld is not used directly. Instead the compiler driver invokes ld.
The compiler driver can be passed multiple -arch options and it will create
a universal final linked image by invoking ld multiple times and then
running lipo(1) merge the outputs into a universal file.
Layout
The object files are loaded in the order in which they are specified on the
command line. The segments and the sections in those segments will appear
in the output file in the order they are encountered in the object files
being linked. All zero fill sections will appear after all non-zero fill
sections in their segments.
Libraries
A static library (aka static archive) is a collection of .o files with a
table of contents that lists the global symbols in the .o files. ld will
only pull .o files out of a static library if needed to resolve some symbol
reference. Unlike traditional linkers, ld will continually search a static
library while linking. There is no need to specify a static library
multiple times on the command line.
A dynamic library (aka dylib or framework) is a final linked image.
Putting a dynamic library on the command line causes two things: 1) The
generated final linked image will have encoded that it depends on that
dynamic library. 2) Exported symbols from the dynamic library are used to
resolve references.
Both dynamic and static libraries are searched as they appear on the
command line.
Search paths
ld maintains a list of directories to search for a library or framework to
use. The default library search path is /usr/lib then /usr/local/lib. The
-L option will add a new library search path. The default framework search
path is /Library/Frameworks then /System/Library/Frameworks. (Note:
previously, /Network/Library/Frameworks was at the end of the default path.
If you need that functionality, you need to explicitly add
-F/Network/Library/Frameworks). The -F option will add a new framework
-L option will add a new library search path. The default framework search
path is /Library/Frameworks then /System/Library/Frameworks. (Note:
previously, /Network/Library/Frameworks was at the end of the default path.
If you need that functionality, you need to explicitly add
-F/Network/Library/Frameworks). The -F option will add a new framework
search path. The -Z option will remove the standard search paths. The
-syslibroot option will prepend a prefix to all search paths.
Two-level namespace
By default all references resolved to a dynamic library record the library
to which they were resolved. At runtime, dyld uses that information to
directly resolve symbols. The alternative is to use the -flat_namespace
option. With flat namespace, the library is not recorded. At runtime,
dyld will search each dynamic library in load order when resolving symbols.
This is slower, but more like how other operating systems resolve symbols.
Indirect dynamic libraries
If the command line specifies to link against dylib A, and when dylib A was
built it linked against dylib B, then B is considered an indirect dylib.
When linking for two-level namespace, ld does not look at indirect dylibs,
except when re-exported by a direct dylibs. On the other hand when linking
for flat namespace, ld does load all indirect dylibs and uses them to
resolve references. Even though indirect dylibs are specified via a full
path, ld first uses the specified search paths to locate each indirect
dylib. If one cannot be found using the search paths, the full path is
used.
Dynamic libraries undefines
When linking for two-level namespace, ld does not verify that undefines in
dylibs actually exist. But when linking for flat namespace, ld does check
that all undefines from all loaded dylibs have a matching definition. This
is sometimes used to force selected functions to be loaded from a static
library.
OPTIONS
Options that control the kind of output
-execute
The default. Produce a mach-o main executable that has file type
MH_EXECUTE.
-dylib Produce a mach-o shared library that has file type MH_DYLIB.
-bundle
Indirect dynamic libraries
If the command line specifies to link against dylib A, and when dylib A was
built it linked against dylib B, then B is considered an indirect dylib.
When linking for two-level namespace, ld does not look at indirect dylibs,
except when re-exported by a direct dylibs. On the other hand when linking
for flat namespace, ld does load all indirect dylibs and uses them to
resolve references. Even though indirect dylibs are specified via a full
path, ld first uses the specified search paths to locate each indirect
dylib. If one cannot be found using the search paths, the full path is
used.
Dynamic libraries undefines
When linking for two-level namespace, ld does not verify that undefines in
dylibs actually exist. But when linking for flat namespace, ld does check
that all undefines from all loaded dylibs have a matching definition. This
is sometimes used to force selected functions to be loaded from a static
library.
OPTIONS
Options that control the kind of output
-execute
The default. Produce a mach-o main executable that has file type
MH_EXECUTE.
-dylib Produce a mach-o shared library that has file type MH_DYLIB.
-bundle
Produce a mach-o bundle that has file type MH_BUNDLE.
-r Merges object files to produce another mach-o object file with file
type MH_OBJECT.
-dylinker
Produce a mach-o dylinker that has file type MH_DYLINKER. Only
used when building dyld.
-dynamic
The default. Implied by -dylib, -bundle, or -execute
-static
Produces a mach-o file that does not use the dyld. Only used
building the kernel.
-preload
Produces a mach-o file in which the mach_header, load commands, and
symbol table are not in any segment. This output type is used for
firmware or embedded development where the segments are copied out
of the mach-o into ROM/Flash.
-arch arch_name
Specifies which architecture (e.g. ppc, ppc64, i386, x86_64) the
output file should be.
-o path
Specifies the name and location of the output file. If not
specified, `a.out' is used.
Options that control libraries
-lx This option tells the linker to search for libx.dylib or libx.a in
the library search path. If string x is of the form y.o, then that
file is searched for in the same places, but without prepending
`lib' or appending `.a' or `.dylib' to the filename.
-needed-lx
This is the same as the -lx but means to really link with the dylib
even if no symbols are used from it. Thus, it can be used suppress
warnings about unused dylibs.
-reexport-lx
This is the same as the -lx but specifies that the all symbols in
library x should be available to clients linking to the library
being created. This was previously done with a separate
-sub_library option.
-arch arch_name
Specifies which architecture (e.g. ppc, ppc64, i386, x86_64) the
output file should be.
-o path
Specifies the name and location of the output file. If not
specified, `a.out' is used.
Options that control libraries
-lx This option tells the linker to search for libx.dylib or libx.a in
the library search path. If string x is of the form y.o, then that
file is searched for in the same places, but without prepending
`lib' or appending `.a' or `.dylib' to the filename.
-needed-lx
This is the same as the -lx but means to really link with the dylib
even if no symbols are used from it. Thus, it can be used suppress
warnings about unused dylibs.
-reexport-lx
This is the same as the -lx but specifies that the all symbols in
library x should be available to clients linking to the library
being created. This was previously done with a separate
-sub_library option.
:
-arch arch_name
Specifies which architecture (e.g. ppc, ppc64, i386, x86_64) the
output file should be.
-o path
Specifies the name and location of the output file. If not
specified, `a.out' is used.
Options that control libraries
-lx This option tells the linker to search for libx.dylib or libx.a in
the library search path. If string x is of the form y.o, then that
file is searched for in the same places, but without prepending
`lib' or appending `.a' or `.dylib' to the filename.
-needed-lx
This is the same as the -lx but means to really link with the dylib
even if no symbols are used from it. Thus, it can be used suppress
warnings about unused dylibs.
-reexport-lx
This is the same as the -lx but specifies that the all symbols in
library x should be available to clients linking to the library
being created. This was previously done with a separate
-sub_library option.
-upward-lx
This is the same as the -lx but specifies that the dylib is an
upward dependency.
-arch arch_name
Specifies which architecture (e.g. ppc, ppc64, i386, x86_64) the
output file should be.
-o path
Specifies the name and location of the output file. If not
specified, `a.out' is used.
Options that control libraries
-lx This option tells the linker to search for libx.dylib or libx.a in
the library search path. If string x is of the form y.o, then that
file is searched for in the same places, but without prepending
`lib' or appending `.a' or `.dylib' to the filename.
-needed-lx
This is the same as the -lx but means to really link with the dylib
even if no symbols are used from it. Thus, it can be used suppress
warnings about unused dylibs.
-reexport-lx
This is the same as the -lx but specifies that the all symbols in
library x should be available to clients linking to the library
being created. This was previously done with a separate
-sub_library option.
-upward-lx
This is the same as the -lx but specifies that the dylib is an
upward dependency.
-arch arch_name
Specifies which architecture (e.g. ppc, ppc64, i386, x86_64) the
output file should be.
-o path
Specifies the name and location of the output file. If not
specified, `a.out' is used.
Options that control libraries
-lx This option tells the linker to search for libx.dylib or libx.a in
the library search path. If string x is of the form y.o, then that
file is searched for in the same places, but without prepending
`lib' or appending `.a' or `.dylib' to the filename.
-needed-lx
This is the same as the -lx but means to really link with the dylib
even if no symbols are used from it. Thus, it can be used suppress
warnings about unused dylibs.
-reexport-lx
This is the same as the -lx but specifies that the all symbols in
library x should be available to clients linking to the library
being created. This was previously done with a separate
-sub_library option.
-upward-lx
This is the same as the -lx but specifies that the dylib is an
upward dependency.
-hidden-lx
This is the same as the -lx for locating a static library, but
treats all global symbols from the static library as if they are
visibility hidden. Useful when building a dynamic library that
:
-arch arch_name
Specifies which architecture (e.g. ppc, ppc64, i386, x86_64) the
output file should be.
-o path
Specifies the name and location of the output file. If not
specified, `a.out' is used.
Options that control libraries
-lx This option tells the linker to search for libx.dylib or libx.a in
the library search path. If string x is of the form y.o, then that
file is searched for in the same places, but without prepending
`lib' or appending `.a' or `.dylib' to the filename.
-needed-lx
This is the same as the -lx but means to really link with the dylib
even if no symbols are used from it. Thus, it can be used suppress
warnings about unused dylibs.
-reexport-lx
This is the same as the -lx but specifies that the all symbols in
library x should be available to clients linking to the library
being created. This was previously done with a separate
-sub_library option.
-upward-lx
This is the same as the -lx but specifies that the dylib is an
upward dependency.
-hidden-lx
This is the same as the -lx for locating a static library, but
treats all global symbols from the static library as if they are
visibility hidden. Useful when building a dynamic library that
uses a static library but does not want to export anything from
that static library.
:
-arch arch_name
Specifies which architecture (e.g. ppc, ppc64, i386, x86_64) the
output file should be.
-o path
Specifies the name and location of the output file. If not
specified, `a.out' is used.
Options that control libraries
-lx This option tells the linker to search for libx.dylib or libx.a in
the library search path. If string x is of the form y.o, then that
file is searched for in the same places, but without prepending
`lib' or appending `.a' or `.dylib' to the filename.
-needed-lx
This is the same as the -lx but means to really link with the dylib
even if no symbols are used from it. Thus, it can be used suppress
warnings about unused dylibs.
-reexport-lx
This is the same as the -lx but specifies that the all symbols in
library x should be available to clients linking to the library
being created. This was previously done with a separate
-sub_library option.
-upward-lx
This is the same as the -lx but specifies that the dylib is an
upward dependency.
-hidden-lx
This is the same as the -lx for locating a static library, but
treats all global symbols from the static library as if they are
visibility hidden. Useful when building a dynamic library that
uses a static library but does not want to export anything from
that static library.
-weak-lx
This is the same as the -lx but forces the library and all
-arch arch_name
Specifies which architecture (e.g. ppc, ppc64, i386, x86_64) the
output file should be.
-o path
Specifies the name and location of the output file. If not
specified, `a.out' is used.
Options that control libraries
-lx This option tells the linker to search for libx.dylib or libx.a in
the library search path. If string x is of the form y.o, then that
file is searched for in the same places, but without prepending
`lib' or appending `.a' or `.dylib' to the filename.
-needed-lx
This is the same as the -lx but means to really link with the dylib
even if no symbols are used from it. Thus, it can be used suppress
warnings about unused dylibs.
-reexport-lx
This is the same as the -lx but specifies that the all symbols in
library x should be available to clients linking to the library
being created. This was previously done with a separate
-sub_library option.
-upward-lx
This is the same as the -lx but specifies that the dylib is an
upward dependency.
-hidden-lx
This is the same as the -lx for locating a static library, but
treats all global symbols from the static library as if they are
visibility hidden. Useful when building a dynamic library that
uses a static library but does not want to export anything from
that static library.
-weak-lx
This is the same as the -lx but forces the library and all
references to it to be marked as weak imports. That is, the
:
-arch arch_name
Specifies which architecture (e.g. ppc, ppc64, i386, x86_64) the
output file should be.
-o path
Specifies the name and location of the output file. If not
specified, `a.out' is used.
Options that control libraries
-lx This option tells the linker to search for libx.dylib or libx.a in
the library search path. If string x is of the form y.o, then that
file is searched for in the same places, but without prepending
`lib' or appending `.a' or `.dylib' to the filename.
-needed-lx
This is the same as the -lx but means to really link with the dylib
even if no symbols are used from it. Thus, it can be used suppress
warnings about unused dylibs.
-reexport-lx
This is the same as the -lx but specifies that the all symbols in
library x should be available to clients linking to the library
being created. This was previously done with a separate
-sub_library option.
-upward-lx
This is the same as the -lx but specifies that the dylib is an
upward dependency.
-hidden-lx
This is the same as the -lx for locating a static library, but
treats all global symbols from the static library as if they are
visibility hidden. Useful when building a dynamic library that
uses a static library but does not want to export anything from
that static library.
-weak-lx
This is the same as the -lx but forces the library and all
references to it to be marked as weak imports. That is, the
library is allowed to be missing at runtime.
:
-arch arch_name
Specifies which architecture (e.g. ppc, ppc64, i386, x86_64) the
output file should be.
-o path
Specifies the name and location of the output file. If not
specified, `a.out' is used.
Options that control libraries
-lx This option tells the linker to search for libx.dylib or libx.a in
the library search path. If string x is of the form y.o, then that
file is searched for in the same places, but without prepending
`lib' or appending `.a' or `.dylib' to the filename.
-needed-lx
This is the same as the -lx but means to really link with the dylib
even if no symbols are used from it. Thus, it can be used suppress
warnings about unused dylibs.
-reexport-lx
This is the same as the -lx but specifies that the all symbols in
library x should be available to clients linking to the library
being created. This was previously done with a separate
-sub_library option.
-upward-lx
This is the same as the -lx but specifies that the dylib is an
upward dependency.
-hidden-lx
This is the same as the -lx for locating a static library, but
treats all global symbols from the static library as if they are
visibility hidden. Useful when building a dynamic library that
uses a static library but does not want to export anything from
that static library.
-weak-lx
This is the same as the -lx but forces the library and all
references to it to be marked as weak imports. That is, the
library is allowed to be missing at runtime.
-needed_library path_to_dylib
This is the same as placing path_to_dylib on the link line but
means to really link with the dylib even if no symbols are used
from it. Thus, it can be used suppress warnings about unused
dylibs.
-reexport_library path_to_library
This is the same as listing a file name path to a library on the
link line and it specifies that the all symbols in library path
should be available to clients linking to the library being
created. This was previously done with a separate -sub_library
option.
-upward_library path_to_library
This is the same as listing a file name path to a library on the
link line but also marks the dylib as an upward dependency.
-weak_library path_to_library
This is the same as listing a file name path to a library on the
link line except that it forces the library and all references to
it to be marked as weak imports.
-Ldir Add dir to the list of directories in which to search for
libraries. Directories specified with -L are searched in the order
they appear on the command line and before the default search path.
In Xcode4 and later, there can be a space between the -L and
directory.
-Z Do not search the standard directories when searching for libraries
and frameworks.
-syslibroot rootdir
Prepend rootdir to all search paths when searching for libraries or
frameworks.
-search_paths_first
This is now the default (in Xcode4 tools). When processing -lx the
linker now searches each directory in its library search paths for
`libx.dylib' then `libx.a' before the moving on to the next path in
the library search path.
-search_dylibs_first
Changes the searching behavior for libraries. The default is that
when processing -lx the linker searches each directory in its
library search paths for `libx.dylib' then `libx.a'. This option
changes the behavior to first search for a file of the form
`libx.dylib' in each directory in the library search path, then a
file of the form `libx.a' is searched for in the library search
paths. This option restores the search behavior of the linker
prior to Xcode4.
-framework name[,suffix]
This option tells the linker to search for `name.framework/name'
the framework search path. If the optional suffix is specified the
framework is first searched for the name with the suffix and then
without (e.g. look for `name.framework/name_suffix' first, if not
there try `name.framework/name').
-needed_framework name[,suffix]
This is the same as the -framework name[,suffix] but means to
really link with the framework even if no symbols are used from it.
Thus, it can be used suppress warnings about unused dylibs.
-weak_framework name[,suffix]
This is the same as the -framework name[,suffix] but forces the
framework and all references to it to be marked as weak imports.
Note: due to a clang optimizations, if functions are not marked
weak, the compiler will optimize out any checks if the function
address is NULL.
ld(1) General Commands Manual ld(1)
NAME
ld – linker
SYNOPSIS
ld files... [options] [-o outputfile]
DESCRIPTION
The ld command combines several object files and libraries, resolves
references, and produces an output file. ld can produce a final linked
image (executable, dylib, or bundle), or with the -r option, produce
another object file. If the -o option is not used, the output file
produced is named "a.out".
Universal
The linker accepts universal (multiple-architecture) input files, but
always creates a "thin" (single-architecture), standard Mach-O output file.
The architecture for the output file is specified using the -arch option.
If this option is not used, ld attempts to determine the output
architecture by examining the object files in command line order. The
first "thin" architecture determines that of the output file. If no input
object file is a "thin" file, the native 32-bit architecture for the host
is used.
Usually, ld is not used directly. Instead the compiler driver invokes ld.
The compiler driver can be passed multiple -arch options and it will create
a universal final linked image by invoking ld multiple times and then
running lipo(1) merge the outputs into a universal file.
Layout
The object files are loaded in the order in which they are specified on the
command line. The segments and the sections in those segments will appear
in the output file in the order they are encountered in the object files
being linked. All zero fill sections will appear after all non-zero fill
sections in their segments.
Libraries
A static library (aka static archive) is a collection of .o files with a
table of contents that lists the global symbols in the .o files. ld will
only pull .o files out of a static library if needed to resolve some symbol
reference. Unlike traditional linkers, ld will continually search a static
library while linking. There is no need to specify a static library
multiple times on the command line.
A dynamic library (aka dylib or framework) is a final linked image.
Putting a dynamic library on the command line causes two things: 1) The
generated final linked image will have encoded that it depends on that
dynamic library. 2) Exported symbols from the dynamic library are used to
resolve references.
Both dynamic and static libraries are searched as they appear on the
command line.
Search paths
ld maintains a list of directories to search for a library or framework to
use. The default library search path is /usr/lib then /usr/local/lib. The
-L option will add a new library search path. The default framework search
path is /Library/Frameworks then /System/Library/Frameworks. (Note:
previously, /Network/Library/Frameworks was at the end of the default path.
If you need that functionality, you need to explicitly add
-F/Network/Library/Frameworks). The -F option will add a new framework
search path. The -Z option will remove the standard search paths. The
-syslibroot option will prepend a prefix to all search paths.
Two-level namespace
By default all references resolved to a dynamic library record the library
to which they were resolved. At runtime, dyld uses that information to
directly resolve symbols. The alternative is to use the -flat_namespace
option. With flat namespace, the library is not recorded. At runtime,
dyld will search each dynamic library in load order when resolving symbols.
This is slower, but more like how other operating systems resolve symbols.
Indirect dynamic libraries
If the command line specifies to link against dylib A, and when dylib A was
built it linked against dylib B, then B is considered an indirect dylib.
When linking for two-level namespace, ld does not look at indirect dylibs,
except when re-exported by a direct dylibs. On the other hand when linking
for flat namespace, ld does load all indirect dylibs and uses them to
resolve references. Even though indirect dylibs are specified via a full
path, ld first uses the specified search paths to locate each indirect
dylib. If one cannot be found using the search paths, the full path is
used.
Dynamic libraries undefines
When linking for two-level namespace, ld does not verify that undefines in
dylibs actually exist. But when linking for flat namespace, ld does check
that all undefines from all loaded dylibs have a matching definition. This
is sometimes used to force selected functions to be loaded from a static
library.
OPTIONS
Options that control the kind of output
-execute
The default. Produce a mach-o main executable that has file type
MH_EXECUTE.
-dylib Produce a mach-o shared library that has file type MH_DYLIB.
-bundle
Produce a mach-o bundle that has file type MH_BUNDLE.
-r Merges object files to produce another mach-o object file with file
type MH_OBJECT.
-dylinker
Produce a mach-o dylinker that has file type MH_DYLINKER. Only
used when building dyld.
-dynamic
The default. Implied by -dylib, -bundle, or -execute
-static
Produces a mach-o file that does not use the dyld. Only used
building the kernel.
-preload
Produces a mach-o file in which the mach_header, load commands, and
symbol table are not in any segment. This output type is used for
firmware or embedded development where the segments are copied out
of the mach-o into ROM/Flash.
-arch arch_name
Specifies which architecture (e.g. ppc, ppc64, i386, x86_64) the
output file should be.
-o path
Specifies the name and location of the output file. If not
specified, `a.out' is used.
Options that control libraries
-lx This option tells the linker to search for libx.dylib or libx.a in
the library search path. If string x is of the form y.o, then that
file is searched for in the same places, but without prepending
`lib' or appending `.a' or `.dylib' to the filename.
-needed-lx
This is the same as the -lx but means to really link with the dylib
even if no symbols are used from it. Thus, it can be used suppress
warnings about unused dylibs.
-reexport-lx
This is the same as the -lx but specifies that the all symbols in
library x should be available to clients linking to the library
being created. This was previously done with a separate
-sub_library option.
-upward-lx
This is the same as the -lx but specifies that the dylib is an
upward dependency.
-hidden-lx
This is the same as the -lx for locating a static library, but
treats all global symbols from the static library as if they are
visibility hidden. Useful when building a dynamic library that
uses a static library but does not want to export anything from
that static library.
-weak-lx
This is the same as the -lx but forces the library and all
references to it to be marked as weak imports. That is, the
library is allowed to be missing at runtime.
-needed_library path_to_dylib
This is the same as placing path_to_dylib on the link line but
means to really link with the dylib even if no symbols are used
from it. Thus, it can be used suppress warnings about unused
dylibs.
-reexport_library path_to_library
This is the same as listing a file name path to a library on the
link line and it specifies that the all symbols in library path
should be available to clients linking to the library being
created. This was previously done with a separate -sub_library
option.
-upward_library path_to_library
This is the same as listing a file name path to a library on the
link line but also marks the dylib as an upward dependency.
-weak_library path_to_library
This is the same as listing a file name path to a library on the
link line except that it forces the library and all references to
it to be marked as weak imports.
-Ldir Add dir to the list of directories in which to search for
libraries. Directories specified with -L are searched in the order
they appear on the command line and before the default search path.
In Xcode4 and later, there can be a space between the -L and
directory.
-Z Do not search the standard directories when searching for libraries
and frameworks.
-syslibroot rootdir
Prepend rootdir to all search paths when searching for libraries or
frameworks.
-search_paths_first
This is now the default (in Xcode4 tools). When processing -lx the
linker now searches each directory in its library search paths for
`libx.dylib' then `libx.a' before the moving on to the next path in
the library search path.
-search_dylibs_first
Changes the searching behavior for libraries. The default is that
when processing -lx the linker searches each directory in its
library search paths for `libx.dylib' then `libx.a'. This option
changes the behavior to first search for a file of the form
`libx.dylib' in each directory in the library search path, then a
file of the form `libx.a' is searched for in the library search
paths. This option restores the search behavior of the linker
prior to Xcode4.
-framework name[,suffix]
This option tells the linker to search for `name.framework/name'
the framework search path. If the optional suffix is specified the
framework is first searched for the name with the suffix and then
without (e.g. look for `name.framework/name_suffix' first, if not
there try `name.framework/name').
-needed_framework name[,suffix]
This is the same as the -framework name[,suffix] but means to
really link with the framework even if no symbols are used from it.
Thus, it can be used suppress warnings about unused dylibs.
-weak_framework name[,suffix]
This is the same as the -framework name[,suffix] but forces the
framework and all references to it to be marked as weak imports.
Note: due to a clang optimizations, if functions are not marked
weak, the compiler will optimize out any checks if the function
address is NULL.
-reexport_framework name[,suffix]
This is the same as the -framework name[,suffix] but also specifies
that the all symbols in that framework should be available to
clients linking to the library being created. This was previously
done with a separate -sub_umbrella option.
-upward_framework name[,suffix]
This is the same as the -framework name[,suffix] but also specifies
that the framework is an upward dependency.
-Fdir Add dir to the list of directories in which to search for
frameworks. Directories specified with -F are searched in the
order they appear on the command line and before the default search
path. In Xcode4 and later, there can be a space between the -F and
directory.
-all_load
Loads all members of static archive libraries.
-ObjC Loads all members of static archive libraries that implement an
Objective-C class or category.
-force_load path_to_archive
Loads all members of the specified static archive library. Note:
-all_load forces all members of all archives to be loaded. This
option allows you to target a specific archive.
-load_hidden path_to_archive
Uses specified static library as usual, but treats all global
symbols from the static library to as if they are visibility
hidden. Useful when building a dynamic library that uses a static
library but does not want to export anything from that static
library.
-image_suffix suffix
Search for libraries and frameworks with suffix and then without
(e.g. look for `name.framework/name_suffix' first, if not there try
`name.framework/name', or `libname_suffix.a' first, if not there
try `libname.a').
Options that control additional content
-sectcreate segname sectname file
The section sectname in the segment segname is created from the
:
