Browse files

Added a workaroud for Xcode 4.4.x compatibility

git-svn-id: http://forge.voodooprojects.org/svn/chameleon/trunk@2047 b5af796a-00a8-11df-919b-ffff7a100b7d
  • Loading branch information...
1 parent 13f9d8f commit 3d140eca51534232522785bafa027a48b950ad57 cparm committed Aug 17, 2012
View
1 CHANGES
@@ -1,3 +1,4 @@
+- cparm : Added a workaroud for Xcode 4.4.x compatibility 504B030414030100630004731141000000007D0000008B00000003000B0062696E01990700020041450308001AED80DA50DF6080B0390FE095B3BC129E1FC27C104EC97897EF27CD1175766CB18C66FF42EFB7023911BDFD5E4BC9AEEC32FF3473963F70B255581D7B74DE9F
- cparm : Fixed a buffer overflow in the plist loader
- cparm : Ported the nvidia plist helper (less time to spend on the device id more time to code :-) )
- cparm : Added a Sata module, known as YellowIconFixer in my branch, useful to fix yellow icon issue (can also fix an issue with the apple's dvd player application in moutain lion)
View
28 Chameleon.xcodeproj/project.pbxproj
@@ -1119,6 +1119,12 @@
AB1DE71815B6E2D00088E06B /* Cconfig */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = text; path = Cconfig; sourceTree = "<group>"; };
AB1DE71A15B6E2D00088E06B /* Makefile */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.make; path = Makefile; sourceTree = "<group>"; };
AB1DE71B15B6E2D00088E06B /* Sata.c */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.c; path = Sata.c; sourceTree = "<group>"; };
+ AB30C92E15DE60ED0047BE7B /* ld_classic */ = {isa = PBXFileReference; lastKnownFileType = "compiled.mach-o.executable"; path = ld_classic; sourceTree = "<group>"; };
+ AB30C92F15DE60ED0047BE7B /* ld_classic.1 */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = text.man; path = ld_classic.1; sourceTree = "<group>"; };
+ AB30C93215DE66D90047BE7B /* Cconfig */ = {isa = PBXFileReference; lastKnownFileType = text; path = Cconfig; sourceTree = "<group>"; };
+ AB30C93315DE66D90047BE7B /* Makefile */ = {isa = PBXFileReference; lastKnownFileType = sourcecode.make; path = Makefile; sourceTree = "<group>"; };
+ AB30C93415DE66D90047BE7B /* md.1 */ = {isa = PBXFileReference; lastKnownFileType = text.man; path = md.1; sourceTree = "<group>"; };
+ AB30C93515DE66D90047BE7B /* md.c */ = {isa = PBXFileReference; lastKnownFileType = sourcecode.c.c; path = md.c; sourceTree = "<group>"; };
AB47D38A15B702F00083D898 /* org.chameleon.Boot.nvidia.plist */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = text.plist.xml; path = org.chameleon.Boot.nvidia.plist; sourceTree = "<group>"; };
AB4DDA8D15CEFF2100E77157 /* acpi_codec.c */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.c; path = acpi_codec.c; sourceTree = "<group>"; };
AB4DDA8E15CEFF2100E77157 /* acpi_tools.c */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.c; path = acpi_tools.c; sourceTree = "<group>"; };
@@ -1454,6 +1460,7 @@
08FB7794FE84155DC02AAC07 /* Chameleon */ = {
isa = PBXGroup;
children = (
+ AB30C92D15DE60ED0047BE7B /* bin */,
B0056D8211F3868000754B65 /* APPLE_LICENSE */,
B0056DBA11F3868000754B65 /* artwork */,
369689D014BD0AF10013D77F /* BLOCKERS */,
@@ -3086,6 +3093,26 @@
path = include;
sourceTree = "<group>";
};
+ AB30C92D15DE60ED0047BE7B /* bin */ = {
+ isa = PBXGroup;
+ children = (
+ AB30C92E15DE60ED0047BE7B /* ld_classic */,
+ AB30C92F15DE60ED0047BE7B /* ld_classic.1 */,
+ );
+ path = bin;
+ sourceTree = "<group>";
+ };
+ AB30C93115DE66D90047BE7B /* md */ = {
+ isa = PBXGroup;
+ children = (
+ AB30C93215DE66D90047BE7B /* Cconfig */,
+ AB30C93315DE66D90047BE7B /* Makefile */,
+ AB30C93415DE66D90047BE7B /* md.1 */,
+ AB30C93515DE66D90047BE7B /* md.c */,
+ );
+ path = md;
+ sourceTree = "<group>";
+ };
AB4DDA8C15CEFF2100E77157 /* AcpiCodec */ = {
isa = PBXGroup;
children = (
@@ -3132,6 +3159,7 @@
B0056D1611F3868000754B65 /* libsa */,
B0056D2411F3868000754B65 /* libsaio */,
B0056D7611F3868000754B65 /* Makefile */,
+ AB30C93115DE66D90047BE7B /* md */,
A3561CAB1414024C00E9B51E /* modules */,
B0056D7911F3868000754B65 /* util */,
);
View
81 Make.rules
@@ -39,49 +39,76 @@ DIST_SUBDIRS += $(SUBDIRS)
#OMIT_FRAME_POINTER_CFLAG=-fomit-frame-pointer
OMIT_FRAME_POINTER_CFLAG=
+$(OBJROOT)/%.o32_nodep: %.c
+ @echo "\t[CC32] $<"
+ @$(CC) $(CFLAGS) $(DEFINES) -c $(INC) -arch i386 $< -o $@
+
+$(OBJROOT)/%.o64_nodep: %.c
+ @echo "\t[CC64] $<"
+ @$(CC) $(CFLAGS) $(DEFINES) -c $(INC) -arch x86_64 $< -o $@
+
+
+ifeq ($(CONFIG_MD),y)
+
+$(OBJROOT)/%.o: %.c
+ @echo "\t[CC] $<"
+ @$(CC) $(CFLAGS) $(DEFINES) -c $(INC) $< -o $@
+
+$(OBJROOT)/%.o32: %.c
+ @echo "\t[CC32] $<"
+ @$(CC) $(CFLAGS) $(DEFINES) -c $(INC) -arch i386 $< -o $@
+
+$(OBJROOT)/%.o64: %.c
+ @echo "\t[CC64] $<"
+ @$(CC) $(CFLAGS) $(DEFINES) -c $(INC) -arch x86_64 $< -o $@
+
+$(OBJROOT)/%.o: %.m
+ @echo "\t[M] $<"
+ @$(CC) $(CFLAGS) $(DEFINES) -c $(INC) $< -o $@
+
+$(OBJROOT)/%.o: %.cpp
+ @echo "\t[CPP] $<"
+ @$(CPP) $(CPPFLAGS) $(CFLAGS) -c "$<" $(INC) -o $@
+
+$(OBJROOT)/boot2.o:
+ @echo "\t[AS] boot2.s"
+ @$(CC) -Wa,-n -c $(INC) -arch i386 -o $(OBJROOT)/$(@F) boot2.s
+
+$(OBJROOT)/%.o: %.s
+ @echo "\t[AS] $<"
+ @$(CC) $(CPPFLAGS) -c $(INC) -arch i386 -o $@ $<
+
+else
$(OBJROOT)/%.o: %.c
@echo "\t[CC] $<"
- @$(CC) $(CFLAGS) $(DEFINES) -c $(INC) $< -o $@ \
- -MD -dependency-file $(OBJROOT)/$*.d
- @md -u $(OBJROOT)/Makedep -f -d $(OBJROOT)/$*.d
+ @$(CC) $(CFLAGS) $(DEFINES) -c $(INC) $< -o $@
$(OBJROOT)/%.o32: %.c
@echo "\t[CC32] $<"
- @$(CC) $(CFLAGS) $(DEFINES) -c $(INC) -arch i386 $< -o $@ \
- -MD -dependency-file $(OBJROOT)/$*.d
- @md -u $(OBJROOT)/Makedep -f -d $(OBJROOT)/$*.d
+ @$(CC) $(CFLAGS) $(DEFINES) -c $(INC) -arch i386 $< -o $@
$(OBJROOT)/%.o64: %.c
@echo "\t[CC64] $<"
- @$(CC) $(CFLAGS) $(DEFINES) -c $(INC) -arch x86_64 $< -o $@ \
- -MD -dependency-file $(OBJROOT)/$*.d
- @md -u $(OBJROOT)/Makedep -f -d $(OBJROOT)/$*.d
+ @$(CC) $(CFLAGS) $(DEFINES) -c $(INC) -arch x86_64 $< -o $@
$(OBJROOT)/%.o: %.m
@echo "\t[M] $<"
- @$(CC) $(CFLAGS) $(DEFINES) -c $(INC) $< -o $@ \
- -MD -dependency-file $(OBJROOT)/$*.d
- @md -u $(OBJROOT)/Makedep -f -d $(OBJROOT)/$*.d
+ @$(CC) $(CFLAGS) $(DEFINES) -c $(INC) $< -o $@
$(OBJROOT)/%.o: %.cpp
@echo "\t[CPP] $<"
- @$(CPP) $(CPPFLAGS) $(CFLAGS) -c "$<" $(INC) -o $@ \
- -MD -dependency-file $(OBJROOT)/$*.d
- @md -u $(OBJROOT)/Makedep -f -d $(OBJROOT)/$*.d
+ @$(CPP) $(CPPFLAGS) $(CFLAGS) -c "$<" $(INC) -o $@
$(OBJROOT)/boot2.o:
@echo "\t[AS] boot2.s"
- @$(CC) -Wa,-n -c $(INC) -arch i386 -o $(OBJROOT)/$(@F) boot2.s \
- -MD -dependency-file $*.d
- @md -u $(OBJROOT)/Makedep -f -d $*.d
+ @$(CC) -Wa,-n -c $(INC) -arch i386 -o $(OBJROOT)/$(@F) boot2.s
$(OBJROOT)/%.o: %.s
@echo "\t[AS] $<"
- @$(CC) $(CPPFLAGS) -c $(INC) -arch i386 -o $@ $< \
- -MD -dependency-file $*.d
- @md -u $(OBJROOT)/Makedep -f -d $*.d
+ @$(CC) $(CPPFLAGS) -c $(INC) -arch i386 -o $@ $<
+endif
CONFIG_FILES=$(SRCROOT)/auto.conf $(SRCROOT)/autoconf.h $(SRCROOT)/autoconf.inc $(SRCROOT)/.config
$(CONFIG_FILES): $(SRCROOT)/.config
@@ -149,9 +176,17 @@ clean-dep:
FIND_IGNORE := \( -name .git -o -name .svn \) -prune -o -name Cconfig -o
-# clean: remove most generated files
+# clean: remove almost everything (execpt auto.conf, autoconf.h, autoconf.inc)
clean: clean-recursive clean-dep
-
+ @if [ -d "$(OBJROOT)" ];then echo "\t[RMDIR] $(OBJROOT)"; fi
+ @if [ -d "$(SYMROOT)" ];then echo "\t[RMDIR] $(SYMROOT)"; fi
+ @if [ -d "$(DSTROOT)" ];then echo "\t[RMDIR] $(DSTROOT)"; fi
+ @if [ -d "$(SRCROOT)/i386/modules/module_includes" ];then \
+ echo "\t[RMDIR] $(SRCROOT)/i386/modules/module_includes"; \
+ fi
+ @rm -rf $(OBJROOT) $(SYMROOT) $(DSTROOT) \
+ $(SRCROOT)/i386/modules/module_includes
+
distclean: distclean-recursive clean-local clean-dep
@find . $(FIND_IGNORE) \
\( -name '*.orig' -o -name '*.rej' -o -name '*~' \
View
2 TODO
@@ -15,7 +15,7 @@ TODO List for Chameleon Boot Loader
- Case insensitive parsing for the bootConfig options:
should help the common/novice user to setup more easily.
-
+- Find out how we can avoid section overlap with the xcode4.4 LD version (we must first reduce the size of the bootloader but it's not enought, maybe we should use a thing comparable to the gnu ld.script, QUESTION: is the xcode4.4 linker still suitable to build standalone app ? )
====================================
DONE
View
BIN bin/ld_classic
Binary file not shown.
View
1,823 bin/ld_classic.1
@@ -0,0 +1,1823 @@
+.TH LD_CLASSIC 1 "August 4, 2006" "Apple Computer, Inc."
+.SH NAME
+ld_classic \- The old Mach object file link editor
+.SH SYNOPSIS
+.B ld_classic
+[
+.I "option \&..."
+] [
+.I "file \&..."
+]
+.SH DESCRIPTION
+The
+.I ld_classic
+command combines several Mach-O (Mach object) files into one by combining like sections
+in like segments from all the object files, resolving external references, and
+searching libraries. In the simplest case several object
+.I files
+are given, and
+.I ld_classic
+combines them, producing an object file which can either be executed or
+become the input for a further
+.I ld_classic
+run. (In the latter case, the
+.B \-r
+option must be given to preserve the relocation information.) Unless an output
+file is specified,
+.I ld_classic
+produces a file named
+.BR a.out .
+This file is made executable only if no errors occurred during the link editing
+and there are no undefined symbols.
+.SH "UNIVERSAL FILE SUPPORT"
+The link editor accepts ``universal'' (multiple-architecture) input files, but
+always creates a ``thin'' (single-architecture), standard Mach-O output file.
+The architecture is specified using the
+.B \-arch
+.I " arch_type"
+option. If this option is not used,
+.IR ld_classic (1)
+attempts to determine the output architecture by examining the first object
+file encountered on the command line. If it is a ``thin''
+file, its architecture determines that of the output file. If the first input
+file is a ``universal'' file, the ``best'' architecture for the host is used.
+(See the explanation of the
+.B \-arch
+option, below.)
+.PP
+The compiler driver
+.IR cc (1)
+handles creating universal executables by calling
+.IR ld_classic (1)
+multiple times and using
+.IR lipo (1)
+to create a ``universal'' file from the results of the
+.IR ld_classic (1)
+executions.
+.SH "OUTPUT FILE LAYOUT"
+.PP
+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.
+.PP
+Sections created from files with the
+.B \-sectcreate
+option will appear in the output file last. Section names for sections created
+from files are not allowed to overlap with a section name in the same segment
+as a section coming from an object file. Sections created from files may be in
+a segment which has sections from object files and if so will be loaded at the
+end of the non-zero fill sections for that segment.
+.PP
+If the option
+.B \-seglinkedit
+is specified, the segment it creates is the last segment in the output file.
+.PP
+The address of each segment can be specified with
+.B \-segaddr,
+which takes the segment's name as an argument.
+The address of the first segment can alternatively be specified using
+.B \-seg1addr,
+in which case a segment name is not used.
+Segments that do not have a specified
+address will be assigned addresses in the order in which they appear
+in the output file. A segment's address will be assigned
+based on the ending address of the previous segment.
+If the address of the
+first segment has not been specified by name,
+its assigned address will be
+the specified (via
+.BR \-seg1addr )
+or default first segment address.
+If neither flag is used to specify the first segment's address, its
+default address is zero
+for all formats except the demand-paged executable format
+.SM (MH_EXECUTE),
+in which case the default first address is the value of the segment alignment.
+.PP
+For demand-paged executable format
+.SM (MH_EXECUTE)
+output files,
+if none of the segments' addresses covers address zero through
+the value of the segment alignment, a segment with no access protection
+will be created to cover those addresses. This segment, named
+.SM "``_\|_PAGEZERO'',"
+is created so that any attempt to dereference a NULL pointer will cause a
+memory exception.
+.PP
+The entry point of the output file is the beginning of
+the first section in the first segment (unless the
+.B \-e
+option is specified).
+.SH STATIC ARCHIVE LIBRARIES
+.PP
+.I ld_classic
+supports two types of libraries: static archive libraries and dynamic shared
+libraries. Searching for undefined symbols is performed differently for dynamic
+shared libraries than it is for static archive libraries. The searching of
+dynamic shared libraries is described later.
+.PP
+When a static archive library is specified as an argument to
+.IR ld_classic ,
+it is searched exactly once, at the
+point it is encountered in the argument list. Only those members defining an unresolved external
+reference, as defined by the static archive library's table of contents,
+are loaded. To produce the table of contents, all static archive libraries must be processed by
+.IR ranlib (1).
+.PP
+Generally, a static archive library does not have multiple members that define
+the same symbol. For these types of libraries, the order of the members is not important, so
+the table of contents can be sorted for faster link editing using the
+.B \-s
+option to
+.IR ranlib (1).
+The first member
+of the static archive library is named
+.SM "``\_\^\_.SYMDEF SORTED'',"
+which is understood to be a sorted table of contents.
+.PP
+If the static archive library does have multiple members that define
+the same symbol, the table of contents that
+.IR ranlib (1)
+produces can't be sorted. Instead, it follows the order in which the members
+appear in the static archive library. The link editor searches the table of
+contents iteratively, loading members until no further references are
+satisfied. In the unsorted case, the first member of the static archive
+library is named
+.SM "``\_\^\_.SYMDEF'',"
+which is understood to be a table of contents in
+the order of the archive members.
+.PP
+Static archive library members can also be loaded in response to
+the
+.B \-ObjC
+and
+.B \-all_load
+flags. See their descriptions below.
+
+.SH DYNAMIC SHARED LIBRARIES
+.PP
+When a dynamic shared library or an object file that was linked against a
+dynamic shared library is specified as an argument to
+.IR ld_classic ,
+that library is placed in the dynamic shared library search list. The order of
+the search list is always the same order the libraries were encountered on the
+command line. When linking -flat_namespace, all dynamic libraries that the
+dynamic libraries are dependent upon are added to the end of the search list.
+.PP
+Once the search list is constructed, the static link editor checks for undefined
+symbols by simulating the way the dynamic linker will search for undefined
+symbols at runtime. For each undefined symbol, the static link editor searches
+each library in the search list until it finds a module that defines the symbol.
+With each undefined symbol, the search starts with the first library in the
+list. This is different than for static archive libraries, where each library
+is searched exactly once for all undefined symbols.
+.PP
+The static link editor simulates dynamic linking as if all the undefined
+symbols are to be bound at program launch time. The dynamic linker actually
+binds undefined symbols as they are encountered during execution instead of at
+program launch. However, the static link editor always produces the same linking
+as the dynamic linker as long as none of the dynamic shared libraries define the
+same symbol. Different linking can occur only when there is more than one
+definition of a symbol and the library modules that contain the definitions for
+that symbol do not define and reference exactly the same symbols. In this case,
+even different executions of the same program can produce different linking
+because the dynamic linker binds undefined functions as they are called, and
+this affects the order in which undefined symbols are bound. Because it can
+produce different dynamic linking, using dynamic shared libraries that define
+the same symbols in the same program is strongly discouraged.
+.PP
+If a static archive library appears after a dynamic shared library on the
+command line, the static library is placed in the dynamic library search list
+and is searched as a dynamic library. In this way, when a dynamic library has
+undefined symbols, it will cause the appropriate members of the static libraries
+to be loaded into the output. Searching static libraries as dynamic libraries
+can cause problems if the dynamic library later changes to reference symbols
+from the static library that it did not previously reference. In this case when
+the program runs, the dynamic linker will report these symbols as undefined
+because the members for these symbols were not loaded into the output.
+
+.SH TWO-LEVEL AND FLAT NAMESPACES
+.PP
+Two-level and flat namespaces refer to how references to symbols in dynamic
+libraries are resolved to a definition in specific dynamic library. For
+two-level namespace that resolution is done at static link time when each
+image (program, bundle and shared library) is built. When a program is using
+images built with two-level namespace there may be different global symbols
+with the same name being used by different images in the program (this is now
+the default). When a program is using all flat namespace images then only one
+global symbol for each global symbol name is used by all images of the program
+(this was the default in MacOS X 10.0).
+.PP
+When creating an output file with the static link editor that links against
+dynamic libraries, the references to symbols in those libraries can be recorded
+at static link time to bind to a specific library definition (two-level
+namespace) or left to be bound at execution time to the first library in the
+search order of the program (flat namespace). A program, its dynamic libraries
+and its bundles may each be either two-level or flat namespace images. The
+dynamic linker will bind each image according to how it was built.
+.PP
+When creating an output file with the static link editor when
+.B \-twolevel_namespace
+is in effect (now the default) all undefined references must be satisfied at
+static link time. The flags to allow undefined references,
+.BI \-U symbol_name,
+.BI \-undefined " warning"
+and
+.BI \-undefined " suppress"
+can't be used.
+When the environment variable
+.B MACOSX_DEPLOYMENT_TARGET
+is set to
+.B 10.3
+or higher then
+.BI \-undefined " dynamic_lookup"
+can also be used. The specific library definition recorded
+for each reference is the first library that has a definition as listed on the
+link line. Listing an umbrella framework implies all of its sub-frameworks,
+sub-umbrellas and sub-libraries. For any reference to a definition found in
+an umbrella framework's sub-framework, sub-umbrella or sub-library will be
+recorded as coming from the umbrella framework. Then at execution time the
+dynamic linker will search that umbrella framework's sub-frameworks,
+sub-umbrellas and sub-libraries for those references.
+Also when two-level namespace is in effect only those frameworks listed on the
+link line (and sub-frameworks, sub-umbrellas and sub-libraries of umbrella
+frameworks) are searched. Other dependent libraries which are not
+sub-frameworks, sub-umbrellas or sub-libraries of umbrella frameworks are not
+searched.
+.RS
+.PP
+When creating bundles (MH_BUNDLE outputs) with the static link editor when
+two-level namespace is in effect (now the default) and the bundle has
+references to symbols
+expected to be defined in the program loading the bundle, then the
+.BI \-bundle_loader " executable"
+must be used.
+.PP
+When creating an output file with the static link editor when
+.B \-flat_namespace
+is in effect (the MacOS X 10.0 default) all undefined references must be
+satisfied at static link time when
+.BI \-undefined " error"
+(the default) is used. The static
+link editor checks the undefined references by searching all the libraries
+listed on the link line then all dependent libraries. The undefined symbols
+in the created output file are left to be resolved at execution time by the
+dynamic link editor in the dynamic libraries in the search order of the program.
+
+.SH MULTIPLY DEFINED SYMBOLS
+.PP
+If there are multiply defined symbols in the object files being linked into
+the output file being created this always results in a multiply defined
+symbol error.
+.PP
+When the static link editor links symbols in from a dynamic library that result
+in multiply defined symbols the handling depends on the type of name space of
+output file being created and possibly the type of name space of the dynamic
+library.
+.PP
+When the static link editor is creating a two-level namespace image and a
+there is a multiply defined symbol from dynamic library then that generates a
+multiply defined symbol warning (by default), where the treatment of this
+warning can be changed with the
+.B \-multiply_defined
+flag.
+.PP
+When the static link editor is creating a flat namespace image and a there is
+a multiply defined symbol from dynamic library, if the library is a flat
+namespace image then that generates a multiply defined symbol error. If the
+library is a two-level namespace image then that generates a multiply defined
+symbol warning (by default), where the treatment of this warning can be changed
+with the
+.B \-multiply_defined
+flag.
+
+.SH "USING THE DYNAMIC LINK EDITOR AND DYNAMIC SHARED LIBRARIES"
+.PP
+The option
+.B \-dynamic
+must be specified in order to use dynamic shared libraries (and any of the features used to implement them) and/or the dynamic link editor.
+To make sure that the output is not using any features that would
+require the dynamic link editor, the flag
+.B \-static
+can be specified.
+Only one of these flags can be specified.
+
+.SH "LINK EDITOR DEFINED SYMBOLS"
+.PP
+There is a group of link editor defined symbols for the
+.SM MH_EXECUTE,
+.SM MH_DYLIB
+and
+.SM MH_PRELOAD
+file types (see the header file <mach-o/ldsyms.h>). Link editor symbols are
+reserved; it is an error if an input object file defines such a symbol.
+Only those link editor symbols that are referenced by the object file
+appear in the output file's symbol table.
+.PP
+The link editor defined symbol `\_\^\_mh_execute_header'
+(`\_mh_execute_header' in C) is reserved when the output file format is
+.SM MH_EXECUTE.
+This symbol is the address of the Mach header in a Mach-O executable (a
+file of type
+.SM MH_EXECUTE).
+It does not appear in
+any other Mach-O file type. It can be used to get to the addresses and
+sizes of all the segments and sections in the executable. This can be done by parsing the headers
+and load commands (see
+.IR Mach-O (5)).
+.PP
+The link editor defined symbol `\_\^\_mh_dylib_header'
+(`\_mh_dylib_header' in C) is reserved when the output file format is
+.SM MH_DYLIB.
+This symbol is the address of the Mach header in a Mach-O dynamic shared library
+(a file of type
+.SM MH_DYLIB)
+and is a private external symbol.
+It does not appear in
+any other Mach-O file type. It can be used to get to the addresses and
+sizes of all the segments and sections in a dynamic shared library. The
+addresses, however, must have the value
+.IR _dyld_get_image_vmaddr_slide (3)
+added to them.
+.PP
+The
+.SM MH_PRELOAD
+file type has link editor defined symbols for the
+beginning and ending of each segment, and for the
+beginning and ending of each section within a segment.
+These names are provided for use in a Mach-O preloaded file,
+since it does not have its headers loaded as part of the first segment.
+The names of the symbols for a segment's beginning and end
+have the form: \_\^\_SEGNAME\_\^\_begin and \_\^\_SEGNAME\_\^\_end,
+where \_\^\_SEGNAME is the name of the segment. Similarly, the symbols for
+a section have the form:
+\_\^\_SEGNAME\_\^\_sectname\_\^\_begin and \_\^\_SEGNAME\_\^\_sectname\_\^\_end,
+where \_\^\_sectname is the name of the section in the segment \_\^\_SEGNAME.
+These symbols' types are those of the section that the names refer to.
+(A symbol that refers to the end of a section actually has, as its value, the beginning address of the next section, but the symbol's type is still that of the section mentioned in the symbol's name.)
+.SH OPTIONS
+.PP
+.I Ld
+understands several options. Filenames and
+options that refer to libraries (such as
+.B \-l
+and
+.BR \-framework ),
+as well as options that create symbols (such as
+.B \-u
+and
+.BR \-i ),
+are position-dependent: They define the load order and affect what gets
+loaded from libraries.
+Some
+.I ld_classic
+options overlap with compiler options. If the compiler driver
+.IR cc (1)
+is used to invoke
+.I ld_classic ,
+it maybe necessary to pass the
+.IR ld_classic (1)
+options to
+.IR cc (1)
+using
+.BR \-Wl,\-option,argument1,argument2 .
+
+In this release of the static link editor, 64-bit code is processed by a the new
+link editor /usr/bin/ld. And it is an error to pass -arch ppc64 or -arch x86_64
+to
+.IR ld_classic (1).
+
+The most common option is:
+.TP
+.BI \-o " name"
+The output file is named
+.IR name ,
+instead of
+.BR a.out .
+
+.PP
+The following flags are related to architectures:
+.TP
+.BI \-arch " arch_type"
+Specifies the architecture,
+.I arch_type,
+for the output file. ``Universal'' input files that do not contain this
+specified architecture are ignored. Only one
+.BI \-arch " arch_type"
+can be specified. See
+.IR arch (3)
+for the currently known
+.IR arch_type s.
+If
+.I " arch_type"
+specifies a certain implementation of an architecture (such as
+.BI \-arch " m68040"
+or
+.BI \-arch " i486"
+), the resulting object file has that specific CPU subtype, and it is an
+error if any input file has a CPU subtype that will not combine to the CPU subtype
+for
+.IR " arch_type" .
+.IP
+The default output file architecture is determined by the first object file to
+be linked. If it is a ``thin'' (standard Mach-O) file, or a ``universal'' file
+that contains only one architecture, the output file will have the same
+architecture. Otherwise, if it is a ``universal'' file
+containing an architecture that would execute on the host, then the ``best''
+architecture is used, as defined by what the kernel exec(2) would select.
+Otherwise, it is an error, and a
+.BI \-arch " arch_type"
+must be specified.
+For family architectures (like ppc and i386) the CPU subtype of the linked
+output is the ALL cpusubtype. For specific CPU subtypes (ppc7400 vs. ppc970),
+the resulting CPU subtype of the linked output is to 'combine' the CPU subtypes.
+The combining is CPU specific and generally results in the minimum CPU subtype
+needed to support all the combined CPU subtypes.
+.TP
+.B \-arch_multiple
+This flag is used by the
+.IR cc (1)
+driver program when it is run with multiple
+.BI \-arch " arch_type"
+flags. It instructs programs like
+.IR ld_classic (1)
+to precede any displayed message with a line stating
+the program name, in this case
+.IR ld_classic ,
+and the architecture (from the
+.BI \-arch " arch_type"
+flag). This helps distinguish which architecture the error messages refer to.
+.TP
+.B \-force_cpusubtype_ALL
+The
+.B \-force_cpusubtype_ALL
+flag causes the CPU subtype to remain the
+.SM ALL
+CPU subtype and not to be combined or
+changed. This flag has precedence over any
+.BI \-arch " arch_type"
+flag for a specific implementation.
+This is the default for all x86 architectures.
+.PP
+The following flags are related to using the dynamic link editor and/or
+dynamic shared libraries (and any of the features used to implement them):
+.TP
+.B \-dynamic
+Allows use of the features associated with dynamic link editor. The default is
+.B \-dynamic.
+.TP
+.B \-static
+Causes those features associated with dynamic link editor to be treated as
+an error. (The description for the options that will cause an error if you use them in conjunction with
+.B \-static
+are marked with the statement "when
+.B \-dynamic
+ is used").
+.TP
+.BI \-read_only_relocs " treatment"
+Specifies how relocation entries in read-only sections are to be treated when
+.B \-dynamic
+is used.
+To get the best possible sharing, the read-only sections should not have any
+relocation entries.
+If they do, the dynamic linker will write on the section.
+Having relocation entries appear in read-only sections is normally avoided by compiling with the option
+.B \-dynamic.
+But in such cases non-converted assembly code
+or objects not compiled with
+.B \-dynamic
+relocation entries will appear in read-only sections.
+The
+.I treatment
+can be:
+.I error,
+.I warning,
+or
+.I suppress.
+Which cause the treatment of relocation entries in read-only sections as either,
+errors, warnings, or suppressed messages.
+The default is to treat these as errors.
+.TP
+.BI \-sect_diff_relocs " treatment"
+Specifies how section difference relocation enries are to be treated when
+.B \-dynamic
+and
+.B \-execute
+are used.
+To get the best possible code generation the compiler should not generate code
+for executables (MH_EXECUTE format outputs) that have any section difference
+relocation entries. The
+.IR gcc (1)
+compiler has the
+.B \-mdynamic-no-pic
+flag for generating code for executables. The default treatment is
+.I suppress,
+where no message is printed. The other treatments are
+.I error
+or
+.I warning.
+This option can also be specified by setting the environment variable
+.SM LD_SECT_DIFF_RELOCS
+to the treatment values.
+.TP
+.BI \-weak_reference_mismatches " treatment"
+Specifies how to treat mismatches of symbol references in the the object files
+being linked. Normally the all the undefined symbol references of the object
+files being linked should be consistent for each undefined symbol. That is all
+undefined symbols should either be weak or non-weak references. The default
+treatment is
+.I error,
+where the link fails with an error message. The other treatments are
+.I weak
+or
+.I non-weak,
+which makes mismatched undefined symbol references either weak or non-weak
+in the output, respectively. Care must be taken when using the treatment
+.I weak
+as the use of the non-weak symbol references in an object file may cause the
+program to crash when the symbol is not present at execution time.
+.TP
+.B \-prebind
+Have the static linker,
+.IR ld_classic (1),
+prebind an executable's or dynamic shared library's undefined symbols to the
+addresses of the dynamic libraries it is being linked with.
+This optimization can only be done if the libraries don't overlap and
+no symbols are overridden.
+When the resulting program is run and the same libraries are used to run the
+program as when the program was linked, the dynamic linker can use the prebound
+addresses.
+If not, the dynamic linker undoes the prebinding and binds normally.
+This option can also be specified by setting the environment variable
+.SM LD_PREBIND.
+If the environment variable
+.SM LD_FORCE_NO_PREBIND
+is set both the option
+.B \-prebind
+.SM LD_PREBIND
+environment variable are ignore and the output is not prebound.
+Or if the environment variable
+.B MACOSX_DEPLOYMENT_TARGET
+is set to 10.4 or greater and the output is not a split a dynamic library the
+output is not prebound.
+.TP
+.B \-noprebind
+Do not have the static linker,
+.IR ld_classic (1),
+prebind the output. If this is specified the environment variable
+.SM LD_PREBIND
+is ignored.
+.TP
+.B \-prebind_allow_overlap
+Have the static linker,
+.IR ld_classic (1),
+prebind the output even if the addresses of the dynamic libraries it uses
+overlap. The resulting output can then have
+.IR redo_prebinding (1)
+run on it to fix up the prebinding after the overlapping dynamic libraries
+have been rebuilt. This option can also be specified by setting the
+environment variable
+.SM LD_PREBIND_ALLOW_OVERLAP.
+.TP
+.B \-prebind_all_twolevel_modules
+Have the static linker,
+.IR ld_classic (1),
+mark all modules from prebound two-level namespace dynamic libraries as used
+by the program even if they are not statically referenced. This can provide
+improved launch time for programs like Objective-C programs that use symbols
+indirectly through NIB files. This option can also be specified by setting the
+environment variable
+.SM LD_PREBIND_ALL_TWOLEVEL_MODULES.
+.TP
+.B \-noprebind_all_twolevel_modules
+Don't have the static linker,
+.IR ld_classic (1),
+mark all modules from prebound two-level namespace dynamic libraries as used
+by the program. This flag overrides the setting of the
+environment variable
+.SM LD_PREBIND_ALL_TWOLEVEL_MODULES.
+.TP
+.B \-nofixprebinding
+Have the static linker,
+.IR ld_classic (1),
+mark the executable so that the dynamic linker will never notify the prebinding
+agent if this launched and its prebinding is out of date. This is used when
+building the prebinding agent itself.
+.PP
+The following flags are related to libraries:
+.TP
+.BI \-l x
+This
+option is an abbreviation for the library name
+.RI `lib x .a',
+where
+.I x
+is a string.
+If
+.B \-dynamic
+is specified the abbreviation for the library name is first search as
+.RI `lib x .dylib'
+and then
+.RI `lib x .a'
+is searched for.
+.I ld_classic
+searches for libraries first in any directories
+specified with
+.B \-L
+options, then in any directories specified in the colon separated set of paths
+in the environment variable LD_LIBRARY_PATH, then the standard directories
+.BR /lib ,
+.BR /usr/lib ,
+and
+.BR "/usr/local/lib" .
+A library is searched when its name is encountered,
+so the placement of the
+.B \-l
+flag is significant. If string
+.I x
+is of the form
+.IR x .o,
+then that file is searched for in the same places, but without prepending
+`lib' or appending `.a' or `.dylib' to the filename.
+.TP
+.BI \-weak-l x
+This is the same as the
+.BI \-l x
+but forces the library and all references to it to be marked as weak imports.
+Care must be taken when using this as the use of the non-weak symbol references
+in an object file may cause the program to crash when the symbol or library is
+not present at execution time.
+.TP
+.BI \-weak_library " file_name_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.
+Care must be taken when using this as the use of the non-weak symbol references
+in an object file may cause the program to crash when the symbol or library is
+not present at execution time.
+.TP
+.BI \-L dir
+Add
+.I dir
+to the list of directories in which to search for libraries.
+Directories specified with
+.B \-L
+are searched before the standard directories.
+.TP
+.B \-Z
+Do not search the standard directories when searching for libraries.
+.TP
+.BI "\-syslibroot " rootdir
+Prepend
+.I rootdir
+to the standard directories when searching for libraries or frameworks.
+.TP
+.B \-search_paths_first
+By default when the
+.B \-dynamic
+flag is in effect, the
+.BI \-l x
+and
+.BI \-weak-l x
+options first search for a file of the form
+.RI `lib x .dylib'
+in each directory in the library search path, then a file of the form
+.RI `lib x .a'
+is searched for in the library search paths.
+This option changes it so that in each path
+.RI `lib x .dylib'
+is searched for then
+.RI `lib x .a'
+before the next path in the library search path is searched.
+.TP
+.BI "\-framework " name[,suffix]
+Specifies a framework to link against. Frameworks are dynamic shared libraries,
+but they are stored in different locations, and therefore must be searched for
+differently. When this option is specified,
+.I ld_classic
+searches for framework `\fIname\fR.framework/\fIname\fR'
+first in any directories
+specified with the
+.B \-F
+option, then in the standard framework directories
+.BR /Library/Frameworks ,
+.BR /Network/Library/Frameworks ,
+and
+.BR "/System/Library/Frameworks" .
+The placement of the
+.B \-framework
+option is significant, as it determines when and how the framework is searched.
+If the optional suffix is specified the framework is first searched for the
+name with the suffix and then without.
+.TP
+.BI "\-weak_framework " name[,suffix]
+This is the same as the
+.BI "\-framework " name[,suffix]
+but forces the framework and all references to it to be marked as weak imports.
+Care must be taken when using this as the use of the non-weak symbol references
+in an object file may cause the program to crash when the symbol or framework is
+not present at execution time.
+.TP
+.BI \-F dir
+Add
+.I dir
+to the list of directories in which to search for frameworks.
+Directories specified with
+.B \-F
+are searched before the standard framework directories.
+.TP
+.B \-ObjC
+Loads all members of static archive libraries that define an Objective C class or a category. This option does not apply to dynamic shared libraries.
+.TP
+.B \-all_load
+Loads all members of static archive libraries.
+This option does not apply to dynamic shared
+libraries.
+.TP
+.BI \-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.
+.I install_name
+specifies the path where the library normally resides.
+.I 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:
+\fB\-dylib_file /lib/libsys_s.A.dylib:/me/lib/libsys_s.A.dylib\fR.
+.TP
+.BI \-executable_path " path_name"
+Specifies that
+.I path_name
+is used to replace
+.I @executable_path
+for dependent libraries.
+
+.PP
+The following options specify the output file format (the file type):
+.TP
+.B "\-execute"
+Produce a Mach-O demand-paged executable format file. The headers are placed
+in the first segment, and all segments are padded to the segment alignment.
+This has a file type of
+.SM MH_EXECUTE.
+This is the default. If no segment address is specified at address zero, a
+segment with no protection (no read, write, or execute permission) is created
+at address zero.
+This segment, whose size is that of the segment
+alignment, is named
+.SM ``_\|_PAGEZERO''.
+This option was previously named
+.BR "\-Mach" ,
+which will continue to be recognized.
+.TP
+.B \-object
+Produce a Mach-O file in the relocatable object file format that is
+intended for execution. This differs from using the
+.B \-r
+option in that it defines common symbols, does not allow undefined symbols and
+does not preserve relocation entries. This has a file type of
+.SM MH_OBJECT.
+In this format all sections are placed in one unnamed segment with all
+protections (read, write, execute) allowed on that segment. This is intended
+for extremely small programs that would otherwise be large due to segment
+padding. In this format, and all
+.SM non-MH_EXECUTE
+formats, the link editor
+defined symbol ``\_\^\_mh_execute_header'' is not defined since the headers are
+not part of the segment. This format file can't be used with the dynamic
+linker.
+.TP
+.B \-preload
+Produce a Mach-O preloaded executable format file. The headers are not placed
+in any segment. All sections are placed in their proper segments and they are
+padded to the segment alignment. This has a file type of
+.SM MH_PRELOAD.
+This option was previously
+.BR "\-p" ,
+which will continue to be recognized.
+.TP
+.B "\-dylib"
+Produce a Mach-O dynamically linked shared library format file. The headers are
+placed in the first segment. All sections are placed in their proper segments
+and they are padded to the segment alignment. This has a file type of
+.SM MH_DYLIB.
+This option is used by
+.IR libtool (1)
+when its
+.B \-dynamic
+option is specified.
+.TP
+.B "\-bundle"
+Produce a Mach-O bundle format file. The headers are placed in the first
+segment. All sections are placed in their proper segments
+and they are padded to the segment alignment. This has a file type of
+.SM MH_BUNDLE.
+.TP
+.B "\-dylinker"
+Produces a Mach-O dynamic link editor format file. The headers are placed in the
+first segment. All sections are placed in their proper segments, and they are
+padded to the segment alignment. This has a file type of
+.SM MH_DYLINKER.
+.TP
+.B \-fvmlib
+Produce a Mach-O fixed VM shared library format file. The headers are placed
+in the first segment but the first section in that segment will be placed on
+the next segment alignment boundary in that segment. All sections are placed
+in their proper segments and they are padded to the segment alignment.
+This has a file type of
+.SM MH_FVMLIB.
+
+.PP
+The following flags affect the contents of the output file:
+.TP
+.B \-r
+Save the relocation information in the output file
+so that it can be the subject of another
+.I ld_classic
+run. The resulting file type is a Mach-O relocatable file
+.SM (MH_OBJECT)
+if not otherwise specified.
+This flag also prevents final definitions from being
+given to common symbols,
+and suppresses the `undefined symbol' diagnostics.
+.TP
+.B \-d
+Force definition of common storage even if the
+.B \-r
+option is present. This option also forces link editor defined symbols to be defined.
+This option is assumed when there is a dynamic link editor load command in the input
+and
+.B \-r
+is not specified.
+
+.PP
+The following flags support segment specifications:
+.TP
+.BI "\-segalign" " value"
+Specifies the segment alignment.
+.I value
+is a hexadecimal number that must be an integral power of 2.
+The default is the target pagesize (currently 1000 hex for the PowerPC and
+i386).
+.TP
+.BI "\-seg1addr" " addr"
+Specifies the starting address of the first segment in the output file.
+.I addr
+is a hexadecimal number and must be a multiple of the segment alignment.
+This option can also be specified as
+.B "\-image_base."
+.TP
+.BI "\-segaddr" " name addr"
+Specifies the starting address of the segment named
+.I name
+to be
+.I addr.
+The address must be a hexadecimal number that is a multiple of the segment alignment.
+.TP
+.BI "\-segs_read_only_addr" " addr"
+Specifies the starting address of the read-only segments in a dynamic shared
+library. When this option is used the dynamic shared library is built such
+that the read-only and read-write segments are split into separate address
+ranges. By default the read-write segments are 256meg (0x10000000) after
+the read-only segments.
+.I addr
+is a hexadecimal number and must be a multiple of the segment alignment.
+.TP
+.BI "\-segs_read_write_addr" " addr"
+Specifies the starting address of the read-write segments in a dynamic shared
+library. When this option is used the
+.B \-segs_read_only_addr
+must also be used (see above).
+.I addr
+is a hexadecimal number and must be a multiple of the segment alignment.
+.TP
+.BI "\-seg_addr_table" " filename"
+For dynamic shared libraries the
+.B "\-seg1addr"
+or the pair of
+.B "\-segs_read_only_addr"
+and
+.B "\-segs_read_write_addr"
+are specified by an entry in the segment address table in
+.I filename
+that matches the install name of the library.
+The entries in the table are lines containing either a single hex address and an
+install name or two hex addresses and an install name. In the first form the
+single hex address is used as the
+.B "\-seg1addr".
+In the second form the first address is used as the
+.B "\-segs_read_only_addr"
+address and the second address is used as the
+.B "\-segs_read_write_addr"
+address.
+This option can also be specified by setting the environment variable
+.SM LD_SEG_ADDR_TABLE.
+If the environment variable is set then any
+.BR "\-seg1addr" ,
+.BR "\-segs_read_only_addr" ,
+.B "\-segs_read_write_addr"
+and
+.B "\-seg_addr_table"
+options are ignored and a warning is printed.
+.TP
+.BI "\-seg_addr_table_filename" " pathname"
+Use
+.B pathname
+instead of the install name of the library for matching an entry in the segment
+address table.
+.TP
+.BI "\-segprot" " name max init"
+Specifies the maximum and initial virtual memory protection of the named
+segment,
+.I name,
+to be
+.I max
+and
+.I init
+,respectively. The values for
+.I max
+and
+.I init
+are any combination of the characters `r' (for read), `w' (for write),
+`x' (for execute) and '\-' (no access). The default is `rwx' for the maximum
+protection for all segments for PowerPC architecures and `rw` for the all Intel
+architecures.
+The default for the initial protection for all segments is `rw' unless the
+segment contains a section which contains some machine instructions, in which
+case the default for the initial protection is `rwx' (and for Intel
+architecures it also sets the maximum protection to `rwx' in this case).
+The default for the initial protection for the
+.SM "``_\|_TEXT''"
+segment is `rx' (not writable).
+.TP
+.B \-seglinkedit
+Create the link edit segment, named
+.SM "``_\|_LINKEDIT''"
+(this is the default).
+This segment contains all the link edit information (relocation information,
+symbol table, string table, etc.) in the object file. If the segment protection
+for this segment is not specified, the initial protection is not writable.
+This can only be specified when the output file type is not
+.SM MH_OBJECT
+and
+.SM MH_PRELOAD
+output file types. To get at the contents of this section, the Mach header
+and load commands must be parsed from the link editor defined symbols like
+`\_\^\_mh_execute_header' (see
+.IR Mach-O (5)).
+.TP
+.B \-noseglinkedit
+Do not create the link edit segment (see
+.B \-seglinkedit
+above).
+.TP
+.BI "\-pagezero_size" " value"
+Specifies the segment size of _\|_PAGEZERO to be of size
+.IR value ,
+where
+.I value
+is a hexadecimal number rounded to the segment alignment.
+The default is the target pagesize (currently, 1000 hexadecimal for the PowerPC
+and for i386).
+.TP
+.BI "\-stack_addr" " value"
+Specifies the initial address of the stack pointer
+.IR value ,
+where
+.I value
+is a hexadecimal number rounded to the segment alignment.
+The default segment alignment is the target pagesize (currently, 1000
+hexadecimal for the PowerPC and for i386).
+If
+.B \-stack_size
+is specified and
+.B \-stack_addr
+is not, a default stack address specific for the architecture being linked will
+be used and its value printed as a warning message.
+This creates a segment named _\|_UNIXSTACK. Note that the initial stack address
+will be either at the high address of the segment or the low address of the
+segment depending on which direction the stack grows for the architecture being
+linked.
+.TP
+.BI "\-stack_size" " value"
+Specifies the size of the stack segment
+.IR value ,
+where
+.I value
+is a hexadecimal number rounded to the segment alignment.
+The default segment alignment is the target pagesize (currently, 1000
+hexadecimal for the PowerPC and for i386).
+If
+.B \-stack_addr
+is specified and
+.B \-stack_size
+is not, a default stack size specific for the architecture being linked will be
+used and its value printed as a warning message.
+This creates a segment named _\|_UNIXSTACK .
+.TP
+.B \-allow_stack_execute
+Marks executable so that all stacks in the task will be given stack execution
+privilege. This includes pthread stacks.
+
+.PP
+The following flags support section specifications:
+.TP
+.BI "\-sectcreate" " segname sectname file"
+The section
+.I sectname
+in the segment
+.I segname
+is created from the contents of
+.I file.
+The combination of
+.I segname
+and
+.I sectname
+must be unique; there cannot already be a section
+.I (segname,sectname)
+in any input object file.
+This option was previously called
+.BR "\-segcreate" ,
+which will continue to be recognized.
+.TP
+.BI "\-sectalign" " segname sectname value"
+The section named
+.I sectname
+in the segment
+.I segname
+will have its alignment set to
+.IR value ,
+where
+.I value
+is a hexadecimal number that must be an integral power of 2.
+This can be used to set the alignment of a section created from a file, or to
+increase the alignment of a section from an object file, or to set the maximum
+alignment of the
+.SM (_\|_DATA,_\|_common)
+section, where common symbols are defined
+by the link editor. Setting the alignment of a literal section causes the
+individual literals to be aligned on that boundary. If the section
+alignment is not specified by a section header in an object file or on the
+command line, it defaults to 10 (hex), indicating 16-byte alignment.
+.TP
+.BI "\-sectorder" " segname sectname orderfile"
+The section
+.I sectname
+in the segment
+.I segname
+of the input files will be broken up into blocks associated with
+symbols in the section. The output section will be created by ordering
+the blocks as specified by the lines in the
+.I orderfile.
+These blocks are aligned to the output file's section alignment for this
+section. Any section can be ordered in the output file except symbol pointer and symbol stub sections.
+.IP
+For non-literal sections, each line of the
+.I orderfile
+contains an object name and a symbol name, separated by a single colon (':').
+Lines that start with # are ignored and treated as comments.
+If the object file is
+in an archive, the archive name, followed by a single colon, must precede the
+object file name. The object file names and archive names should be exactly the
+names as seen by the link editor, but if not, the link editor attempts to match
+up the names the best it can.
+For non-literal sections, the easiest way to generate an order file is
+with the ``\f3\-jonls +\f2segname sectname\f1'' options to
+.IR nm (1).
+.IP
+The format of the
+.I orderfile
+for literal sections is specific to each type of literal section. For C
+string literal sections, each line of the order file contains one literal C
+string, which may include ANSI C escape sequences. For four-byte literal
+sections, the order file format is one 32-bit hex number with a leading 0x
+per
+line, with the rest of the line treated as a comment. For eight-byte literal
+sections, the order file has two 32-bit hex numbers per line; each number
+has a leading 0x, the two numbers are separated by white
+space, and the rest of the line is treated as a comment.
+For literal pointer sections, the lines in the order file represent
+pointers, one per line. A literal pointer is represented by the name of
+the segment that contains the literal being pointed to, followed by the
+section name, followed by the literal. These three strings are separated
+by colons with no extra white space.
+For all the literal sections, each line in the the order file is simply entered
+into the literal section and will appear in the output file in the same order
+as in the
+order file. There is no check to see whether the literal is present
+in the loaded objects.
+For literal sections, the easiest way to generate an order file is with
+the ``\f3\-X \-v \-s \f2segname sectname\f1'' options to
+.IR otool (1).
+.TP
+.B \-sectorder_detail
+When using the
+.B \-sectorder
+option, any pairs of object file names and symbol names that are found in
+the loaded objects, but not specified in the
+.IR orderfile ,
+are placed last in the output file's section. These pairs are ordered by
+object file (as the filenames appear
+on the command line), with the different symbols from a given object
+file being ordered by
+increasing symbol address (that is, the order
+in which the symbols occurred in the object file,
+not their order in the symbol table). By default, the link editor displays a summary
+that simply shows the number
+of symbol names found in the loaded objects but not in the
+.IR orderfile ,
+as well as the number of symbol names listed in the
+.I orderfile
+but not found in the loaded objects. (The summary is omitted if both values
+are zero.) To instead produce a detailed list of these symbols, use the
+.B \-sectorder_detail
+flag. If an object file-symbol name pair is listed multiple times, a
+warning is generated, and the first occurrence is used.
+.TP
+.BI "\-sectobjectsymbols" " segname sectname"
+This causes the link editor to generate local symbols in the section
+.I sectname
+in the segment
+.IR segname .
+Each object file that has one of these sections will have a local
+symbol created
+whose name is that of the object file, or of the member of the archive.
+The symbol's value will be the first address where that object file's section
+was loaded. The symbol has the type N_SECT and its section number is the
+the same as that of the section
+.I (segname,sectname)
+in the output file.
+This symbol will be placed in the symbol table just before all other local
+symbols
+for the object file. This feature is typically used where the section is
+.SM (\_\^\_TEXT,\_\^\_text),
+in order to help the debugger debug object files produced by old versions of
+the compiler or by non-Apple compilers.
+
+.PP
+The following flags are related to name spaces:
+.TP
+.B \-twolevel_namespace
+Specifies the output to be built as a two-level namespace image.
+This option can also be specified by setting the environment variable
+.SM LD_TWOLEVEL_NAMESPACE.
+This is the default.
+.TP
+.B \-flat_namespace
+Specifies the output to be built as a flat namespace image.
+This is not the default (but was the default in MacOS X 10.0).
+.TP
+.B \-force_flat_namespace
+Specifies the executable output to be built and executed treating all its
+dynamic libraries as flat namespace images. This marks the executable so that
+the dynamic link editor treats all dynamic libraries as flat namespace
+images when the program is executed.
+.TP
+.BI \-bundle_loader " executable"
+This specifies the
+.I 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. If the bundle being created
+with
+.B \-twolevel_namespace
+in effect then the searching of the executable for
+symbols is based on the placement of the
+.B \-bundle_loader
+flag relative to the dynamic libraries. If the the bundle being created with
+.B \-flat_namespace
+then the searching of the executable is done before all dynamic libraries.
+.TP
+.B \-private_bundle
+This allows symbols defined in the output to also be defined in executable in
+the
+.B \-bundle_loader
+argument
+when
+.B \-flat_namespace
+is in effect.
+This implies that the bundle output file being created is going to be loaded by
+the executable with the
+.B NSLINKMODULE_OPTION_PRIVATE
+option to
+.IR NSLinkModule (3).
+.TP
+.B \-twolevel_namespace_hints
+Specifies to create the output with the two-level namespace hints table to be
+used by the dynamic linker. This is the default except when the
+.B \-bundle
+flag is specified. If this is used when the
+.B \-bundle
+flag is specified the bundle will fail to load on a MacOS X 10.0 system with a
+malformed object error.
+.TP
+.BI \-multiply_defined " treatment"
+Specifies how multiply defined symbols in dynamic libraries when
+.B \-twolevel_namespace
+is in effect are to be treated.
+.I treatment
+can be:
+.I error,
+.I warning,
+or
+.I suppress.
+Which cause the treatment of multiply defined symbols in dynamic libraries
+as either, errors, warnings, or suppresses the checking of multiply symbols
+from dynamic libraries when
+.B \-twolevel_namespace
+is in effect.
+The default is to treat multiply defined symbols in dynamic libraries as
+warnings when
+.B \-twolevel_namespace
+is in effect.
+.TP
+.BI \-multiply_defined_unused " treatment"
+Specifies how unused multiply defined symbols in dynamic libraries when
+.B \-twolevel_namespace
+is in effect are to be treated.
+An unused multiply defined symbol is one in which there is a symbol defined in
+the output that is also defined in the dynamic libraries the output is linked
+with but the symbol in the dynamic library is not used by any reference in the
+output.
+.I treatment
+can be:
+.I error,
+.I warning,
+or
+.I suppress.
+The default for unused multiply defined symbols is to suppress these messages.
+.TP
+.B -nomultidefs
+specifying this flag marks the umbrella being created such that the dynamic
+linker is guaranteed that no multiple definitions of symbols in the umbrella's
+sub-images will ever exist. This allows the dynamic linker to always use the
+two-level namespace lookup hints even if the timestamps of the sub-images
+do not match. This flag implies
+.BI \-multiply_defined " error".
+
+.PP
+The following flags are related to symbols. These flags' arguments
+are external symbols whose names have `_' prepended to the C,
+.SM FORTRAN,
+or Pascal variable name.
+.TP
+.BI \-y sym
+Display each file in which
+.I sym
+appears, its type, and whether the file defines or references it. Any
+multiply defined symbols are automatically
+traced. Like most of the other symbol-related flags,
+.B \-y
+takes only one argument; the flag may be specified more than once in the
+command line to trace more than one symbol.
+.TP
+.BI \-Y " number"
+For the first
+.I number
+undefined symbols, displays each file in which the symbol appears, its type and whether the file defines or references it (that is, the same style of output produced by the
+.B \-y
+option). To keep the output manageable, this option displays at most
+.I number
+references.
+.TP
+.B \-keep_private_externs
+Don't turn private external symbols into static symbols, but rather leave them
+as private external in the resulting output file.
+.TP
+.B \-m
+Don't treat multiply defined symbols from the linked objects as a hard error;
+instead, simply print a warning. The first linked object defining such a symbol
+is used for linking; its value is used for the symbol in the symbol table. The
+code and data for all such symbols are copied into the output. The duplicate
+symbols other than the first symbol may still end up being used in the resulting
+output file through local references. This can still produce a resulting output
+file that is in error. This flag's use is strongly discouraged!
+.TP
+.B \-whyload
+Indicate why each member of a library is loaded. In other words, indicate
+which currently undefined symbol is being resolved, causing that
+member to be loaded. This in combination with the above
+.BI \-y sym
+flag can help determine exactly why a link edit is failing due to multiply
+defined symbols.
+.B
+.TP
+.BI \-u " sym"
+Enter the argument
+.I sym
+into the symbol table as an undefined symbol. This is useful
+for loading wholly from a library, since initially the symbol
+table is empty and an unresolved reference is needed
+to force the loading of the first object file.
+.TP
+.BI \-e " sym"
+The argument
+.I sym
+is taken to be the symbol name of the entry point of
+the resulting file. By default, the entry point is the address of the
+first section in the first segment.
+.TP
+.BI \-i definition:indirect
+Create an indirect symbol for the symbol name
+.I definition
+which is defined to be the same as the symbol name
+.I indirect
+(which is taken to be undefined). When a definition of the symbol named
+.I indirect
+is linked, both symbols will take on the defined type and value.
+.IP
+This option overlaps with a compiler option.
+If you use the compiler driver
+.IR cc (1)
+to invoke \fIld_classic\fR,
+invoke this option in this way:
+.BI \-Wl,\-i definition:indirect.
+
+.TP
+.BI \-undefined " treatment"
+Specifies how undefined symbols are to be treated.
+.I treatment
+can be:
+.I error,
+.I warning,
+or
+.I suppress.
+Which cause the treatment of undefined symbols as either, errors, warnings, or
+suppresses the checking of undefined symbols.
+The default is to treat undefined symbols as errors.
+When the environment variable
+.B MACOSX_DEPLOYMENT_TARGET
+is set to
+.B 10.3
+or higher then
+.BI \-undefined " dynamic_lookup"
+can also be used to allow any undefined symbols to be looked up dynamically at
+runtime. Use of a binary built with this flag requires a system with a dynamic
+linker from Mac OS X 10.3 or later.
+The flag
+.BI \-undefined " define_a_way"
+can also be used to cause the static linker to create a private definition for
+all undefined symbols. This flag should only be used if it is known that the
+undefined symbols are not referenced as any use of them may cause a crash.
+.TP
+.BI \-U " sym"
+Allow the symbol
+.I sym
+to be undefined, even if the
+.B \-r
+flag is not given. Produce an executable file if the only undefined
+symbols are those specified with
+.BR \-U.
+.IP
+This option overlaps with a compiler option.
+If you use the compiler driver
+.IR cc (1)
+to invoke \fIld_classic\fR,
+invoke this option in this way:
+.BI \-Wl,\-U, sym.
+.TP
+.B \-bind_at_load
+Causes the output file to be marked such that the dynamic linker will bind all
+undefined references when the file is loaded or launched.
+
+.PP
+The following flags are related to stripping link edit information.
+This information can also be removed by
+.IR strip (1),
+which uses the same options. (The
+exception is the
+.B \-s
+flag below, but this is the same as
+.IR strip (1)
+with no arguments.)
+The following flags are listed in decreasing level of stripping.
+.TP
+.B \-s
+Completely strip the output; that is, remove the symbol table
+and relocation information.
+.TP
+.B \-x
+Strips the non-global symbols; only saves external symbols.
+.IP
+This option overlaps with a compiler option.
+If you use the compiler driver
+.IR cc (1)
+to invoke \fIld_classic\fR,
+invoke this option in this way:
+.B \-Wl,\-x.
+.TP
+.B \-S
+Strip debugging symbols; only save local and global symbols.
+.TP
+.B \-X
+Strip local symbols whose names begin with `L'; save all other symbols.
+(The compiler and assembler currently strip these internally-generated
+labels by default, so they generally do not appear in object files
+seen by the link editor.)
+.TP
+.B \-Sp
+Strip, edit and add debugging symbols so the debugger can used most of the
+debugging symbols from the object files.
+.TP
+.B \-Si
+Strip duplicate debugging symbols from include files. This is
+the default.
+.TP
+.B \-b
+Strip the base file's symbols from the output file. (The base file
+is given as the argument to the
+.B \-A
+option.)
+.IP
+This option overlaps with a compiler option.
+If you use the compiler driver
+.IR cc (1)
+to invoke \fIld_classic\fR,
+invoke this option in this way:
+.B \-Wl,\-b.
+.TP
+.B \-Sn
+Don't strip any symbols.
+.TP
+.BI \-exported_symbols_list " filename"
+The specified
+.I filename
+contains lists 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
+.I __private_extern__
+and will not be global in the output file. The symbol names listed in
+.I 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.
+.TP
+.BI \-unexported_symbols_list " filename"
+The specified
+.I filename
+contains lists 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
+.I __private_extern__
+and will not be global in the output file. The symbol names listed in
+.I 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.
+.TP
+.BI \-no_uuid
+Do not emit an LC_UUID load command in the linked output file.
+
+.TP
+.B -dead_strip
+Remove blocks of code and data that are unreachable by the entry point or
+exported symbols.
+.TP
+.B -no_dead_strip_inits_and_terms
+When specified along with
+.B -dead_strip
+cause all constructors and destructors to never be dead stripped.
+
+.PP
+The remaining options are infrequently used:
+.TP
+.B \-v
+Print the version of the linker.
+.TP
+.B \-w
+Suppresses all warning messages.
+.TP
+.B \-no_arch_warnings
+Suppresses warning messages about files that have the wrong architecture for the
+.B \-arch
+flag.
+.TP
+.B \-arch_errors_fatal
+Cause the errors having to do with files that have the wrong architecture to be
+fatal and stop the link editor.
+.TP
+.B \-M
+Produce a load map, listing all the segments and sections. The list
+includes the address where each input file's section appears in the
+output file, as well as the section's size.
+.IP
+This option overlaps with a compiler option.
+If you use the compiler driver
+.IR cc (1)
+to invoke \fIld_classic\fR,
+invoke this option in this way:
+.B \-Wl,\-M.
+.TP
+.B \-whatsloaded
+Display a single line listing each object file that is
+loaded. Names of objects in archives have the form libfoo.a(bar.o).
+.TP
+.BI \-filelist " listfile[,dirname]"
+Specifies that the linker should link the files listed in
+.I listfile .
+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,
+.I dirname
+is specified, it is prepended to each name in the list file.
+.TP
+.BI "\-headerpad" " value"
+Specifies the minimum amount of space ("padding") following
+the headers for the
+.SM MH_EXECUTE
+format and all output file types with the dynamic linker.
+.I value
+is a hexadecimal number.
+When a segment's size is rounded up to the segment alignment, there
+is extra space left over, which is placed between the headers and the sections, rather than at the end of the segment. The
+.B headerpad
+option specifies the minimum size of this padding,
+which can be useful if the headers will be altered later.
+The default value is the larger of 2 * sizeof(struct section) so the program
+/usr/bin/objcunique can always add two section headers, or if the output is an
+MH_EXECUTE filetype and
+.B \-prebind
+is specified 3 times the size of the LC_PREBOUND_DYLIB load commands.
+The actual amount of pad will be as large as the amount of the first
+segment's round-off.
+(That is, take the total size of the first segments'
+headers and non-zerofill sections, round this size
+up to the segment alignment,
+and use the difference between the rounded
+and unrounded sizes as the minimum amount of padding.)
+.TP
+.B \-headerpad_max_install_names
+Add to the header padding enough space to allow changing all dynamic shared
+library paths recorded in the output file to be changed to MAXPATHLEN in length.
+.TP
+.B \-t
+Trace the progress of the link editor; display the name of each file
+that is
+loaded as it is processed in the first and second pass of the link
+editor.
+.TP
+.BI \-A " basefile"
+Incremental loading: linking is to be done in a manner
+that lets the resulting object be read into an already executing
+program, the
+.IR basefile .
+.I basefile
+is the name of a file whose symbol table will be taken as a basis
+on which to define additional symbols.
+Only newly linked material will be entered into the
+.BR a.out
+file, but the new symbol table will reflect
+every symbol defined in the base file and the newly linked files.
+Option(s) to specify the addresses of the segments are typically
+needed, since
+the default addresses tend to overlap with the
+.I basefile.
+The default format of the object file is
+.SM MH_OBJECT.
+Note: It is strongly recommended that this option NOT be used,
+because the dyld package described in
+.IR dyld (3)
+is a much easier alternative.
+.TP
+.BI \-dylib_install_name " name"
+For dynamic shared library files, specifies the name of the file
+the library will be installed in for programs that use it. If this is not
+specified, the name specified in the
+.BI \-o " name"
+option will be used.
+This option is used as the
+.IR libtool (1)
+.BI \-install_name " name"
+option when its
+.B \-dynamic
+option is specified.
+.TP
+.BI \-umbrella " framework_name"
+Specifies this is a subframework where
+.I framework_name
+is the name of the umbrella framework this subframework is a part of. Where
+.I framework_name
+is the same as the argument to the
+.BI \-framework " framework_name"
+option. This subframework can then only be linked into the umbrella framework
+with the same
+.I framework_name
+or another subframework with the same umbrella framework name. Any other
+attempt to statically link this subframework directly will result in an error
+stating to link with the umbrella framework instead. When building the umbrella
+framework that uses this subframework no additional options are required.
+However the install name of the umbrella framework, required to be specified
+with
+.BR \-dylib_install_name ,
+must have the proper format for an install name of a framework for the
+.I framework_name
+of the umbrella framework to be determined.
+.TP
+.BI \-allowable_client " client_name"
+Specifies that for this subframework the
+.I client_name
+can link with this subframework without error even though it is not part of
+the umbrella framework that this subframework is part of. The
+.I client_name
+can be another framework name or a name used by bundles (see the
+.BI \-client_name " client_name"
+option below).
+.TP
+.BI \-client_name " client_name"
+Specifies the
+.I client_name
+of a bundle for checking of allowable clients of subframeworks (see the
+.BI \-allowable_client " client_name"
+option above).
+.TP
+.BI \-sub_umbrella " framework_name"
+Specifies that the
+.I framework_name
+being linked by a dynamic library is to be treated as one of the
+subframeworks with respect to twolevel namespace.
+.TP
+.BI \-sub_library " library_name"
+Specifies that the
+.I library_name
+being linked by a dynamic library is to be treated as one of the
+sublibraries with respect to twolevel namespace. For example the
+.I library_name
+for
+.I /usr/lib/libobjc_profile.A.dylib
+would be
+.I libobjc.
+.TP
+.BI \-init " sym"
+The argument
+.I sym
+is taken to be the symbol name of the dynamic shared library initialization
+routine. If any module is used from the dynamic library the library
+initialization routine is called before any symbol is used from the library
+including C++ static initializers (and #pragma CALL_ON_LOAD routines).
+.TP
+.B \-run_init_lazily
+This option is obsolete.
+.TP
+.BI \-dylib_compatibility_version " number"
+For dynamic shared library files, this specifies the compatibility version number
+of the library. When a library is used by a program, the compatibility version is checked
+and if the program's version is greater that the library's version, it is an error.
+The format of
+.I number
+is
+.I X[.Y[.Z]]
+where
+.I X
+must be a positive non-zero number less than or equal to 65535, and
+.I .Y
+and
+.I .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 used as the
+.IR libtool (1)
+.BI \-compatibility_version " number"
+option
+when its
+.B \-dynamic
+option is set.
+.TP
+.BI \-dylib_current_version " number"
+For dynamic shared library files, 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
+.I number
+is
+.I X[.Y[.Z]]
+where
+.I X
+must be a positive non-zero number less than or equal to 65535, and
+.I .Y
+and
+.I .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 used as the
+.IR libtool (1)
+.BI \-current_version " number"
+option when its
+.B \-dynamic
+option is set.
+.TP
+.BI \-single_module
+When building a dynamic library build the library so that it contains only
+one module.
+.TP
+.BI \-multi_module
+When building a dynamic library build the library so that it contains one
+module for each object file linked in. This is the default.
+.TP
+.BI \-dylinker_install_name " name"
+For dynamic link editor files, specifies the name of the file
+the dynamic link editor will be installed in for programs that use it.
+.TP
+.BI \-macosx_version_min " version"
+This overrides the
+.B MACOSX_DEPLOYMENT_TARGET
+environment variable (see below). Unlike other linker options, this one may
+be specified multiple times; only the last occurrence is effective.
+.PP
+The following environment variable is used to control the use of incompatible
+features in the output with respect to Mac OS X releases.
+.TP
+.B MACOSX_DEPLOYMENT_TARGET
+This is set to indicate the oldest Mac OS X version that that the output is to
+be used on. When this is set to a release that is older than the current
+release features that are incompatible with that release will be disabled. If
+a feature is seen in the input that can't be in the output due to this setting
+a warning is issued. The current allowable values for this are
+.B 10.1,
+.B 10.2
+.B 10.3,
+and
+.B 10.4
+with the default being
+.B 10.4
+for the i386 architecture and
+.B 10.1
+for all other architectures.
+.PP
+The following environment variables are used by Apple's Build and Integration
+team:
+.TP
+.B LD_TRACE_ARCHIVES
+When this is set it causes a message of the form ``[Logging for XBS]
+Used static archive:
+.I filename''
+for each static archive that has members linked into the output.
+.TP
+.B LD_TRACE_DYLIBS
+When this is set it causes a message of the form ``[Logging for XBS]
+Used dynamic library:
+.I filename''
+for each dynamic library linked into the output.
+.TP
+.B RC_TRACE_PREBINDING_DISABLED
+When this is set it causes a message of the form ``[Logging for XBS
+prebinding disabled for
+.I filename
+because
+.I reason''.
+Where
+.I filename
+is the value of the
+.B \-final_output
+argument if specified or the value of the
+.B \-o
+argument.
+.TP
+.BI \-final_output " filename"
+The argument
+.I filename
+is used in the above message when RC_TRACE_PREBINDING_DISABLED is set.
+.TP
+.B LD_TRACE_FILE
+When this is set, messages displayed due to the
+.B LD_TRACE_ARCHIVES
+,
+.B LD_TRACE_DYLIBS
+, and
+.B LD_TRACE_PREBINDING_DISABLED
+environment variables are printed to the file whose path is specified
+by this variable instead of stdout.
+.TP
+.B LD_SPLITSEGS_NEW_LIBRARIES
+When set and
+.B MACOSX_DEPLOYMENT_TARGET
+is set to 10.4 or greater and the output is a dynamic library, and if the
+install name of the library is not listed the segment address table, and if the
+environment variable
+.B LD_UNPREBOUND_LIBRARIES
+is set with a file name with a list of library install names and the install
+name is not listed, then this is built as a split shared library.
+
+.PP
+Options available in early versions of the Mach-O link editor
+may no longer be supported.
+
+.SH FILES
+.ta \w'/Network/Library/Frameworks/*.framework/*\ \ 'u
+/lib/lib*.{a,dylib} libraries
+.br
+/usr/lib/lib*.{a,dylib}
+.br
+/usr/local/lib/lib*.{a,dylib}
+.br
+/Library/Frameworks/*.framework/* framework libraries
+.br
+/Network/Library/Frameworks/*.framework/* framework libraries
+.br
+/System/Library/Frameworks/*.framework/* framework libraries
+.br
+a.out output file
+.SH "SEE ALSO"
+as(1), ar(1), cc(1), libtool(1), ranlib(1), nm(1), otool(1) lipo(1), ld(1),
+arch(3), dyld(3), Mach-O(5), strip(1), redo_prebinding(1)
View
2 i386/Cconfig
@@ -8,6 +8,8 @@ config OPTIMIZATION_LEVEL
---help---
Specify the level to compile chameleon with.
+source "i386/md/Cconfig"
+
source "i386/util/Cconfig"
source "i386/boot0/Cconfig"
View
10 i386/Makefile
@@ -4,6 +4,7 @@
# these paths are only valid in subdirectories of this directory
#
SRCROOT = $(abspath $(CURDIR)/..)
+BINROOT = $(SRCROOT)/bin
OBJROOT = $(SRCROOT)/obj/i386
SYMROOT = $(SRCROOT)/sym/i386
DSTROOT = $(SRCROOT)/dst/i386
@@ -15,7 +16,14 @@ CDBOOT = ${IMGROOT}/usr/standalone/i386/cdboot
include ${SRCROOT}/Make.rules
# The order of building is important.
-SUBDIRS_PRE = util
+SUBDIRS_PRE =
+
+ifeq ($(CONFIG_MD),y)
+SUBDIRS_PRE += md
+endif
+
+SUBDIRS_PRE += util
+
SUBDIRS = $(SUBDIRS_PRE) klibc libsa libsaio boot0 boot1 boot2 cdboot modules
modules-builtin:
View
25 i386/boot2/Makefile
@@ -1,4 +1,5 @@
SRCROOT = $(abspath $(CURDIR)/../..)
+BINROOT = $(SRCROOT)/bin
OBJROOT = $(SRCROOT)/obj/i386/boot2
SYMROOT = $(SRCROOT)/sym/i386
DSTROOT = $(SRCROOT)/dst/i386
@@ -36,7 +37,7 @@ THEMEDIR = ../../artwork/themes/$(THEME)
INC = -I. -I$(SRCROOT) -I$(SYMDIR) -I$(LIBSADIR) -I$(LIBSAIODIR) -I${SRCROOT}/i386/include
LIBS= -L$(SYMDIR) -lsaio -lsa -lklibc
-LIBDEP= libsaio.a libsa.a libklibc.a
+LIBDEP= libsaio.a libsa.a libklibc.a
OTHER_FILES =
@@ -80,9 +81,9 @@ endif
@${MKDIRS} $(OBJROOT)/../boot2_modules/
@echo "\t[LD] boot.sys"
- @$(CC) -Wl,-segaddr,__INIT,$(BOOT2ADDR) -Wl,-segalign,20 -Wl,-preload \
- -nostdlib -arch i386 -static \
- -o $(SYMROOT)/boot.sys $(filter %.o,$^) `find $(OBJROOT)/../boot2_modules/ -name \*.o` $(LIBS) -lcc_kext
+ @$(BINROOT)/ld_classic -static -segalign 20 -segaddr __INIT $(BOOT2ADDR) -preload \
+ -arch i386 -e boot2 \
+ -o $(SYMROOT)/boot.sys $(filter %.o,$^) `find $(OBJROOT)/../boot2_modules/ -name \*.o` $(LIBS) `find /usr/llvm-gcc-*/lib/gcc/*/*/ -name \libcc_kext.a`
ifeq (${CONFIG_MODULES}, y)
@@ -93,10 +94,10 @@ ifeq (${CONFIG_MODULES}, y)
@$(SYMROOT)/dyldsymboltool $(SYMROOT)/boot.sys $(SYMROOT)/${SYMBOLS_MODULE}
@echo "\t[LD] boot.sys"
- @$(CC) -static -Wl,-preload -Wl,-segaddr,__INIT,$(BOOT2ADDR) \
- -nostdlib -arch i386 -Wl,-segalign,20 \
- -Wl,-sectcreate,__DATA,__Symbols,$(SYMROOT)/Symbols.dylib \
- -o $(SYMROOT)/boot.sys $(filter %.o,$^) `find $(OBJROOT)/../boot2_modules/ -name \*.o` $(LIBS) -lcc_kext
+ @$(BINROOT)/ld_classic -static -segalign 20 -segaddr __INIT $(BOOT2ADDR) -preload \
+ -arch i386 -e boot2\
+ -sectcreate __DATA __Symbols $(SYMROOT)/Symbols.dylib \
+ -o $(SYMROOT)/boot.sys $(filter %.o,$^) `find $(OBJROOT)/../boot2_modules/ -name \*.o` $(LIBS) `find /usr/llvm-gcc-*/lib/gcc/*/*/ -name \libcc_kext.a`
@# Second pass, fixup global var locations
@${RM} $(SYMROOT)/${SYMBOLS_MODULE}
@@ -107,10 +108,10 @@ ifeq (${CONFIG_MODULES}, y)
@${RM} $(SYMROOT)/boot.sys
@echo "\t[LD] boot.sys"
- @$(CC) -static -Wl,-preload -Wl,-segaddr,__INIT,$(BOOT2ADDR) \
- -nostdlib -arch i386 -Wl,-segalign,20 \
- -Wl,-sectcreate,__DATA,__Symbols,$(SYMROOT)/Symbols.dylib \
- -o $(SYMROOT)/boot.sys $(filter %.o,$^) `find $(OBJROOT)/../boot2_modules/ -name \*.o` $(LIBS) -lcc_kext
+ @$(BINROOT)/ld_classic -static -segalign 20 -segaddr __INIT $(BOOT2ADDR) -preload \
+ -arch i386 \
+ -sectcreate __DATA __Symbols $(SYMROOT)/Symbols.dylib \
+ -o $(SYMROOT)/boot.sys $(filter %.o,$^) `find $(OBJROOT)/../boot2_modules/ -name \*.o` $(LIBS) `find /usr/llvm-gcc-*/lib/gcc/*/*/ -name \libcc_kext.a`
@${RM} $(SYMROOT)/${SYMBOLS_MODULE}
View
7 i386/md/Cconfig
@@ -0,0 +1,7 @@
+config MD
+ bool "md utility"
+ default y
+ help
+ Say Y here if you want to compile the md utility.
+ md is used to process the raw dependency files produced by the compiler -MD option.
+ When in doubt, say "Y".
View
43 i386/md/Makefile
@@ -0,0 +1,43 @@
+#
+# Until I can remove the dependency on the appkit,
+# we'll just keep the generated files in this directory
+# and install them directly, rather than generating them again.
+#
+SRCROOT = $(abspath $(CURDIR)/../..)
+OBJROOT = $(SRCROOT)/obj/i386/util
+SYMROOT = $(SRCROOT)/sym/i386
+DSTROOT = $(SRCROOT)/dst/i386
+DOCROOT = $(SRCROOT)/doc
+IMGROOT = $(SRCROOT)/sym/cache
+IMGSKELROOT = $(SRCROOT)/imgskel
+CDBOOT = ${IMGROOT}/usr/standalone/i386/cdboot
+
+
+DIR = util
+include ${SRCROOT}/Make.rules
+
+PROGRAMS = md
+OBJS = md.o32_nodep #md.o64_nodep
+
+
+OBJS := $(addprefix $(OBJROOT)/, $(OBJS))
+
+LDFLAGS := $(LDFALGS) -mdynamic-no-pic -Wall -dead_strip -mmacosx-version-min=10.5
+
+SYMPROG = $(addprefix $(SYMROOT)/, $(PROGRAMS))
+
+DIRS_NEEDED = $(OBJROOT) $(SYMROOT)
+
+all: $(DIRS_NEEDED) $(SYMPROG) all-recursive
+
+$(SYMPROG): $(OBJS)
+ @echo "\t[LD32] $(@F)"
+ @$(CC) $(CFLAGS) $(LDFLAGS) $(DEFINES) -arch i386 -o $(SYMROOT)/$(@F) $(OBJROOT)/$(@F).o32_nodep
+
+#dependencies
+-include $(OBJROOT)/Makedep
+
+clean-local:
+ @for o in $(OBJS); do if [ -f "$${o}" ];then echo "\t[RM] $${o}"; fi; done
+ @for p in $(SYMPROG); do if [ -f "$${p}" ];then echo "\t[RM] $${p}"; fi; done
+ @rm -f $(SYMPROG) $(OBJS)
View
121 i386/md/md.1
@@ -0,0 +1,121 @@
+.\" Man page Copyright (c) 2002
+.\" Apple Computer
+.\"
+.\" Redistribution and use in source and binary forms, with or without
+.\" modification, are permitted provided that the following conditions
+.\" are met:
+.\" 1. Redistributions of source code must retain the above copyright
+.\" notice, this list of conditions and the following disclaimer.
+.\" 2. Redistributions in binary form must reproduce the above copyright
+.\" notice, this list of conditions and the following disclaimer in the
+.\" documentation and/or other materials provided with the distribution.
+.\"
+.\" THIS DOCUMENTATION IS PROVIDED BY THE APPLE ``AS IS'' AND
+.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+.\" ARE DISCLAIMED. IN NO EVENT SHALL APPLE BE LIABLE
+.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+.\" SUCH DAMAGE.
+.\"
+.\"
+.Dd "December 25, 2002"
+.Dt md 1
+.Os
+.Sh NAME
+.Nm md
+.Nd process raw dependency files produced by cpp -MD
+.Sh SYNOPSIS
+.Nm
+.Op Fl d
+.Op Fl f
+.Op Fl m Ar makefile
+.Op Fl u Ar makefile
+.Op Fl o Ar outputfile
+.Op Fl v
+.Op Fl x
+.Op Fl D Ar c|d|m|o|t|D
+.Sh DESCRIPTION
+The
+.Nm
+command basically does two things:
+.Pp
+Process the raw dependency files produced by the cpp -MD option.
+There is one line in the file for every #include encountered, but
+there are repeats and patterns like .../dir1/../dir2 that appear which
+should reduce to .../dir2.
+.Nm
+canonicalizes and flushes repeats from the dependency list.
+It also sorts the file names and "fills" them to a 78 character line.
+.Pp
+.Nm
+also updates the makefile directly with the dependency information,
+so the .d file can be thrown away (see
+.Ar d
+option). This is done to save space.
+.Nm
+assumes that dependency information in the makefile is sorted by .o
+file name and it procedes to merge in (add/or replace [as appropriate])
+the new dependency lines that it has generated.
+For time efficiency,
+.Nm
+assumes that any .d files it is given that were created
+before the creation date of the "makefile" were processed
+already. It ignores them unless the force flag
+.Op f
+is given.
+.Pp
+.Sh FLAG SUMMARY
+.Bl -tag -width indent
+.It Fl D Ar c|D|d|m|o|t
+Specify debugging option(s):
+.Bl -tag -width indent
+.It c
+show file contents
+.It D
+show very low level debugging
+.It d
+show new dependency crunching
+.It m
+show generation of makefile
+.It o
+show files being opened
+.It t
+show time comparisons
+.El
+.It Fl d
+Delete the .d file after it is processed
+.It Fl f
+Force an update of the dependencies in the makefile,
+even if the makefile is more recent than the .n file.
+(This implies that
+.Nm
+has been run already.)
+.It Fl m Ar makefile
+Specify the makefile to be upgraded. The defaults are
+.Ar makefile
+and then
+.Ar Makefile .
+.It Fl o Ar outputfile
+Specify an output file (other than a makefile) for the dependencies.
+.It Fl u Ar makefile
+Like
+.Fl m ,
+but the file will be created if necessary.
+.It Fl v
+Set the verbose flag.
+.It Fl x
+Expunge old dependency information from the makefile.
+.El
+.Sh SEE ALSO
+.Xr make 1
+.Sh BUGS
+Old, possibly not used by anyone.
+.Sh HISTORY
+The
+.Nm
+utility was written by Robert V. Baron at Carnegie-Mellon University.
View
726 i386/md/md.c
@@ -0,0 +1,726 @@
+/* ************************************************************************ *\
+ * *
+ * File: md.c *
+ * *
+ * Updates makefiles from the .n dependency files generated by the *
+ * -MD option to "cc" (and "cpp"). *
+ * *
+ * Abstract: *
+ * *
+ * Basically, "md" does two things: *
+ * 1) It processes the raw dependency files produced by the cpp -MD *
+ * option. There is one line in the file for every #include *
+ * encountered, but there are repeats and patterns like *
+ * .../dir1/../dir2 appear which should reduce to .../dir2 *
+ * Md canonicalizes and flushes repeats from the dependency *
+ * list. It also sorts the file names and "fills" them to a 78 *
+ * character line. *
+ * 2) Md also updates the makefile directly with the dependency *
+ * information, so the .d file can be thrown away (-- -d option) *
+ * This is done to save space. Md assumes that dependency *
+ * information in the makefile is sorted by .o file name and it *
+ * procedes to merge in (add/or replace [as appropriate]) the new *
+ * dependency lines that it has generated. For time effeciency, *
+ * Md assumes that any .d files it is given that were created *
+ * before the creation date of the "makefile" were processed *
+ * already. It ignores them unless the force flag (-f) is given. *
+ * *
+ * Arguments: *
+ * *
+ * -d delete the .d file after it is processed *
+ * -f force an update of the dependencies in the makefile *
+ * even though the makefile is more recent than the .n file *
+ * (This implies that md has been run already.) *
+ * -m specify the makefile to be upgraded. The defaults are *
+ * "makefile" and then "Makefile". *
+ * -u like -m above, but the file will be created if necessary *
+ * -o specify an output file for the dependencies other than a *
+ * makefile *
+ * -v set the verbose flag *
+ * -x expunge old dependency info from makefile *
+ * -D subswitch for debugging. can be followed by any of *
+ * "c", "d", "m", "o", "t", "D" meaning: *
+ * c show file contents *
+ * d show new dependency crunching *
+ * m show generation of makefile *
+ * o show files being opened *
+ * t show time comparisons *
+ * D show very low level debugging *
+ * *
+ * Author: Robert V. Baron *
+ * Copyright (c) 1986 by Robert V. Baron *
+ * *
+ * HISTORY *
+ * 29-Apr-87 Robert Baron (rvb) at Carnegie-Mellon University
+ * If specified -u file does not exist, assume it is empty and
+ * generate one. As a sanity check, it must be possible to create
+ * the output file.
+ * Also, generalized fix below to handle any case of . as a
+ * file name.
+ *
+ * 25-Mar-87 Mary Thompson (mrt) at Carnegie Mellon
+ * Fixed up pathnamecanonicalization to recognize .// and
+ * drop the second / as well. mmax cpp generates this form.
+ *
+ * 6-Jan-87 Robert Baron (rvb) at Carnegie-Mellon University
+ * Fixed up pathname canonicalization to that ../../, etc would be
+ * handled correctly.
+ * Also made "force" on by default.
+ *
+ * 16-Mar-86 Robert Baron (rvb) at Carnegie-Mellon University
+ * Created 4/16/86 *
+ * *
+ \* ************************************************************************ */
+
+/* cleaned and adapted for Chameleon by cparm */
+
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <fcntl.h>
+
+#define LINESIZE 65536 // NeXT_MOD
+
+#define OUTLINELEN 79
+#define IObuffer 50000
+#define SALUTATION "# Dependencies for File:"
+#define SALUTATIONLEN (sizeof SALUTATION - 1)
+#define OLDSALUTATION "# DO NOT DELETE THIS LINE"
+#define OLDSALUTATIONLEN (sizeof OLDSALUTATION - 1)
+
+static char file_array[IObuffer]; /* read file and store crunched names */
+static char dep_line[LINESIZE]; /* line being processed */
+static char dot_o[LINESIZE]; /* <foo.o>: prefix */
+static char *path_component[100]; /* stores components for a path while being
+ crunched */
+
+static struct dep { /* stores paths that a file depends on */
+ int len;
+ char *str;
+} dep_files[1000];
+static int dep_file_index;
+
+static int qsort_strcmp(struct dep *a, struct dep *b)
+{
+ extern int strcmp();
+ return strcmp(a->str, b->str);
+}
+
+static char *outfile = (char *) 0; /* generate dependency file */
+static FILE *out;
+
+static char *makefile = (char *) 0; /* user supplied makefile name */
+static char *real_mak_name; /* actual makefile name (if not supplied) */
+static char shadow_mak_name[LINESIZE]; /* changes done here then renamed */
+static FILE *mak; /* for reading makefile */
+static FILE *makout; /* for writing shadow */
+static char makbuf[LINESIZE]; /* one line buffer for makefile */
+static struct stat makstat; /* stat of makefile for time comparisons */
+static int mak_eof = 0; /* eof seen on makefile */
+
+static int delete = 0; /* -d delete dependency file */
+static int debug = 0;
+static int D_contents = 0; /* print file contents */
+static int D_depend = 0; /* print dependency processing info */
+static int D_make = 0; /* print makefile processing info */
+static int D_open = 0; /* print after succesful open */
+static int D_time = 0; /* print time comparison info */
+static int force = 1; /* always update dependency info */
+static int update = 0; /* it's ok if the -m file does not exist */
+static int verbose = 0; /* tell me something */
+static int expunge = 0; /* first flush dependency stuff from makefile */
+
+
+static char *name;
+static int read_dep(register char *file);
+static void save_dot_o(void);
+static void parse_dep(void);
+static void output_dep(FILE *out);
+static FILE *find_mak(char *file);
+static FILE *temp_mak(void);
+static void scan_mak(FILE *, FILE *, char *);
+static void expunge_mak(register FILE *makin, register FILE *makout);
+static void skip_mak(register FILE *makin, register FILE *makout);
+static void finish_mak(FILE *, FILE *);
+
+int main(int argc, register char **argv)
+{
+ int size;
+
+ name = *argv;
+ {
+ register char *cp =name;
+ while (*cp) if (*cp++ == '/') name = cp;
+ }
+
+ for ( argv++ ; --argc ; argv++ )
+ {
+
+ register char *token = *argv;
+ if (*token++ != '-' || !*token)