AX_SYS_WEAK_ALIAS
Determines whether weak aliases are supported on the system, and if so, what scheme is used to declare them. Also checks to see if aliases can cross object file boundaries, as some systems don’t permit them to.
Most systems permit something called a "weak alias" or "weak symbol." These aliases permit a library to provide a stub form of a routine defined in another library, thus allowing the first library to operate even if the other library is not linked. This macro will check for support of weak aliases, figure out what schemes are available, and determine some characteristics of the weak alias support – primarily, whether a weak alias declared in one object file may be referenced from another object file.
There are four known schemes of declaring weak symbols; each scheme is checked in turn, and the first one found is preferred. Note that only one of the mentioned preprocessor macros will be defined!
1. Function attributes
This scheme was first introduced by the GNU C compiler, and attaches attributes to particular functions. It is among the easiest to use, and so is the first one checked. If this scheme is detected, the preprocessor macro HAVE_SYS_WEAK_ALIAS_ATTRIBUTE will be defined to 1. This scheme is used as in the following code fragment:
void __weakf(int c)
{
/* Function definition... */
}
void weakf(int c) __attribute__((weak, alias("__weakf")));
2. #pragma weak
This scheme is in use by many compilers other than the GNU C compiler. It is also particularly easy to use, and fairly portable – well, as portable as these things get. If this scheme is detected first, the preprocessor macro HAVE_SYS_WEAK_ALIAS_PRAGMA will be defined to 1. This scheme is used as in the following code fragment:
extern void weakf(int c);
#pragma weak weakf = __weakf
void __weakf(int c)
{
/* Function definition... */
}
3. #pragma _HP_SECONDARY_DEF
This scheme appears to be in use by the HP compiler. As it is rather specialized, this is one of the last schemes checked. If it is the first one detected, the preprocessor macro HAVE_SYS_WEAK_ALIAS_HPSECONDARY will be defined to 1. This scheme is used as in the following code fragment:
extern void weakf(int c);
#pragma _HP_SECONDARY_DEF __weakf weakf
void __weakf(int c)
{
/* Function definition... */
}
4. #pragma _CRI duplicate
This scheme appears to be in use by the Cray compiler. As it is rather specialized, it too is one of the last schemes checked. If it is the first one detected, the preprocessor macro HAVE_SYS_WEAK_ALIAS_CRIDUPLICATE will be defined to 1. This scheme is used as in the following code fragment:
extern void weakf(int c);
#pragma _CRI duplicate weakf as __weakf
void __weakf(int c)
{
/* Function definition... */
}
In addition to the preprocessor macros listed above, if any scheme is found, the preprocessor macro HAVE_SYS_WEAK_ALIAS will also be defined to 1.
Once a weak aliasing scheme has been found, a check will be performed to see if weak aliases are honored across object file boundaries. If they are, the HAVE_SYS_WEAK_ALIAS_CROSSFILE preprocessor macro is defined to 1.
This Autoconf macro also makes two substitutions. The first, WEAK_ALIAS, contains the name of the scheme found (one of "attribute", "pragma", "hpsecondary", or "criduplicate"), or "no" if no weak aliasing scheme was found. The second, WEAK_ALIAS_CROSSFILE, is set to "yes" or "no" depending on whether or not weak aliases may cross object file boundaries.
Download the latest version of ax_sys_weak_alias.m4 or browse the macro’s revision history.
Copyright © 2008 Kevin L. Mitchell klmitch@mit.edu
Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. This file is offered as-is, without any warranty.