This article might be interesting to someone who writes a plugin software with C/C++ using shared library (dynamic link library) mechanism. But, if you are not, I think this is totally rubbish.
When I develop a plugin, I could compile it and link it, but when I run it, I happen to see an error message, ``no such symbol''. I see the symbol in the executable via nm/dumpbin, but, it is not recognized from the plugin code at runtime.
Why this happens? Because the linker optimizes exposing symbols.
Some of the software needs symbols that are only used by its plugin. When you need to build such software, you need to ask to the linker to keep those symbols. Otherwise linker trashes un-referenced symbols. This is usually useful, otherwise my disk and memory will be filled up by copies of unused symbols.
To ask to the linker that ``please keep unused symbols since I might need them later,'' you need to specify --export-dynamic option (liker option) to the linker. If you use gcc as the linker driver, the option is -Wl,--export-dynamic.
In this way, the executable can have the symbols that are only referred by dlopen-ed code.
This method keeps all the symbols that are exported from the executable, but you can also specify the symbols you want to keep, one by one. This is effective to avoid reverse engineering a bit, since I can control which symbol I want to expose. But, this is a pain for developers and I sometimes envy the freesoftware writers that they do not need to care and manage these cumbersome problem. Sometimes I spent days only for this.
The motivation of writing this article comes from my job task. We also do this. Sometimes our customer complains our library, ``Hey, you don't give us the promised function! Where it is?'' Not only that, I made a bug in a make file, my colleague can not use our software. Sorry, Matthias.
When I develop a plugin, I could compile it and link it, but when I run it, I happen to see an error message, ``no such symbol''. I see the symbol in the executable via nm/dumpbin, but, it is not recognized from the plugin code at runtime.
Why this happens? Because the linker optimizes exposing symbols.
Some of the software needs symbols that are only used by its plugin. When you need to build such software, you need to ask to the linker to keep those symbols. Otherwise linker trashes un-referenced symbols. This is usually useful, otherwise my disk and memory will be filled up by copies of unused symbols.
To ask to the linker that ``please keep unused symbols since I might need them later,'' you need to specify --export-dynamic option (liker option) to the linker. If you use gcc as the linker driver, the option is -Wl,--export-dynamic.
In this way, the executable can have the symbols that are only referred by dlopen-ed code.
This method keeps all the symbols that are exported from the executable, but you can also specify the symbols you want to keep, one by one. This is effective to avoid reverse engineering a bit, since I can control which symbol I want to expose. But, this is a pain for developers and I sometimes envy the freesoftware writers that they do not need to care and manage these cumbersome problem. Sometimes I spent days only for this.
The motivation of writing this article comes from my job task. We also do this. Sometimes our customer complains our library, ``Hey, you don't give us the promised function! Where it is?'' Not only that, I made a bug in a make file, my colleague can not use our software. Sorry, Matthias.
Comments