ld-classic(1)

📦 version 957.1, in nixpkgs unstable

💖 NAME 💖

okay so bestie, this is ld-classic(1) — the linker. That’s the whole name. We are in the General Commands Manual corner of the universe and yes, it’s giving iconic build-tool energy already 💅✨

✨ SYNOPSIS ✨

ld-classic files...  [options] [-o outputfile]

🎀 DESCRIPTION 🎀

The ld-classic command combines several object files and libraries, resolves references, and produces an output file. Slay. ld-classic 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-classic 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-classic is not used directly. Instead the compiler driver invokes ld-classic. The compiler driver can be passed multiple -arch options and it will create a universal final linked image by invoking ld-classic multiple times and then running lipo(1) to merge the outputs into a universal file. bestie behavior fr fr 🦋

🌸 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-classic will only pull .o files out of a static library if needed to resolve some symbol reference. Unlike traditional linkers, ld-classic will continually search a static library while linking. There is no need to specify a static library multiple times on the command line. obsessed with the efficiency, honestly ✨

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-classic 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. not the vibe for speed, but sometimes you need it 💀

🌈 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-classic 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-classic does not verify that undefines in dylibs actually exist. But when linking for flat namespace, ld-classic 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 to suppress warnings about unused dylibs.
  • -reexport-lx — This is the same as the -lx but specifies that 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 to 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 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 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 in 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 to 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 optimization, if functions are not marked weak, the compiler will optimize out any checks if the function address is NULL.
  • -reexport_framework name[,suffix] — same energy as -framework name[,suffix], but it also says that all symbols in that framework should be available to clients linking to the library being created 💅 This used to be done with a separate -sub_umbrella option.
  • -upward_framework name[,suffix] — same as -framework name[,suffix], but it also tells the linker that the framework is an upward dependency 🦋
  • -Fdir — adds dir to the list of directories where the linker searches for frameworks. Directories you specify with -F get 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. all of them. no skips 👑
  • -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 lets you target one specific archive 🎯
  • -load_hidden path_to_archive — uses the specified static library as usual, but treats all global symbols from that static library as if they are visibility hidden. Useful when you're building a dynamic library that uses a static library but does not want to export anything from that static library 🙈
  • -image_suffix suffix — searches for libraries and frameworks with suffix first, and then without it 🔎

🧩 Options that control additional content

  • -sectcreate segname sectname file — creates the section sectname in the segment segname from the contents of file. If there's already a section (segname,sectname) from any other input, the linker will append the content from file to that section 🧵
  • -add_empty_section segname sectname — makes an empty section named sectname in the segment segname. If any of the inputs contains a section (segname,sectname), that section will be included in the output, and this option will be ignored 🫶
  • -add_ast_path file — the linker will add an N_AST stab symbol to the output file where the string is the path pointed to by file and its value is the modification time of the file ⏰
  • -filelist file[,dirname] — tells the linker to link the files listed in file. This is an alternative to listing the files on the command line. The file names are listed one per line, separated only by newlines. (Spaces and tabs are assumed to be part of the file name.) If the optional directory name dirname is specified, it is prepended to each name in the list file 📝
  • -dtrace file — enables dtrace static probes when producing a final linked image. The file must be a DTrace script which declares the static probes 🔬

⚡ Options that control optimizations

  • -dead_strip — removes functions and data that are unreachable by the entry point or exported symbols 💀
  • -order_file file — alters the order in which functions and data are laid out. For each section in the output file, any symbol in that section that's specified in the order file file is moved to the start of its section and laid out in the same order as in the order file file. Order files are text files with one symbol name per line. Lines starting with a # are comments. A symbol name may be optionally preceded with its object file leaf name and a colon (e.g. foo.o:_foo). This is useful for static functions/data that occur in multiple files. A symbol name may also be optionally preceded with the architecture (e.g. ppc:_foo or ppc:foo.o:_foo). This enables you to have one order file that works for multiple architectures. Literal c-strings may be ordered by quoting the string (e.g. "Hello, world\n") in the order file 🗂️
  • -no_order_inits — when the -order_file option is not used, the linker lays out functions in object file order and it moves all initializer routines to the start of the __text section and terminator routines to the end. Use this option to disable the automatic rearrangement of initializers and terminators 🙅‍♀️
  • -platform_version platform min_version sdk_version — this is set to indicate the platform, the oldest supported version of that platform that the output is to be used on, and the SDK that the output was built against. platform is a numeric value as defined in <mach-o/loader.h>, or it may be one of the following strings:
    • macos
    • ios
    • tvos
    • watchos
    • bridgeos
    • mac-catalyst
    • ios-simulator
    • tvos-simulator
    • watchos-simulator
    • driverkit

