If plugins are enabled, GCC installs the headers needed to build a plugin (somewhere in the installation tree, e.g. under /usr/local). In particular a plugin/include directory is installed, containing all the header files needed to build plugins.
On most systems, you can query this plugin
directory by
invoking gcc -print-file-name=plugin
(replace if needed
gcc
with the appropriate program path).
Inside plugins, this plugin
directory name can be queried by
calling default_plugin_dir_name ()
.
Plugins may know, when they are compiled, the GCC version for which
plugin-version.h is provided. The constant macros
GCCPLUGIN_VERSION_MAJOR
, GCCPLUGIN_VERSION_MINOR
,
GCCPLUGIN_VERSION_PATCHLEVEL
, GCCPLUGIN_VERSION
are
integer numbers, so a plugin could ensure it is built for GCC 4.7 with
#if GCCPLUGIN_VERSION != 4007 #error this GCC plugin is for GCC 4.7 #endif
The following GNU Makefile excerpt shows how to build a simple plugin:
HOST_GCC=g++ TARGET_GCC=gcc PLUGIN_SOURCE_FILES= plugin1.c plugin2.cc GCCPLUGINS_DIR:= $(shell $(TARGET_GCC) -print-file-name=plugin) CXXFLAGS+= -I$(GCCPLUGINS_DIR)/include -fPIC -fno-rtti -O2 plugin.so: $(PLUGIN_SOURCE_FILES) $(HOST_GCC) -shared $(CXXFLAGS) $^ -o $@
A single source file plugin may be built with g++ -I`gcc
-print-file-name=plugin`/include -fPIC -shared -fno-rtti -O2 plugin.cc -o
plugin.so
, using backquote shell syntax to query the plugin
directory.
Plugin support on Windows/MinGW has a number of limitations and additional requirements. When building a plugin on Windows we have to link an import library for the corresponding backend executable, for example, cc1.exe, cc1plus.exe, etc., in order to gain access to the symbols provided by GCC. This means that on Windows a plugin is language-specific, for example, for C, C++, etc. If you wish to use your plugin with multiple languages, then you will need to build multiple plugin libraries and either instruct your users on how to load the correct version or provide a compiler wrapper that does this automatically.
Additionally, on Windows the plugin library has to export the
plugin_is_GPL_compatible
and plugin_init
symbols. If you
do not wish to modify the source code of your plugin, then you can use
the -Wl,--export-all-symbols option or provide a suitable DEF
file. Alternatively, you can export just these two symbols by decorating
them with __declspec(dllexport)
, for example:
#ifdef _WIN32 __declspec(dllexport) #endif int plugin_is_GPL_compatible; #ifdef _WIN32 __declspec(dllexport) #endif int plugin_init (plugin_name_args *, plugin_gcc_version *)
The import libraries are installed into the plugin
directory
and their names are derived by appending the .a
extension to
the backend executable names, for example, cc1.exe.a,
cc1plus.exe.a, etc. The following command line shows how to
build the single source file plugin on Windows to be used with the C++
compiler:
g++ -I`gcc -print-file-name=plugin`/include -shared -Wl,--export-all-symbols \ -o plugin.dll plugin.cc `gcc -print-file-name=plugin`/cc1plus.exe.a
When a plugin needs to use gengtype
, be sure that both
gengtype and gtype.state have the same version as the
GCC for which the plugin is built.