RFR: JDK-8200358 Remove mapfiles for JDK executables

[Magnus Ihse Bursie]

On 2018-04-04 17:25, Erik Joelsson wrote:
>
> On 2018-04-04 00:42, Magnus Ihse Bursie wrote:
>> On 2018-04-03 23:16, Erik Joelsson wrote:
>>> Looks good to me at least. Exporting symbols from executables seems 
>>> wrong so applying hidden as default seems good to me.
>> Unfortunately, it was not this easy. :-(
>>
>> Out of paranoia, I also started a test run on Windows, even though it 
>> should not have been affected. Well, "should not". The added 
>> JNIEXPORT turns into a __declspec(dllexport) on Windows, which causes 
>> the Microsoft linker to behave like when linking a dll, so it creates 
>> a .lib and .exp for each binary, in the bin directory.
>>
>> *sigh*
>>
>> I see two ways out of this.
>>
>> 1) Make the JNIEXPORT conditional on OS. Either by #ifdef before the 
>> main function, or by declaring something like EXEC_EXPORT instead, 
>> and let it be empty on Windows.
>>
>> 2) Let the part of SetupNativeCompilation that handles executables 
>> behave more like the one for shared libraries, and setting -implib, 
>> etc. I'm not sure what happens if you pass in -implib when linking an 
>> executable which does *not* have any dllexport decorations. If it 
>> breaks, then this does not really seem like a way forward. Otherwise, 
>> it's probably the safest choice, since it will make sure we never 
>> leak any *.lib or *.exp for a potential future executable.
>>
>> What do you think?
>>
> I really don't know which I would prefer. Would be good to find out 
> what happens in 2.

Turns out that -implib is just ignored if not needed, so 2 is clearly 
the way to go.

This also meant that there was much overlap between the linking of 
shared libraries and executables in SetupNativeCompilation, so I 
(finally) took the time to unify them.

Updated webrev: 
http://cr.openjdk.java.net/~ihse/JDK-8200358-remove-launcher-mapfiles/webrev.03
(Only changes NativeCompilation.gmk)

/Magnus


>
> /Erik