http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54069
Bug #: 54069
Summary: linkage type of plugin API wrong
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: plugins
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wein...@gns-mbh.com
Created attachment 27856
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27856
plugin source
gcc 4.7.0 and 4.7.1
created with:
./configure --prefix=/usr/local --program-suffix=-4.7.1 --with-mpc=/usr/local
--with-mpfr=/usr/local --with-gmp=/usr/local --enable-serial-configure
--enable-languages=c,c++,fortran,objc,obj-c++
plugin (see attached source) compiled with:
gcc-4.7.1 -I`gcc -print-file-name=plugin`/include -fPIC -shared -O2 plugin.c -o
plugin.so
try to use with:
gcc-4.7.1 -fplugin=./plugin.so test.c
where test.c is simply:
int main(int argc, char *argv[]) { return 0; }
or may be any other source, doesn't matter, the test plugin does nothing...
generates following error lines:
cc1: error: cannot load plugin ./plugin.so
./plugin.so: undefined symbol: list_length
Looking at the generated compiler (libgcc, gcc-executable, etc.) it seems that
presumably all functions from tree.h, input.h, and many others seem to have
C++-linkage though they are part of a C-API. Using
#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */
.... declarations ....
#ifdef __cplusplus
} /* extern "C" */
#endif /* __cplusplus */
in those headers cures the problem (after long recompile)...
the function used in the plugin is only example, there are tons(!!) of others
there that have the same problem..
it would be great if you could restore ability to use C for the plugin-API..
thanks...
