I wondered if that might be the case since it was a "BSD" port .. using
X11 ..
Maybe we should be getting rid of them ?
-phil.
On 03/15/2018 10:21 AM, Erik Joelsson wrote:
Digging a bit, those files came with the initial Macosx support. It
doesn't look like they were ever used.
/Erik
On 2018-03-15 09:53, Phil Race wrote:
It is very hard to follow all the moved around files, but one thing
that sticks out is there is a "bsd" directory created and I can't
work out how the files in there are used.
If they are for a BSD port of OpenJDK where is rest of the support
for that ?
On 03/15/2018 07:20 AM, Erik Joelsson wrote:
Looks good to me. I tried cleaning this up before but failed to find
a reasonable split, but this seems like a good split between common
and library specific.
/Erik
On 2018-03-14 18:12, Magnus Ihse Bursie wrote:
I forgot to add the client mailing lists as recipients. Sorry. (Not
sure if "sounds" belong to "awt" or "2d".)
In fact, there is a sound-specific list, which I've added.
-phil.
/Magnus
On 2018-03-15 02:07, Magnus Ihse Bursie wrote:
From the bug description:
Moving this to a separate bug from JDK-8055190. In
SoundLibraries.gmk, the source code splitting is not complete. The
directory libjsound is used to build not only libjsound but
libjsoundalsa and libjsoundds, and thus needs a complex
include/exclude system like before.
I have tested this using COMPARE_BUILD. Windows and solaris are
completely clean. On macosx, there's a binary diff (but nothing
else) on libjsound.dylib. On linux, some offset seems to have
changed, which caused a slight change in disass and fulldump for
libjsound.so. I'm not quite sure what's causing it, but I'm
convinced it's harmless.
Bug: https://bugs.openjdk.java.net/browse/JDK-8071469
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8071469-cleanup-sound-libs/webrev.01
/Magnus
