R: R: R: Plugin development under windows

Pedro Alves pedro@palves.net
Wed Mar 29 10:37:00 GMT 2017

On 03/29/2017 08:30 AM, Davide Piombo wrote:
> Hi Trevor, thanks for your hint.
> Yesterday I made some other tests. I tried to use CygWin instead of
> MinGW and the POSIX missing references are now solved. Now the error
> have moved from the compiler to the linker and the build stops
> because of undefined references. The missing symbols are included in
> GCC executable and are declared as external symbols in GCC plugin
> header files.

Declared as external is not sufficient.  They also need to be
declared as exported in PE terms.

Usually, you do that by tagging exported symbols
with __declspec(dllexport) at the time the exe is built, and tagging
them as __declspec(dllimport) when the plugin is built.

I.e., you'd apply the guidelines described at:


to GCC itself.  E.g., add a macro like the DLL_PUBLIC described
there, something around:

#if defined _WIN32 || defined __CYGWIN__
#   define GCC_PUBLIC __declspec(dllexport)
# else
#   define GCC_PUBLIC __declspec(dllimport)
# endif
# define GCC_PUBLIC

And add GCC_PUBLIC to symbols that should be exported to plugins.

AFAIK, in plugin architectures on Windows, it's more common to
split the bulk of an exe to a dll that is then linked by both
a "shim" exe and the plugins, but exporting symbols from EXEs
should work fine too.  See e.g.,:


The key search terms are "plugins on windows export exe symbols".

My Windows knowledge has been steadily fading over the years, and I'm
not sure whether GCC export all symbols automatically using "-fvisibility"
on Windows (as workaround) of whether you really need to go
the __declspec or dllexport routes.

Also, see:


maybe you can also workaround it by using LD's --export-all.

This should give you some pointers to experiment.

> Anyway, before to change the compiler or library version I tried to
> dump symbols from libgcc.a in order to understand if missing symbols
> are really in this library and they are not there.

libgcc.a is not GCC itself.  See:


Pedro Alves

More information about the Gcc mailing list