RFR: JDK-8200358 Remove mapfiles for JDK executables (original) (raw)
Erik Joelsson erik.joelsson at oracle.com
Wed Apr 4 15:25:30 UTC 2018
- Previous message (by thread): RFR: JDK-8200358 Remove mapfiles for JDK executables
- Next message (by thread): RFR: JDK-8200358 Remove mapfiles for JDK executables
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 EXECEXPORT 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.
/Erik
- Previous message (by thread): RFR: JDK-8200358 Remove mapfiles for JDK executables
- Next message (by thread): RFR: JDK-8200358 Remove mapfiles for JDK executables
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]