GNU Info

Info Node: (gcc-295.info)Macros for Initialization

(gcc-295.info)Macros for Initialization


Next: Instruction Output Prev: Initialization Up: Assembler Format
Enter node , (file) or (file)node

Macros Controlling Initialization Routines
------------------------------------------

   Here are the macros that control how the compiler handles
initialization and termination functions:

`INIT_SECTION_ASM_OP'
     If defined, a C string constant for the assembler operation to
     identify the following data as initialization code.  If not
     defined, GNU CC will assume such a section does not exist.  When
     you are using special sections for initialization and termination
     functions, this macro also controls how `crtstuff.c' and
     `libgcc2.c' arrange to run the initialization functions.

`HAS_INIT_SECTION'
     If defined, `main' will not call `__main' as described above.
     This macro should be defined for systems that control the contents
     of the init section on a symbol-by-symbol basis, such as OSF/1,
     and should not be defined explicitly for systems that support
     `INIT_SECTION_ASM_OP'.

`LD_INIT_SWITCH'
     If defined, a C string constant for a switch that tells the linker
     that the following symbol is an initialization routine.

`LD_FINI_SWITCH'
     If defined, a C string constant for a switch that tells the linker
     that the following symbol is a finalization routine.

`INVOKE__main'
     If defined, `main' will call `__main' despite the presence of
     `INIT_SECTION_ASM_OP'.  This macro should be defined for systems
     where the init section is not actually run automatically, but is
     still useful for collecting the lists of constructors and
     destructors.

`ASM_OUTPUT_CONSTRUCTOR (STREAM, NAME)'
     Define this macro as a C statement to output on the stream STREAM
     the assembler code to arrange to call the function named NAME at
     initialization time.

     Assume that NAME is the name of a C function generated
     automatically by the compiler.  This function takes no arguments.
     Use the function `assemble_name' to output the name NAME; this
     performs any system-specific syntactic transformations such as
     adding an underscore.

     If you don't define this macro, nothing special is output to
     arrange to call the function.  This is correct when the function
     will be called in some other manner--for example, by means of the
     `collect2' program, which looks through the symbol table to find
     these functions by their names.

`ASM_OUTPUT_DESTRUCTOR (STREAM, NAME)'
     This is like `ASM_OUTPUT_CONSTRUCTOR' but used for termination
     functions rather than initialization functions.

     When `ASM_OUTPUT_CONSTRUCTOR' and `ASM_OUTPUT_DESTRUCTOR' are
     defined, the initializaiton routine generated for the generated
     object file will have static linkage.

   If your system uses `collect2' as the means of processing
constructors, then that program normally uses `nm' to scan an object
file for constructor functions to be called.  On such systems you must
not define `ASM_OUTPUT_CONSTRUCTOR' and `ASM_OUTPUT_DESTRUCTOR' as the
object file's initialization routine must have global scope.

   On certain kinds of systems, you can define these macros to make
`collect2' work faster (and, in some cases, make it work at all):

`OBJECT_FORMAT_COFF'
     Define this macro if the system uses COFF (Common Object File
     Format) object files, so that `collect2' can assume this format
     and scan object files directly for dynamic constructor/destructor
     functions.

`OBJECT_FORMAT_ROSE'
     Define this macro if the system uses ROSE format object files, so
     that `collect2' can assume this format and scan object files
     directly for dynamic constructor/destructor functions.

     These macros are effective only in a native compiler; `collect2' as
     part of a cross compiler always uses `nm' for the target machine.

`REAL_NM_FILE_NAME'
     Define this macro as a C string constant containing the file name
     to use to execute `nm'.  The default is to search the path
     normally for `nm'.

     If your system supports shared libraries and has a program to list
     the dynamic dependencies of a given library or executable, you can
     define these macros to enable support for running initialization
     and termination functions in shared libraries:

`LDD_SUFFIX'
     Define this macro to a C string constant containing the name of the
     program which lists dynamic dependencies, like `"ldd"' under SunOS
     4.

`PARSE_LDD_OUTPUT (PTR)'
     Define this macro to be C code that extracts filenames from the
     output of the program denoted by `LDD_SUFFIX'.  PTR is a variable
     of type `char *' that points to the beginning of a line of output
     from `LDD_SUFFIX'.  If the line lists a dynamic dependency, the
     code must advance PTR to the beginning of the filename on that
     line.  Otherwise, it must set PTR to `NULL'.


automatically generated by info2www version 1.2.2.9