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

[Erik Joelsson]

Right, explainable differences are fine of course. Thanks for the report!

/Erik


On 2018-03-13 03:27, Magnus Ihse Bursie wrote:
> On 2018-03-12 21:44, Erik Joelsson wrote:
>> Looks good given that the comparison is clean (for the affected libs).
>
> That depends on what you mean as "clean". Of course there is a 
> difference in deps for libsaproc.so on solaris, since we add a new 
> library to link with. As a side effect, the disassembly also changes 
> somewhat.
>
> The "file" command on Windows also reports a difference:
>      other: ./bin/sawindbg.dll: PE32+ executable (DLL) (console) 
> x86-64, for MS Windows
>      this : ./bin/sawindbg.dll: PE32+ executable (DLL) (GUI) x86-64, 
> for MS Windows
> even though the documentation states that the subsystem selected does 
> not matter for DLLs, just executables. (Possibly the PE format stores 
> this information even if it not used, and "file" is not intelligent 
> enough to discard this for DLLs).
>
> Other than that, there are no reported differences.
>
> /Magnus
>>
>> /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
>>>
>>
>