Specifying a newer min or SDK version enables the linker to assume features of that OS or SDK in the output file. The format of min_version and sdk_version is a version number such as 10.13 or 10.14 🌈

  • -macos_version_min version — this is set to indicate the oldest macOS version that the output is to be used on. Specifying a later version enables the linker to assume features of that OS in the output file. The format of version is a macOS version number such as 10.9 or 10.14 🍎
  • -ios_version_min version — this is set to indicate the oldest iOS version that the output is to be used on. Specifying a later version enables the linker to assume features of that OS in the output file. The format of version is an iOS version number such as 3.1 or 4.0 📱
  • -image_base address — specifies the preferred load address for a dylib or bundle. The argument address is a hexadecimal number with an optional leading 0x. By choosing non-overlapping addresses for all dylibs and bundles that a program loads, launch time can be improved because dyld will not need to "rebase" the image (that is, adjust pointers within the image to work at the loaded address). It is often easier to not use this option, but instead use the rebase(1) tool, and give it a list of dylibs. It will then choose non-overlapping addresses for the list and rebase them all. When building a position independent executable, this option will be ignored. This option is also called -seg1addr for compatibility 🏠
  • -no_implicit_dylibs — when creating a two-level namespace final linked image, normally the linker will hoist up public dylibs that are implicitly linked to make the two-level namespace encoding more efficient for dyld. For example, Cocoa re-exports AppKit and AppKit re-exports Foundation. If you link with -framework Cocoa and use a symbol from Foundation, the linker will implicitly add a load command to load Foundation and encode the symbol as coming from Foundation. If you use this option, the linker will not add a load command for Foundation and encode the symbol as coming from Cocoa. Then at runtime dyld will have to search Cocoa and AppKit before finding the symbol in Foundation 🔍
  • -no_zero_fill_sections — by default the linker moves all zero fill sections to the end of the __DATA segment and configures them to use no space on disk. This option suppresses that optimization, so zero-filled data occupies space on disk in a final linked image 💾
  • -merge_zero_fill_sections — causes all zero-fill sections in the __DATA segment to be merged into one __zerofill section 🧼
  • -no_branch_islands — disables linker creation of branch islands, which allows images to be created that are larger than the maximum branch distance. Useful with -preload when code is in multiple sections but all are within the branch range 🌉

🧚 Options when creating a dynamic library (dylib)

  • -install_name name — sets an internal "install path" (LC_ID_DYLIB) in a dynamic library. Any clients linked against the library will record that path as the way dyld should locate this library. If this option is not specified, then the -o path will be used. This option is also called -dylib_install_name for compatibility 🏷️
  • -mark_dead_strippable_dylib — specifies that the dylib being built can be dead strip by any client. That is, the dylib has no initialization side effects. So if a client links against the dylib, but never uses any symbol from it, the linker can optimize away the use of the dylib ✂️
  • -compatibility_version number — specifies the compatibility version number of the library. When a library is loaded by dyld, the compatibility version is checked and if the program's version is greater than the library's version, it is an error. The format of number is X[.Y[.Z]] where X must be a positive non-zero number less than or equal to 65535, and .Y and .Z are optional and if present must be non-negative numbers less than or equal to 255. If the compatibility version number is not specified, it has a value of 0 and no checking is done when the library is used. This option is also called -dylib_compatibility_version for compatibility 🧸
  • -current_version number — specifies the current version number of the library. The current version of the library can be obtained programmatically by the user of the library so it can determine exactly which version of the library it is using. The format of number is X[.Y[.Z]] where X must be a positive non-zero number less than or equal to 65535, and .Y and .Z are optional and if present must be non-negative numbers less than or equal to 255. If the version number is not specified, it has a value of 0. This option is also called -dylib_current_version for compatibility 💖

🎀 Options when creating a main executable 🎀

  • -pie — makes a special kind of main executable that's position independent, aka a PIE ✨. On Mac OS X 10.5 and later, the OS will load a PIE at a random address every single time it gets executed. Iconic security behavior honestly. But — you cannot create a PIE from .o files compiled with -mdynamic-no-pic, so heads up. That means the codegen is less optimal, but the address randomization adds some security. And when targeting Mac OS X 10.7 or later, PIE is the default for main executables 💅.
  • -no_pie — do not make a position independent executable (PIE). This is the default when targeting 10.6 and earlier. Old school vibes 🫶.
  • -pagezero_size size — by default the linker creates an unreadable segment starting at address zero named __PAGEZERO. Its whole existence will cause a bus error if a NULL pointer gets dereferenced — it's literally there to catch you 😭. The argument size is a hexadecimal number with an optional leading 0x. If size is zero, the linker will not generate a page zero segment at all. Defaults: on 32-bit architectures the page zero size is 4KB, and on 64-bit architectures the default size is 4GB. Big mood, big page 💀.
  • implicit_pagezero — when used on main executables, it omits the __PAGEZERO segment and relies on the loader blocking out low memory instead. Leaning on the loader, respectfully 🙈.
  • -stack_size size — specifies the maximum stack size for the main thread in a program. Without this option a program has a 8MB stack. The argument size is a hexadecimal number with an optional leading 0x, and it should be a multiple of the architecture's page size (4KB or 16KB) ⭐.
  • -allow_stack_execute — marks the executable so that all stacks in the task get stack execution privilege. This includes pthread stacks, fr fr. This option is only valid when targeting architectures that support stack execution (i.e. Intel) 🧚.
  • -export_dynamic — preserves all global symbols in main executables during LTO. Without this option, Link Time Optimization is allowed to inline and remove global functions — which is exactly the drama this prevents. This option is used when a main executable may load a plug-in which requires certain symbols from the main executable. Plug-in support, we love to see it 💖.

🦋 Options when creating a bundle 🦋

  • -bundle_loader executable — this specifies the executable that will be loading the bundle output file being linked. Undefined symbols from the bundle are checked against the specified executable like it was one of the dynamic libraries the bundle was linked with. Basically the bundle gets to borrow its friend's symbol table 😌.

🌸 Options when creating an object file 🌸

  • -keep_private_externs — don't turn private external (aka visibility=hidden) symbols into static symbols, but rather leave them as private external in the resulting object file. Keep them exactly as they are, no notes 👑.
  • -d — force definition of common symbols. That is, transform tentative definitions into real definitions. Tentative no more, bestie — it's committing ✨.

