31b8154266
For now I've been editing the Makefile directly and haven't updated the Makefile.in. Once it works I'll transfer everything to Makefile.in and remove Makefile.
28 lines
1.4 KiB
Plaintext
28 lines
1.4 KiB
Plaintext
test6-execsymbols2
|
|
|
|
Try again to allow the module to reference symbols in the executable.
|
|
But this time, eliminate direct symbol references from the executable
|
|
to the module, so that the executable can be linked first. I believe
|
|
this will work ok for win32 and it's closer to how plugins need to work.
|
|
|
|
What I think I learned from test5:
|
|
> DLLs don't allow any symbols to be undefined at link time. So you have to
|
|
> choose the order of how to build things so that each link is complete.
|
|
> For a DLL that's used as a shared library, it must be built and linked on
|
|
> its own (without the program), with symbols exported. This link must be
|
|
> complete, so it can't depend on pieces from the program. Then, the
|
|
> program can be linked with the DLL, with the program reading symbols from
|
|
> the DLL. It can't go both ways.
|
|
>
|
|
> For a plugin environment, we want the plugin to be able to call functions
|
|
> in the main code, without putting every single thing as a function pointer.
|
|
> So the main executable should be built first, with appropriate symbols
|
|
> exported, and then the plugin can import those symbols. The main
|
|
> executable will find symbols in the DLL using lt_dlopen() and lt_dlsym(),
|
|
> which probably maps to LoadLibrary() and GetProcAddress().
|
|
|
|
|
|
module1.lo: In function `module_init(void)':
|
|
/home/bryce/bochs-testing/plugin-test/test6-execsymbols2/module1.cc:7: undefined reference to `import stub for register_module(char const *)'
|
|
|