Howto re-compile ony parts?

[Kelly O'Hair]

Kelly O'Hair wrote:
> 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
                         ^^^^^^^ NOT needed

:^{

-kto

> 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.
>>