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
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.
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.