RFR: JDK-8199483 Clean up some non-standard LDFLAGS usage

[Erik Joelsson]

Looks good given that the comparison is clean (for the affected libs).

/Erik


On 2018-03-12 13:03, Magnus Ihse Bursie wrote:
> We have a few libraries that, for one reason or another, use 
> non-standard LDFLAGS. There is typically no good reason for this, just 
> historical accidents.
>
> This patch fixes several places to remove odd or unneeded LDFLAGS, and 
> to make them conform better to the prevailing standard. This will 
> facilitate even more future cleanups in this area.
>
> We still have some "snowflakes" left that have tricky LDFLAGS, but 
> they require more research to figure out the best way to handle.
>
> Some comments on the changes:
> * -machine is not needed, it is autodetected by the linker.
> * -subsystem:* has no meaning for dlls (and "windows" is default anyway)
> * -map is always provided by SetupNativeCompilation
> * -SAFESEH is provided by LDFLAGS_JDKLIB.
> * The unknown symbols from libsaproc on Solaris was due to the missing 
> link with libproc.
> * In Windows DEF files, the HEAPSIZE command is equivalent to 
> -heap:<nn>. But this is ignored for dlls. (We should not have any 
> linker commands except EXPORTS in def files).
>
> I'm running a COMPARE_BUILD set (it's 3/4 finished by now), to verify 
> that there is no significant differences.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8199483
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8199483-simplify-LDFLAGS/webrev.01
>
> /Magnus
>