Howto re-compile ony parts?

[Kelly O'Hair]

Yes, Windows defaults it's DLL symbols to be private, you must explicitly
'export' them with statements in the source, or using the command line
'export' options.

With Solaris/Linux and the Elf binary file format, there are two symbol
tables in the .so library, the normal symbol table section .symtab and the
dynamic symbol table .dynsym used at runtime. By default all extern symbols or
GLOBAL symbols will be in both, opening up the door for anyone to find or
use any symbol. The mapfile manipulates what goes into what symbol table
and also can control what goes into other runtime Elf sections of a .so
or a.out file. On Solaris, mapfiles are required to limit the list of
extern symbols to just those that are publicly documented/supported and
also 'version' the library.
Linux may call these mapfiles 'version scripts'.

Note that a .symtab is needed at runtime, and if you 'strip' your .so file
the .symtab is removed and your .so is much smaller, only the .dynsym
sections is needed at runtime. However, not having a .symtab makes debugging
and stack traces pretty useless.

-kto


Phil Race wrote:
> Igor Nekrestyanov wrote:
>> Thanks Phil!
>>
>> I just found similar explanation in the jdk\make\common\Makefile-vers.gmk
>> ....
> 
>> However, it seems to be used on Linux/Solaris only (everything inside 
>> is under ifder solaris/linux) and this puzzle me a bit.
>> So, it seems if name clashing is primary reason we should be 
>> protecting from this on Windows too.
>>
>> -
> I believe its the default behaviour on windows to not export symbols. So 
> this isn't needed and the
> magic "JNIEXPORT <rtn type> JNICALL" at the top of each of the JNI fn 
> declarations expands
> into what is needed to force the export :
> jni_md.h:#define JNIEXPORT __declspec(dllexport)
> 
> -phil.
>