On 2018-09-13 21:59, Erik Joelsson wrote:
On 2018-09-13 12:21, Magnus Ihse Bursie wrote:
On 2018-09-13 19:58, Erik Joelsson wrote:
I believe it's because they are C++ instead of pure C. We always had
a harder time comparing C++ binaries.
Hm, is that so? You mean as in linking using TOOLCHAIN_LINK_CXX?
More because there are C++ source files in them, .cpp in libsaproc and
.cc in libfontmanager.
I was just about to argue that we have lots of other libraries with C++
source files in them, but when I checked I noticed that they coincided
quite well with the libraries that has caused us most issues in the
comparisons. Hm. I've never noticed that pattern before. Interesting.
/Magnus
/Erik
I'm just a bit "allergic" towards libfontmanager. There's a lot of
odd things happening there; it's one of our most atypical libraries.
Loads of disabled warnings. Some of them might warn about code that
could cause this unstableness.
I plan to look more closely into libfontmanager in the
hopefully-not-too-long-term future.
/Magnus
/Erik
On 2018-09-13 10:48, Phil Race wrote:
Ditto, although as the "owner" of libfontmanager I am curious what
are the rare characteristics that make just these two libraries
"unstable" in this sense ?
-phil.
On 09/13/2018 10:24 AM, Erik Joelsson wrote:
Looks good.
/Erik
On 2018-09-13 02:23, Magnus Ihse Bursie wrote:
We regularly use the COMPARE_BUILD framework to test build
reproducability, by comparing two builds made directly after one
another. This test currently fails on solaris, since the
compilation of libfontmanager and libsaproc is not stable (and
thus can produce different disassembly each build).
This patch adds an exception for these libraries. (Note that one
of them was already on the exception list, but only on slowdebug
builds).
Ideally, we'd rather hunt down the problems with reproducability,
but that's a loooong term project.
Bug: https://bugs.openjdk.java.net/browse/JDK-8207264
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8207264-solaris-compare-build-fails/webrev.01
/Magnus
