RFR: JDK-8199682 Clean up building the saproc library

[David Holmes]

On 16/03/2018 9:49 PM, Magnus Ihse Bursie wrote:
> On 2018-03-16 04:13, David Holmes wrote:
>> Hi Magnus,
>>
>> Overall this seems okay.
> Thanks!
> 
>>
>> On 16/03/2018 4:22 AM, Magnus Ihse Bursie wrote:
>>> The saproc library has historically been built in quite odd ways on 
>>> almost all platforms. When the old build system was converted, this 
>>> was not changed.
>>>
>>> However, now the time has come to streamline this and build this 
>>> library just as any other.
>>>
>>> The most visible change, perhaps, is that the library is now named 
>>> saproc on all platforms, even Windows. Other changes include:
>>
>> That could have repercussions elsewhere. sawindbg.dll is probably a 
>> well known name for deployment systems.
> You mean other classes than WindbgDebuggerLocal.java, out in the wild, 
> might load sawindbg.dll directly and call into it? If they do so, they 
> must also be prepared that this is not an exported interface and can 
> change at any time.

No I mean deployment systems, like an upstream RPM manager, or Oracle's 
own installer process, may know the name of the file and have to be 
modified if the name changes.

Though as Sundar said "proc" isn't really the right name.

David
-----

>>
>>> * Don't set flags that is already set by the default flags.
>>> * Don't set flags that do not have anny effect.
>>> * Don't subst away the WIN32_LEAN_AND_MEAN definition, it's perfectly 
>>> okay to have it.
>>> * Don't set CXX linker on solaris -- this was not needed so no reason 
>>> to do it.
>>> * Cleaned up some old hooks for closed code that is no longer needed.
>>
>> Right - we could have deleted that when our ARM ports went open.
>>
>>> I have verified this using COMPARE_BUILD. This shows only the 
>>> expected differences:
>>> * On all platforms: class file changes for WindbgDebuggerLocal.java.
>>> * On solaris: some minor symbol differences, since the linker now 
>>> uses C framework functions instead of C++. (And with symbol changes 
>>> always comes disasm changes.)
>>> * On linux: a binary difference for libsaproc.so, but no 
>>> size/symbol/deps/disasm change.
>>> * On macosx: no changes at all.
>>> * On windows: sawindbg.dll is renamed to saproc.dll. When I made a 
>>> manual comparison between the two files, I found no significant 
>>> differences.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199682
>>> WebRev: 
>>> http://cr.openjdk.java.net/~ihse/JDK-8199682-clean-up-saproc/webrev.01
>>
>> The deleted OSX files seem okay. This just seems like another case 
>> where the original port copied every Linux file across to the bsd 
>> directory.
>>
>> Not sure about the Solaris saproc_audit.cpp or the test.c files ??
> I don't know either. :) As I said to Erik, the test files looked like 
> stupid adhoc testing just left in place. The saproc_audit.cpp looks 
> legit, but has not been compiled for years. Someone must have "removed" 
> the file by excluding it from compilation, rather than deleting it. 
> Could have happened back in the bad old days when "solaris" didn't mean 
> solaris but "unix", and nobody understood the consequences of deleting 
> files there.
> 
> As always, the file is still in the repository, if someone wants to 
> revive it.
> 
> /Magnus
> 
>>
>> Thanks,
>> David
>>
>>> /Magnus
>>>
>