This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: shared library - undefined symbols

Dan O'Brien wrote:

> g++ -o build/unknown-pc-cygwin/debug/ -shared -Wl,--allow-shlib-undefined build/unknown-pc-cygwin/debug/.objs/plugin.o build/unknown-pc-cygwin/debug/.objs/NullFilter.o build/unknown-pc-cygwin/debug/.objs/NullFilterFactory.o

First of all, get rid of -Wl,--allow-shlib-undefined.  There is nothing
you can tell the linker that will change the fact that on PE systems,
all symbols must be defined at link-time, i.e. there can be no undefined
symbols in shared libraries.  This is not something that is up to the
linker, it's a basic fundamental property of the platform that we can't

Is is possible to import symbols from the main .exe from a plugin, but
it requires that you declare them dllexport in the main .exe, and it
requires that you create an import lib for the main .exe, which you can
do during its link with -Wl,-out-implib,libgpm.a.  Then add -lgpm to the
link of the plugin.

This should work, but it's sometimes considered rather ugly because it
hardcodes the name of the executable into the plugin, just as if gpm.exe
was a regular library.  Thus the plugin cannot be used in a general
manner with any other .exe, and will fail to load if the .exe was

The standard workaround for this is to move the symbols into their own
common .dll and import them from both the main .exe and from the module.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]