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: https://gcc.gnu.org/wiki/Visibility to GCC itself. E.g., add a macro like the DLL_PUBLIC described there, something around: #if defined _WIN32 || defined __CYGWIN__ # ifdef BUILDING_GCC # define GCC_PUBLIC __declspec(dllexport) # else # define GCC_PUBLIC __declspec(dllimport) # endif #else # define GCC_PUBLIC #endif 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.,: http://stackoverflow.com/questions/3752634/dll-get-symbols-from-its-parent-loader/3756083#3756083 http://stackoverflow.com/questions/15454968/dll-plugin-that-uses-functions-defined-in-the-main-executable 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: https://gcc.gnu.org/onlinedocs/gcc/Microsoft-Windows-Function-Attributes.html 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: https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html Thanks, Pedro Alves