This looks good, hopefully for the last time. :)
Thanks for hanging in there!
/Erik
On 2018-04-05 02:16, Magnus Ihse Bursie wrote:
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
