42 lines
1.6 KiB
Plaintext
42 lines
1.6 KiB
Plaintext
test5-execsymbols
|
|
|
|
Can a module reference symbols in the executable?
|
|
|
|
module1 exports module_name and operate(int,int).
|
|
module2 exports n_operations and operation_occurred().
|
|
|
|
uselib.cc uses symbols and functions from both modules.
|
|
Module1 calls operation_occurred() in module2.
|
|
|
|
Module2 calls register_module() in uselib.cc the first time
|
|
it is called.
|
|
|
|
Results:
|
|
redhat linux: works fine.
|
|
solaris: works fine.
|
|
macosX: works fine.
|
|
cygwin:
|
|
when building a DLL you cannot have undefined symbols at link time.
|
|
You have to put -no-undefined on the command line, but whether you
|
|
do or not, you get undefined symbol register_module when you try to
|
|
link module2.
|
|
|
|
test5-execsymbols/module2.cc:11: undefined reference to `register_module(char const *)'
|
|
|
|
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().
|
|
|
|
I will try this in test 6!
|