💜 Options that control symbol resolution 💜

  • -exported_symbols_list filename — the specified filename contains a list of global symbol names that will remain as global symbols in the output file. All other global symbols will be treated as if they were marked as __private_extern__ (aka visibility=hidden) and will not be global in the output file. The symbol names listed in filename must be one per line. Leading and trailing white space are not part of the symbol name. Lines starting with # are ignored, as are lines with only white space. Some wildcards (similar to shell file matching) are supported: the * matches zero or more characters, the ? matches one character, [abc] matches one character which must be an 'a', 'b', or 'c', and [a-z] matches any single lower case letter from 'a' to 'z' 🌈.
  • -exported_symbol symbol — the specified symbol is added to the list of global symbol names that will remain as global symbols in the output file. This option can be used multiple times. For short lists, this can be more convenient than creating a file and using -exported_symbols_list 🎀.
  • -no_exported_symbols — useful for main executables that don't have plugins and thus need no symbol exports. No plugins, no problems 💅.
  • -unexported_symbols_list file — the specified filename contains a list of global symbol names that will not remain as global symbols in the output file. The symbols will be treated as if they were marked as __private_extern__ (aka visibility=hidden) and will not be global in the output file. The symbol names listed in filename must be one per line. Leading and trailing white space are not part of the symbol name. Lines starting with # are ignored, as are lines with only white space. Some wildcards (similar to shell file matching) are supported: the * matches zero or more characters, the ? matches one character, [abc] matches one character which must be an 'a', 'b', or 'c', and [a-z] matches any single lower case letter from 'a' to 'z' ⭐.
  • -unexported_symbol symbol — the specified symbol is added to the list of global symbol names that will not remain as global symbols in the output file. This option can be used multiple times. For short lists, this can be more convenient than creating a file and using -unexported_symbols_list 🫶.
  • -reexported_symbols_list file — the specified filename contains a list of symbol names that are implemented in a dependent dylib and should be re-exported through the dylib being created. Sharing the wealth, we stan 🌸.
  • -alias symbol_name alternate_symbol_name — creates an alias named alternate_symbol_name for the symbol symbol_name. By default the alias symbol has global visibility. This option was previously the -idef:indir option, fyi 👀.
  • -alias_list filename — the specified filename contains a list of aliases. The symbol name and its alias are on one line, separated by whitespace. Lines starting with # are ignored.
  • -flat_namespace — alters how symbols are resolved at build time and runtime. With -two_levelnamespace (the default), the linker only searches dylibs on the command line for symbols, and records in which dylib they were found. With -flat_namespace, the linker searches all dylibs on the command line and all dylibs those original dylibs depend on. The linker does not record which dylib an external symbol came from, so at runtime dyld again searches all images and uses the first definition it finds. In addition, any undefines in loaded flat_namespace dylibs must be resolvable at build time. It's giving chaos but make it deterministic 💀.
  • -u symbol_name — specifies that symbol symbol_name must be defined for the link to succeed. This is useful to force selected functions to be loaded from a static library. Required means required 🔥.
  • -U symbol_name — specifies that it's ok for symbol_name to have no definition. With -two_levelnamespace, the resulting symbol will be marked dynamic_lookup which means dyld will search all loaded images. No definition? No stress 😌.
  • -undefined treatment — specifies how undefined symbols are to be treated. Options are: error, warning, suppress, or dynamic_lookup. The default is error. Note: dynamic_lookup that depends on lazy binding will not work with chained fixups ⚠️.
  • -rpath path — adds path to the runpath search path list for the image being created. At runtime, dyld uses the runpath when searching for dylibs whose load path begins with @rpath/. Path list glow-up 💖.
  • -commons treatment — specifies how commons (aka tentative definitions) are resolved with respect to dylibs. Options are: ignore_dylibs, use_dylibs, error. The default is ignore_dylibs which means the linker will turn a tentative definition in an object file into a real definition and not even check dylibs for conflicts — it simply does not look 👑. The use_dylibs option means the linker should check linked dylibs for definitions and use them to replace tentative definitions from object files. The error option means the linker should issue an error whenever a tentative definition in an object file conflicts with an external symbol in a linked dylib. See also -warn_commons ✨.

🔥 Options for introspecting the linker 🔥

  • -why_load — logs why each object file in a static library is loaded. That is, what symbol was needed. Also called -whyload for compatibility. Detective mode activated 🕵️.
  • -why_live symbol_name — logs a chain of references to symbol_name. Only applicable with -dead_strip. It can help debug why something that you think should be dead strip removed is not removed 😭. See -exported_symbols_list for syntax and use of wildcards.
  • -print_statistics — logs information about the amount of memory and time the linker used. Receipts, basically 🧾.
  • -t — logs each file (object, archive, or dylib) the linker loads. Useful for debugging problems with search paths where the wrong library is loaded. Wrong library jumpscare prevention 💀.
  • -order_file_statistics — logs information about the processing of a -order_file.
  • -map map_file_path — writes a map file to the specified path which details all symbols and their addresses in the output image. The whole map, no gatekeeping 🗺️.

🌈 Options for controlling symbol table optimizations 🌈

  • -S — do not put debug information (STABS or DWARF) in the output file. Slimming it down 💅.
  • -x — do not put non-global symbols in the output file's symbol table. Non-global symbols are useful when debugging and getting symbol names in back traces, but are not used at runtime. If -x is used with -r, non-global symbol names are not removed, but instead replaced with a unique, dummy name that will be automatically removed when linked into a final linked image. This allows dead code stripping, which uses symbols to break up code and data, to work properly and provides the security of having source symbol names removed. Dummy names are the ultimate undercover mission 🕶️.
  • -non_global_symbols_strip_list filename — the specified filename contains a list of non-global symbol names that should be removed from the output file's symbol table. All other non-global symbol names will remain in the output file's symbol table. See -exported_symbols_list for syntax and use of wildcards 🎀.
  • -non_global_symbols_no_strip_list filename — bestie, this file is a list of non-global symbol names that should remain in the output file's symbol table. Every other symbol name gets removed from that table. For the syntax and wildcard lore, see -exported_symbols_list. 💅
  • -oso_prefix prefix-path — when the linker generates the debug map, it removes this prefix-path from the path in OSO symbols. Why? So build servers can generate identical binaries. If '.' is passed as the argument, the linker expands it to the current working directory. ✨

