[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

21.17.6 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, including spacing, for the assembler operation to identify the following data as initialization code. If not defined, GCC 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.

SUPPORTS_INIT_PRIORITY
If nonzero, the C++ init_priority attribute is supported and the compiler should emit instructions to control the order of initialization of objects. If zero, the compiler will issue an error message upon encountering an init_priority attribute.

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 initialization 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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

This document was generated by Vincent Chung on June, 26 2001 using texi2html