你可能想看看--export-dynamic
ld的選項:
-E
--export-dynamic
--no-export-dynamic
When creating a dynamically linked executable, using the -E option
or the --export-dynamic option causes the linker to add all symbols
to the dynamic symbol table. The dynamic symbol table is the set
of symbols which are visible from dynamic objects at run time.
If you do not use either of these options (or use the
--no-export-dynamic option to restore the default behavior), the
dynamic symbol table will normally contain only those symbols which
are referenced by some dynamic object mentioned in the link.
If you use "dlopen" to load a dynamic object which needs to refer
back to the symbols defined by the program, rather than some other
dynamic object, then you will probably need to use this option when
linking the program itself.
You can also use the dynamic list to control what symbols should be
added to the dynamic symbol table if the output format supports it.
See the description of --dynamic-list.
Note that this option is specific to ELF targeted ports. PE
targets support a similar function to export all symbols from a DLL
or EXE; see the description of --export-all-symbols below.
另外,如果沒有鏈接中的對象是指你的外部符號,你可能想將其付諸--dynamic-list
使肯定他們出口。
例子:
$ cat test.cc
#include <stdio.h>
int main() {
printf("Hello, world\n");
}
extern "C" void export_this() {
printf("Hello, world from export_this\n");
}
$ g++ -o test -W{all,extra} -Wl,--export-dynamic test.cc
$ ./test
Hello, world
$ nm --dynamic test | grep export_this
00000000004007f5 T export_this # <---- here you go
所以,你想用你的可執行文件太共享庫?通常情況下,構建一個由多個應用程序使用的共享庫是通常的方法。 – 2014-10-10 08:23:05
編輯的迴應:是的,它幾乎說我的評論說同樣的事情:要麼使用共同的共享庫,要麼不使用'dlopen'和'dlsym' ... – 2014-10-10 08:25:08
是的......所以,奇怪:我在程序中嵌入了一個Java VM,它使用JNA/dlopen/dlsym來訪問extern C函數。最好將所有內容保存在一個可執行文件中,這樣我就不需要在開發過程中混淆鏈接器路徑。如果我非常*有*做共享庫,那麼,meh,'凱... – user 2014-10-10 08:28:49