✨ Options for Bitcode build flow ✨

  • -bitcode_bundle — generates an embedded bitcode bundle in the output binary, and it lives in the __LLVM, __bundle section. Big caveat: this option requires all the object files, static libraries and user frameworks/dylibs contain bitcode. Also note: not all the linker options are supported to use together with -bitcode_bundle. 😭
  • -bitcode_hide_symbols — use this together with -bitcode_bundle to hide all non-exported symbols from the output bitcode bundle. Heads up: the hide symbol process might not be reversible. To obtain a reverse mapping file to recover all the symbols, use the -bitcode_symbol_map option. 🫶
  • -bitcode_symbol_map path — sets the output for the bitcode symbol reverse mapping (.bcsymbolmap). If path is an existing directory, UUID.bcsymbolmap will be written to that directory. Otherwise, the reverse map will be written to a file at path. 🎀

✨ Rarely used Options ✨

  • @response_file_path — inserts the contents of the file at response_file_path into the arguments. This lets linker command line args be stored in a file. Important note: ld is normally invoked through clang, and clang also interprets @file on the command line. To have clang ignore the @file and pass it through to ld, use -Wl,@file. 💀
  • -v — prints the version of the linker. Simple, iconic, does what it says. ⭐
  • -adhoc_codesign — directs the linker to add an ad-hoc codesignature to the output file. The default for Apple Silicon binaries is to be ad-hoc codesigned. 🍓
  • -no_adhoc_codesign — directs the linker to not add an ad-hoc codesignature to the output file, even for Apple Silicon binaries. 🙈
  • -data_const — by default the linker moves some data sections into __DATA_CONST if it knows the target OS version supports that. This option overrides the default behavior and forces the use of __DATA_CONST. 💅
  • -no_data_const — by default the linker moves some data sections into __DATA_CONST if it knows the target OS version supports that. This option overrides the default behavior and forces the linker to never move sections to __DATA_CONST. 🚫
  • -const_selrefs — by default the linker moves the __objc_selrefs section into __DATA_CONST if it knows the target OS version supports that. This option overrides the default behavior and forces __objc_selrefs being in __DATA_CONST. Note this only applies if the __DATA_CONST segment is enabled. See -data_const for more information. 🦋
  • -no_const_selrefs — by default the linker moves the __objc_selrefs section into __DATA_CONST if it knows the target OS version supports that. This option overrides the default behavior and keeps the __objc_selrefs section in __DATA. 🌸
  • -version_details — prints the version info about the linker in JSON. It's giving structured data realness. 📊
  • -no_weak_imports — error if any symbols are weak imports (i.e. allowed to be unresolved (NULL) at runtime). Useful for config based projects that assume they are built and run on the same OS version. ⚠️
  • -no_deduplicate — don't run the deduplication pass in the linker. No cap, sometimes you just don't want the linker touching your duplicate-looking stuff. 🧚
  • -verbose_deduplicate — prints names of functions that are eliminated by deduplication and total code savings size. Receipts! 🧾
  • -no_inits — error if the output contains any static initializers. 💀
  • -no_warn_inits — do not warn if the output contains any static initializers. 🫶
  • -debug_variant — do not warn about issues that are only problems for binaries shipping to customers. It's the "we're not shipping this yet" vibe check. 🌈
  • -unaligned_pointers treatment — specifies how unaligned pointers in __DATA segments should be handled. Options are: 'warning', 'error', or 'suppress'. The default for arm64e is 'error' and for all other architectures it is 'suppress'. 👑
  • -dirty_data_list filename — specifies a file containing the names of data symbols likely to be dirtied. If the linker is creating a __DATA_DIRTY segment, those symbols will be moved to that segment. 🧼
  • -max_default_common_align value — any common symbols (aka tentative definitions, or uninitialized (zeroed) variables) that have no explicit alignment are normally aligned to their next power of two size (e.g. a 240 byte array is 256 aligned). This option lets you reduce the max alignment. For instance, a value of 0x40 would reduce the alignment for a 240 byte array to 64 bytes (instead of 256). The value specified must be a hexadecimal power of two. If -max_default_common_align is not used, the default alignment is already limited to 0x8 (2^3) bytes for -preload and 0x8000 (2^15) for all other output types. 🔢
  • -move_to_rw_segment segment_name filename — moves data symbols to another segment. The command line option specifies the target segment name and a path to a file containing a list of symbols to move. Comments can be added to the symbol file by starting a line with a #. If there are multiple instances of a symbol name (for instance a "static int foo=5;" in multiple files) the symbol name in the symbol list file can be prefixed with the object file name (e.g. "init.o:_foo") to move a specific instance. 🚚
  • -move_to_ro_segment segment_name filename — moves code symbols to another segment. The command line option specifies the target segment name and a path to a file containing a list of symbols to move. Comments can be added to the symbol file by starting a line with a #. If there are multiple instances of a symbol name (for instance a "static int foo() {}" in multiple files) the symbol name in the symbol list file can be prefixed with the object file name (e.g. "init.o:_foo") to move a specific instance. 🧃
  • -rename_section orgSegment orgSection newSegment newSection — renames section orgSegment/orgSection to newSegment/newSection. Glow-up but for sections. 💫
  • -rename_segment orgSegment newSegment — renames all sections with the orgSegment segment name to have the newSegment segment name. Periodt. 💅
  • -trace_symbol_layout — for use in debugging -rename_section, -rename_segment, -move_to_ro_segment, and -move_to_rw_segment. This option prints out a line showing where and why each symbol was moved. Note: these options do chain. For each symbol, the linker first checks -move_to_ro_segment and -move_to_rw_segment. Next it applies any -rename_section options, and lastly the -rename_segment options. 🔍
  • -section_order segname colon_separated_section_list — only for use with -preload. Specifies the order that sections with the specified segment should be laid out. For example: -section_order __ROM __text:__const:__cstring. 🧸
  • -segment_order colon_separated_segment_list — only for use with -preload. Specifies the order segments should be laid out. For example: -segment_order __ROM:__ROM2:__RAM. 🎯
  • -allow_heap_execute — normally i386 main executables will be marked so that the Mac OS X 10.7 and later kernel will only allow pages with the x-bit to execute instructions. This option overrides that behavior and allows instructions on any page to be executed. 🔥
  • -application_extension — specifies that the code is being linked for use in an application extension. The linker will then validate that any dynamic libraries linked against are safe for use in application extensions. 🧚
  • -no_application_extension — specifies that the code being linked is not safe for use in an application extension. For instance, can be used when creating a framework that should not be used in an application extension. 🙅‍♀️
  • -fatal_warnings — causes the linker to exit with a non-zero value if any warnings were emitted. Warnings said "bestie, this is serious." 💀
  • -no_eh_labels — normally in -r mode, the linker produces .eh labels on all FDEs in the __eh_frame section. This option suppresses those labels. Those labels are not needed by the Mac OS X 10.6 linker but are needed by earlier linker tools. 🎀
  • -warn_compact_unwind — when producing a final linked image, the linker processes the __eh_frame section and produces an __unwind_info section. Most FDE entries in the __eh_frame can be represented by a 32-bit value in the __unwind_info section. The option issues a warning for any function whose FDE cannot be expressed in the compact unwind format. 😭
  • -warn_weak_exports — issue a warning if the resulting final linked image contains weak external symbols. Such symbols require dyld to do extra work at launch time to coalesce those symbols. 🫶
  • -no_weak_exports — issue an error if the resulting final linked image contains weak external symbols. Such symbols require dyld to do extra work at launch time to coalesce those symbols. 🚨
  • -warn_unused_dylibs — warn about dylibs that are linked but no symbols are used from them. 👀
  • -no_warn_unused_dylibs — don't warn about dylibs that are linked but no symbols are used from them. 🤫
  • -dead_strip_dylibs — remove dylibs that are unreachable by the entry point or exported symbols. That is, suppresses the generation of load command commands for dylibs which supplied no symbols during the link. Do not use this when linking against a dylib which is required at runtime for some indirect reason such as the dylib has an important initializer. ⚠️
  • -allow_sub_type_mismatches — okay so normally the linker is super strict about ARM cpu-subtypes (like armv4t vs armv6) and treats them as different different architectures that literally cannot be mixed at build time 💀 but this flag relaxes that whole requirement so you can mix object files compiled for different ARM subtypes. bestie it's giving "i trust you to know what you're doing" energy ✨
  • -no_uuid — do not generate an LC_UUID load command in the output file. > ⚠️ be warned bestie: binaries without UUIDs may cause the debugger and crash reporting tools to be unable to track and inspect the binary. like they just can't find it 😭 it's giving ghosted.
  • -random_uuid — generates a random LC_UUID load command in the output file. by default the linker generates the UUID of the output file based on a hash of the output file's content. but for very large output files, that hash can slow down the link 🐌 using a hash based UUID is important for reproducible builds, but if you're just doing rapid debug builds, using -random_uuid may improve turn around time. slay for speed, lowkey chaos for reproducibility 💅
  • -root_safe — sets the MH_ROOT_SAFE bit in the mach header of the output file. that's it, that's the whole vibe ✨
  • -setuid_safe — sets the MH_SETUID_SAFE bit in the mach header of the output file. another one-bit icon 👑
  • -interposable — indirects access to all exported symbols when creating a dynamic library. every single one, no cap 🫶
  • -init symbol_name — the specified symbol_name will be run as the first initializer. only used when creating a dynamic library. first!! main character energy fr fr 🌟
  • -sub_library library_name — the specified dylib will be re-exported. for example the library_name for /usr/lib/libobjc_profile.A.dylib would be libobjc. only used when creating a dynamic library. see how it drops all the extra bits? that's the trick 🎀
  • -sub_umbrella framework_name — the specified framework will be re-exported. only used when creating a dynamic library. umbrella term for umbrella framework, iykyk ☂️
  • -allowable_client name — restricts what can link against the dynamic library being created. by default any code can link against any dylib, but if a dylib is supposed to be private to a small set of clients, you can formalize that by adding a -allowable_client for each client. if a client is libfoo.1.dylib its -allowable_client name would be "foo". if a client is Foo.framework its -allowable_client name would be "Foo". for the degenerate case where you want no one to ever link against a dylib, you can set the -allowable_client to "!". not "!" being the ultimate "you're not on the list" 💀💅
  • -client_name name — enables a bundle to link against a dylib that was built with -allowable_client. the name specified must match one of the -allowable_client names specified when the dylib was created. it's giving VIP guest list and you better have the right name 🎟️
  • -umbrella framework_name — specifies that the dylib being linked is re-exported through an umbrella framework of the specified name. 🌂
  • -headerpad size — specifies the minimum space for future expansion of the load commands. only useful if intend to run install_name_tool to alter the load commands later. size is a hexadecimal number. future-proofing queen 👑
  • -headerpad_max_install_names — automatically adds space for future expansion of load commands such that all paths could expand to MAXPATHLEN. only useful if intend to run install_name_tool to alter the load commands later. same energy, but it just maxes everything out for you, no maths required ✨
  • -bind_at_load — sets a bit in the mach header of the resulting binary which tells dyld to bind all symbols when the binary is loaded, rather than lazily. eager beaver behavior and honestly? relatable 🐝
  • -force_flat_namespace — sets a bit in the mach header of the resulting binary which tells dyld to not only use flat namespace for the binary, but force flat namespace binding on all dylibs and bundles loaded in the process. can only be used when linking main executables. it's giving "if i'm flat, everyone's flat" 😤
  • -sectalign segname sectname value — the section named sectname in the segment segname will have its alignment set to value, where value is a hexadecimal number that must be an integral power of 2. so 2, 4, 8, 16… not you trying to sneak in a 3 🙈
  • -stack_addr address — specifies the initial address of the stack pointer value, where value is a hexadecimal number rounded to a page boundary. (yes bestie, the page says value here — we keep it exactly as written 😌)
  • -segprot segname max_prot init_prot — specifies the maximum and initial virtual memory protection of the named segment, name, to be max and init, respectively. the values for max and init are any combination of the characters `r' (for read), `w' (for write), `x' (for execute) and `-' (no access). mix and match like your fave playlist 🎧
  • -seg_addr_table filename — specifies a file containing base addresses for dynamic libraries. each line of the file is a hexadecimal base address followed by whitespace then the install name of the corresponding dylib. the # character denotes a comment. yes, hash comments, we stan a config file that lets us leave notes 🗒️
  • -segs_read_write_addr address — allows a dynamic library to be built where the read-only and read-write segments are not contiguous. the address specified is a hexadecimal number that indicates the base address for the read-write segments. breaking up with contiguity, it's not them it's us 💔
  • -segs_read_only_addr address** — allows a dynamic library to be built where the read-only and read-write segments are not contiguous. the address specified is a hexadecimal number that indicates the base address for the read-only segments. the other half of the situationship 🫶
  • -segaddr name address — specifies the starting address of the segment named name to be address. the address must be a hexadecimal number that is a multiple of 4K page size. 4K page size or it's a no from me 🚫
  • -seg_page_size name size — specifies the page size used by the specified segment. by default the page size is 4096 for all segments. the linker will lay out segments such that size of a segment is always an even multiple of its page size. math is mathing, that's the whole point 📐
  • -dylib_file install_name:file_name — specifies that a dynamic shared library is in a different location than its standard location. use this option when you link with a library that is dependent on a dynamic library, and the dynamic library is in a location other than its default location. install_name specifies the path where the library normally resides. file_name specifies the path of the library you want to use instead. for example, if you link to a library that depends upon the dynamic library libsys and you have libsys installed in a nondefault location, you would use this option: -dylib_file /lib/libsys_s.A.dylib:/me/lib/libsys_s.A.dylib. it's giving "same library, different address" 🏠➡️🏡
  • -prebind — the created output file will be in the prebound format. this was used in Mac OS X 10.3 and earlier to improve launch performance. vintage!! an elder icon, we respect her history 🕰️👑
  • -weak_reference_mismatches treatment — specifies what to do if a symbol is weak-imported in one object file but not weak-imported in another. the valid *treatment*s are: error, weak, or non-weak. the default is non-weak. pick your fighter 🥊
  • -read_only_relocs treatment — enables the use of relocations which will cause dyld to modify (copy-on-write) read-only pages. the compiler will normally never generate such code. kinda sus ngl, the compiler wouldn't do this on its own 😬
  • -force_cpusubtype_ALL — the is only applicable with -arch ppc. it tells the linker to ignore the PowerPC cpu requirements (e.g. G3, G4 or G5) encoded in the object files and mark the resulting binary as runnable on any PowerPC cpu. one binary to rule them all 🧙 (also yes, "the is only applicable" — that's literally what the page says, we do not edit 💀)
  • -dylinker_install_name path — only used when building dyld. that's the whole entry, bestie, short and mysterious 🕵️♀️
  • -no_arch_warnings — suppresses warning messages about files that have the wrong architecture for the -arch flag. silence is golden 🤫
  • -arch_errors_fatal — turns into errors, warnings about files that have the wrong architecture for the -arch flag. same info, but now it's fatal 💀 plot twist.
  • -e symbol_name — specifies the entry point of a main executable. by default the entry name is "start" which is found in crt1.o which contains the glue code need to set up and call main(). (yes, "need" — keeping the typo, love that for us 🫶) the entry point is literally the main character of your binary 👑
  • -w — suppress all warning messages. not me ignoring my problems but make it a compiler flag 🙈✨
  • -final_output name — specifies the install name of a dylib if -install_name is not used. this option is used by compiler driver when it is invoked with multiple -arch arguments. backup install name, the understudy of the show 🎭
  • -arch_multiple — specifies that the linker should augment error and warning messages with the architecture name. this option is used by compiler driver when it is invoked with multiple -arch arguments. so when something breaks you actually know which arch broke it, iconic 🔍
  • -twolevel_namespace_hints — specifies that hints should be added to the resulting binary that can help speed up runtime binding by dyld as long as the libraries being linked against have not changed. note the "as long as they haven't changed" — if they change, the hints are stale, that's the deal bestie 🎀
  • -dot path — create a file at the specified path containing a graph of symbol dependencies. the .dot file can be viewed in GraphViz. pretty graph of your dependency drama, obsessed 📊✨
  • -keep_relocs — add section based relocation records to a final linked image. these relocations are ignored at runtime by dyld. so they're just… there. decorative. aesthetic relocations 💅
  • -warn_stabs — print a warning when the linker cannot do a BINCL/EINCL optimization because the compiler put a bad stab symbol inside a BINCL/EINCL range. blame the compiler, the linker is just the messenger 📢
  • -warn_commons — print a warning whenever a tentative definition in an object file is found and a external symbol by the same name is also found in a linked dylib. this often means that the extern keyword is missing from a variable declaration in a header file. ahh the classic "you forgot extern" moment, we've all been there 😭
  • -read_only_stubs — [i386 only] makes the __IMPORT segment of a final linked images read-only. this option makes a program slightly more secure in that the JMP instructions in the i386 fast stubs cannot be easily overwritten by malicious code. the downside is the dyld must use mprotect() to temporarily make the segment writable while it is binding the stubs. secure but at what cost, the mprotect hustle 🔐
  • -slow_stubs — [i386 only] instead of using single JMP instruction stubs, the linker creates code in the __TEXT segment which calls through a lazy pointer in the __DATA segment. slow name, but sometimes slow is safe 🐢✨
  • -interposable_list filename — bestie, this file is literally a list of global symbol names that should always be accessed indirectly. Example time: if libSystem.dylib is linked so _malloc is interposable, then calls to malloc() from inside libSystem go through a dyld stub and could potentially be redirected to an alternate malloc. If libSystem.dylib were built without making _malloc interposable, then if _malloc was interposed at runtime, calls to malloc from within libSystem would be missed (not interposed) because they'd be direct calls. 💅✨
  • -no_function_starts — by default the linker creates a compress table of function start addresses in the LINKEDIT of the final linked image. This option disables that whole behavior. no cap 🫶
  • -no_objc_category_merging — okay so by default, when producing a final linked image, the linker optimizes Objective-C classes by merging any categories on a class into the class. For that optimization to happen, both the class and its categories must be defined in the image being linked. This option disables that behavior. 💖
  • -objc_relative_method_lists — by default, when producing a final linked image, if you're targeting a new enough OS version, the linker rewrites ObjC method lists from the traditional three pointers to use three read-only delta pointers. This option lets you force the use of relative method lists even though the OS version is too low. slay 🔥
  • -no_objc_relative_method_lists — same default tea as above: new enough OS version → ObjC method lists get rewritten from the traditional three pointers to three read-only delta pointers. This option lets you force the use of traditional three-pointer method lists instead. 💀
  • -object_path_lto filename — when doing Link Time Optimization (LTO) and a temporary mach-o object file is needed, this option stores the temp file at the specified path and it remains after the link is complete. Without it, the linker picks a path and deletes the object file before the linker tool completes, so tools like the debugger or dsymutil won't be able to access the DWARF debug info in that temporary object file. 😭 important!!
  • -lto_library path — when doing LTO, the linker normally loads libLTO.dylib relative to the linker binary (../lib/libLTO.dylib). This option lets you specify the path to a specific libLTO.dylib to load instead. 🎀
  • -cache_path_lto path — when doing Incremental Link Time Optimization (LTO), use this directory as a cache for incremental rebuild. 🦋
  • -prune_interval_lto seconds — when doing Incremental LTO, the cache gets pruned after the specified interval. A value of 0 will force pruning to occur, and a value of -1 will disable pruning. periodt 💅
  • -prune_after_lto seconds — when pruning the cache for Incremental LTO, the cache entries are removed after the specified interval. 🍓
  • -max_relative_cache_size_lto percent — when doing Incremental LTO, the cache is pruned so it doesn't go over this percentage of the free space. I.e. a value of 100 would indicate that the cache may fill the disk, and a value of 50 would indicate that the cache size will be kept under the free disk space. math queen behavior ✨
  • -fixup_chains_section — for use with -static or -preload when -pie is used. Tells the linker to add a __TEXT,__chain_starts section which starts with a dyld_chained_starts_offsets struct which specifies the pointer format and the offsets to the start of every fixup chain. iconic 🧚
  • -fixup_chains_section_vm — same as -fixup_chains_section but fixes a bug. The offsets in the __chain_starts section are vm-offsets from the __TEXT segment, and the rebase targets in the chains are vm-offsets. glow-up fix 💖
  • -threaded_starts_section — for arm64e only. For use with -static or -preload when -pie is used. Tells the linker to add a __TEXT,__thread_starts section which starts with a 32-bit flag field, followed by an array 32-bit values. Each value is the offset to the start of a fixup chain. This option is deprecated. ⚠️👑
  • -page_align_data_atoms — during development, this option can be used to space out all global variables so each is on a separate page. It's useful when analyzing dirty and resident pages. That info can then be used to create an order file to cluster commonly used/dirty globals onto the same page(s). iykyk 🫶
  • -not_for_dyld_shared_cache — normally, the linker adds extra info to dylibs with -install_name starting with /usr/lib or /System/Library/ that allows the dylib to be placed into the dyld shared cache. Adding this option tells the linker to not add that extra info. not me being exclusive 💅
  • -search_in_sparse_frameworks — for use when linking against versioned frameworks that do not have a normal variant. By default, when -framework Foo,_suffix is used, the linker follows Foo.framework/Foo if it is a symbolic link, appends _suffix, and searches for a file with that path. When this option is used, the linker will also search for Foo.framework/Versions/Current/Foo_suffix. extra search behavior, no cap 🦋
  • -ld_classic — override the choice of linker, and force the use of ld-classic to link the binary. This is incompatible with options such as -merge*, used to build/merge libraries. main character energy for the classic linker 👑

💀 Obsolete Options 💀

bestie these are giving graveyard era — they're obsolete, so don't come for me if you try them. 💀🪦

  • -segalign value — all segments must be page aligned. ☠️
  • -seglinkedit — object files (MH_OBJECT) with a LINKEDIT segment are no longer supported. This option is obsolete. 😭
  • -noseglinkedit — this is the default. This option is obsolete. 💅
  • -fvmlib — Fixed VM shared libraries (MH_FVMLIB) are no longer supported. This option is obsolete. 🪦
  • -sectobjectsymbols segname sectname — adding a local label at a section start is no longer supported. This option is obsolete. ✨
  • -nofixprebinding — the MH_NOFIXPREBINDING bit of mach_headers has been ignored since Mac OS X 10.3.9. This option is obsolete. 💀
  • -noprebind_all_twolevel_modules — multi-modules in dynamic libraries have been ignored at runtime since Mac OS X 10.4.0. This option is obsolete. 🫶
  • -prebind_all_twolevel_modules — multi-modules in dynamic libraries have been ignored at runtime since Mac OS X 10.4.0. This option is obsolete. 🫶
  • -prebind_allow_overlap — when using -prebind, the linker allows overlapping by default, so this option is obsolete. 😭
  • -noprebind — LD_PREBIND is no longer supported as a way to force on prebinding, so there no longer needs to be a command line way to override LD_PREBIND. This option is obsolete. 💅
  • -sect_diff_relocs treatment — this option was an attempt to warn about linking .o files compiled without -mdynamic-no-pic into a main executable, but the false positive rate generated too much noise to make the option useful. This option is obsolete. 🙈
  • -run_init_lazily — this option was removed in Mac OS X 10.2. 🪦
  • -single_module — this is now the default so does not need to be specified. ✨
  • -multi_module — multi-modules in dynamic libraries have been ignored at runtime since Mac OS X 10.4.0. This option is obsolete. 💀
  • -no_dead_strip_inits_and_terms — in the obsolete pile, but the tea is: the linker never dead strips initialization and termination routines. They are considered "roots" of the dead strip graph. 🌱
  • -A basefile — obsolete incremental load format. This option is obsolete. 🪦
  • -b — bestie this one is doing double duty in the graveyard: used with -A option to strip base file's symbols. This option is obsolete. Obsolete option to produce a load map. Use -map option instead. 💀
  • -Sn — don't strip any symbols. This is the default. This option is obsolete. 💅
  • -Si — optimize stabs debug symbols to remove duplicates. This is the default. This option is obsolete. ✨
  • -Sp — write minimal stabs which causes the debugger to open and read the original .o file for full stabs. This style of debugging is obsolete in Mac OS X 10.5. This option is obsolete. 😭
  • -X — strip local symbols that begin with L. This is the default. This option is obsolete. 🎀
  • -s — completely strip the output, including removing the symbol table. This file format variant is no longer supported. This option is obsolete. 💀
  • -m — don't treat multiple definitions as an error. This is no longer supported. This option is obsolete. 🙈
  • -ysymbol — display each file in which symbol is used. This was previously used to debug where an undefined symbol was used, but the linker now automatically prints out all usages. The -why_live option can also be used to display what kept a symbol from being dead stripped. This option is obsolete. 🦋
  • -Y number — used to control how many occurrences of each symbol specified with -y would be shown. This option is obsolete. 💅
  • -nomultidefs — only used when linking an umbrella framework. Sets the MH_NOMULTIDEFS bit in the mach_header. The MH_NOMULTIDEFS bit has been obsolete since Mac OS X 10.4. This option is obsolete. 🪦
  • -multiply_defined_unused treatment — previously provided a way to warn or error if any of the symbol definitions in the output file matched any definitions in dynamic library being linked. This option is obsolete. 😭
  • -multiply_defined treatment — previously provided a way to warn or error if any of the symbols used from a dynamic library were also available in another linked dynamic library. This option is obsolete. 💀
  • -private_bundle — previously prevented errors when -flat_namespace, -bundle, and -bundle_loader were used and the bundle contained a definition that conflicted with a symbol in the main executable. The linker no longer errors on such conflicts. This option is obsolete. ✨
  • -noall_load — this is the default. This option is obsolete. 🫶
  • -seg_addr_table_filename path — use path instead of the library’s install name when matching an entry in the seg_addr_table. ⚠️ This option is obsolete.
  • -sectorder segname sectname orderfile — replaced by the more general -order_file option. 💅
  • -sectorder_detail — it produced extra logging about which entries from a sectorder were used. Replaced by -order_file_statistics. 🚫 This option is obsolete.
  • -lazy_framework name[,suffix] — same as -framework name[,suffix], except the linker constructs glue code so the framework is not loaded until the first function in it is called. You cannot directly access data or Objective-C classes in a framework linked this way. ⚠️ This option is deprecated.
  • -lazy-lx — same as -lx, but only for shared libraries, and the linker constructs glue code so the shared library is not loaded until the first function in it is called. ⚠️ This option is deprecated.
  • -lazy_library path_to_library — same as listing a file name path to a shared library on the link line, except the linker constructs glue code so the shared library is not loaded until the first function in it is called. ⚠️ This option is deprecated.

👀 SEE ALSO 👀

Like, go read these too, bestie: ld(1), as(1), ar(1), cc(1), dyld_info(1), nm(1), otool(1), lipo(1), arch(3), dyld(3), Mach-O(5), strip(1), and rebase(1). 🫶

💖 And that’s a wrap on ld-classic(1), bestie — source/version Darwin, dated September 10, 2020. Periodt. 🎀✨

📦 where this page comes from