I agree with what Erik said on build-dev that being specific about the
tool chain
and the reason are worthwhile and important. We've done that in similar
cases.
Also these review threads usually should have a subject like
RFR: :
which means you first need a bug id .. the patch can't be
Try again with build-dev cc'd ..
-phil.
On 01/18/2018 11:14 AM, Phil Race wrote:
I agree with what Erik said on build-dev that being specific about the
tool chain
and the reason are worthwhile and important. We've done that in
similar cases.
Also these review threads usually should have
+1
-phil.
On 12/04/2017 02:18 AM, Magnus Ihse Bursie wrote:
By oversight, when the external fontconfig was introduced in
JDK-8170681, spec.gmk.in was not updated to actually include
FONTCONFIG_CFLAGS (but it was properly exported from lib-fontconfig.m4
and included in the AWT makefile).
I see this opens was moved to platform-specific code ... 115 opens
com.sun.java.swing.plaf.windows to
116 jdk.jconsole;
So jdk.jconsole definitely accesses this only on Windows ?
-phil.
On 11/28/2017 09:28 AM, Erik Joelsson wrote:
From a build point of view, this looks great.
/Erik
On
Updated webrev posted as http://cr.openjdk.java.net/~prr/8170681.1
-phil.
On 10/25/2017 01:04 AM, Erik Joelsson wrote:
Hello,
Expanding the help as Sergey suggests is a good idea. The package on
Ubuntu is called libfontconfig1-dev and on Redhat fontconfig-devel.
In lib-fontconfig.m4, line
I've looked at the code and tested this too .. looks good.
Thanks,
-phil.
On 10/23/2017 07:39 AM, Erik Joelsson wrote:
This patch adds building of a new test bundle containing just the
remaining demos, which are used for client testing. It's basically
resurrecting the build logic for the old
+1
-phil.
On 07/20/2017 01:45 AM, Prasanta Sadhukhan wrote:
Hi All,
This is a back-out of 6461834: Minimize WindowsLookAndFeel classes
included with Unix JDKs
fix which was done to make sure WindowsLookAndFeel classes are not
built for non-windows platform
but it seems there are some
The way to do this is to create a file
src/java.desktop/windows/classes/module-info.java.extra
and move the opens there.
See for example
src/java.base/windows/classes/module-info.java.extra
But are you sure jdk.jconsole needs these only on Windows ?
Better make sure of it.
-phil.
On
And to be clear, the provision for still building these client demos
needs to be made BEFORE this is pushed.
Or at least as *part* of this push.
Else we will be unable to perform our normal integration testing at this
critical juncture of JDK 9 ..
-phil.
On 03/03/2017 09:39 AM, Phil Race
What is the plan for ensuring there is still a way to build the client
demos - which are not being removed
but just moved. Doesn't this makefile need to be somewhere still ?
-phil.
On 3/3/2017 12:18 AM, Magnus Ihse Bursie wrote:
On 2017-03-02 20:33, Alexandre (Shura) Iline wrote:
Hi,
Could
A complete stab in the dark, but did you install the xcode command line
tools ?
-phil.
On 12/15/2016 07:24 AM, Martijn Verburg wrote:
Hi Erik,
Thanks, that's fine. As an FYI I swapped to using gcc and g++ compilers but
still get the same error so more digging is required, will update here
On 12/15/2016 05:16 AM, Artur Rataj wrote:
By the way, are you shure that 2d-dev is the correct mailing list?
yes it is.
Isn't
Java2D rendering the glyph data as any other shape, i.e. a font rasterizer
is not used?
wrong. Java 2D uses a font rasteriser.
Anyway, it seems that OpenJDK for
+1.
I am assuming you made sure AccessBridgeCalls.c is not being compiled
during the JDK build as discussed earlier ...
-phil.
On 10/31/2016 07:36 AM, Pete Brunet wrote:
On 10/28/16 8:14 PM, Mandy Chung wrote:
On Oct 28, 2016, at 1:59 PM, Philip Race wrote:
If it
On 10/27/2016 11:52 AM, Pete Brunet wrote:
On 10/27/16 1:47 PM, Pete Brunet wrote:
On 10/27/16 1:34 PM, Phil Race wrote:
In which case be careful it is not built by the JDK build ..
Build team, Is there anything I need to handle here to make sure it isn't?
Actually, let me give it a try. I
In which case be careful it is not built by the JDK build ..
unless that is actually required .. which I didn't think it was.
-phil.
On 10/27/2016 11:30 AM, Mandy Chung wrote:
Please move AccessBridgeCalls.c to src/jdk.accessibility/windows/native/bridge
directory.
No, we are definitely shipping those.
Unless of course you think we should stop shipping JNI headers too ...
-phil
On 10/27/2016 10:37 AM, Mandy Chung wrote:
Should they be kept just in the source and not to be included in the
image/include directory?
It’s not clear to me if anyone needs
This all seems fine.
Do other accessbridge files still have the remnants of SCCS ? :-
That was purged from all the other JDK files when we moved to mercurial.
33 /*
34 * @(#)AccessBridgeCalls.c 1.25 05/08/22
35 */
If "yes", then I suggest to file a clean-up bug to clean up all of
One big problem I see with this is that it means they will only be
available under the GPL license
as they will not be in an Oracle JDK which strips the GPL
So if you are going to do this then these files first need to be
dual-licensed
because otherwise people can't link their commercial
On 08/23/2016 08:47 AM, Erik Joelsson wrote:
> Hello,
>
> I do agree that maintaining the list of disabled warnings will be
> impossible unless we have a structured way of tracking for which
> compiler versions we disable what. Ideally we should be able to easily
> add conditions for when certain
rds,
Ajit
-Original Message-
From: Phil Race
Sent: Wednesday, July 06, 2016 2:02 AM
To: Ajit Ghaisas
Cc: Sergey Bylokhov; Erik Joelsson; 2d-dev; awt-...@openjdk.java.net;
build-dev@openjdk.java.net
Subject: Re: [9] Fix for JDK-8074824: Resolve disabled warnings for
libawt_x
I expect this is the SDK version you are using more than the OS version.
10.9 is the supported SDK.
Any changes to this particular code should be discussed on
2d-...@openjdk.java.net
since they would not be build changes
But that might not be sufficient .. you could encounter other issues
It is not always clear to me what warning is being suppressed and why you have
chosen a particular solution/action
this next one looks like it might introduce an unused variable warning.
What was it solving ? That the code was not checking a return value ?
size_t bytesWritten = write (
-Phil.
> On Jul 3, 2016, at 4:55 PM, Phil Race <philip.r...@oracle.com> wrote:
>
> It is it all "extensions".
That should have read :
It is "not" all ...
- Phil
> It is mostly just different internal code as far as we (se client) are
> con
It is it all "extensions". It is mostly just different internal code as far as
we (se client) are concerned so the word extension has entirely the wrong
connotation for people in SE api land.
-Phil.
> On Jul 3, 2016, at 4:01 PM, David Holmes wrote:
>
> Hi Erik,
>
>>
erik,
SUPPRESS_CUSTOM_SOURCE"
FWIW "CLOSED" implies better to me what this is about than "CUSTOM".
Can't this be SUPPRESS_CLOSED_SOURCE ?
http://cr.openjdk.java.net/~erikj/8003593/webrev.01/jdk/make/mapfiles/libfontmanager/mapfile-vers.sdiff.html
Regarding all the freetype symbols in here ..
://cr.openjdk.java.net/~aghaisas/8074829/webrev.01/
The changes are exactly the same between webrev.00 & webrev.01.
Request you to kindly review and approve again.
Regards,
Ajit
-Original Message-
From: Phil Race
Sent: Tuesday, May 31, 2016 10:05 PM
To: Ajit Ghaisas
Cc: Sergey Bylokhov; 2d
-Original Message-
From: Phil Race
Sent: Friday, April 22, 2016 1:43 AM
To: Ajit Ghaisas
Cc: Sergey Bylokhov; 2d-dev; build-dev@openjdk.java.net
Subject: Re: Fix for JDK-8074829 : Resolve disabled warnings for
libawt_headless
> Another solution is to exclude this file from HEADLESS compilat
+1
-phil.
On 05/12/2016 11:02 AM, Tim Bell wrote:
Erik:
Looks good to me as well.
/Tim
On 05/12/16 04:06, Erik Joelsson wrote:
Good point, the quotes are certainly not necessary. Removed and
updated review in place. Verified that it still works.
/Erik
On 2016-05-12 12:49, Vadim
The usual one --disable-warnings-as-errors when running configure.
-phil.
On 05/09/2016 01:11 PM, Pete Brunet wrote:
Thanks Phil, I asked in the bug but will ask here too - is there a
workaround until the issue is resolved? In my case I have 6.2 and 7.3.1.
Pete
On 5/9/16 2:29 PM, Phil Race
https://bugs.openjdk.java.net/browse/JDK-8152856
-phil.
On 05/09/2016 12:20 PM, Pete Brunet wrote:
Am running into a build problem on Mac.
Creating libjvm.dylib from 771 file(s)
In file included from
> Another solution is to exclude this file from HEADLESS compilation.
> I am not sure how to achieve it. Any suggestion?
I suppose that is possible and I expect we can do that
See in the make file, where I think you just need to add entries to
LIBAWT_HEADLESS_EXCLUDES := medialib
although
This is bug https://bugs.openjdk.java.net/browse/JDK-8134884
I am not sure about the bit where refreshing your repo triggered it since
I don't think the source code changed recently, so perhaps something
in your installed tool chain changed recently since it reads to me like
a particular
Sorry, no we don't want this patch.
We are not fixing warnings in upstream libraries.
-phil.
On 04/01/2016 03:57 AM, prasanta sadhukhan wrote:
Hi All,
Please review a fix to remove the disabled warnings from lcms library
Bug: https://bugs.openjdk.java.net/browse/JDK-8074826
webrev:
Hi,
First, this is the wrong list entirely - this is list is about how to
build openjdk from source,
and all lists on this site are about source development so this is the
one -and-only reply on this list.
If you really need to follow up go to 2d-...@openjdk.java.net which
superseded
a
+1
-phil.
On 02/15/2016 01:02 AM, Erik Joelsson wrote:
Looks good.
/Erik
On 2016-02-12 10:15, Seán Coffey wrote:
Approved for jdk8u-dev once you have a peer code review.
Regards,
Sean.
On 12/02/2016 08:19, Alexey Ivanov wrote:
I forgot to add jdk8u-dev list...
On 11.02.2016 17:19, Alexey
On 03/07/2016 08:11 AM, Hendrik Schreiber wrote:
- System Setup: freetype is listed as a requirement for Linux and Solaris. But
not for Windows.
I don't think that is completely accurate. There is some additional mention
in Unix sections regarding what to install to make your life easier,
Ideally hotspot would review this, not build.
so it would be helpful if hotspot found an engineer to own the bug :-
https://bugs.openjdk.java.net/browse/JDK-8138820
So far as I know this is not tracked under any other bug id.
-phil.
On 10/06/2015 05:30 AM, Jim Laskey (Oracle) wrote:
I’ve
Because lots of people do not yet have VS2013.
The official compilers are not the only ones we should support.
They are just the ones RE uses.
I would call this a "must fix".
-phil.
On 09/29/2015 08:12 AM, Thomas Stüfe wrote:
Ok, I did not check this. Nevermind, then.
Kind Regards, Thomas
Approved.
-phil.
On 09/25/2015 10:07 AM, Sergey Bylokhov wrote:
Hi, Phil.
Here is an updated version:
http://cr.openjdk.java.net/~serb/8079965/webrev.02
The CPrinterJob.m is changed only. jprt build passed. But I cannot
verify osx 10.8, I have not it.
On 25.09.15 1:57, Phil Race wrote
On 9/24/2015 1:05 PM, Sergey Bylokhov wrote:
On 23.09.15 23:58, Phil Race wrote:
IMO we should support building JDK on as many platforms as possible.
Not just the RE-blessed platform of the day which can change more often
than I can - or want to - update my systems as I need to build multiple
the types in CPrinterJob [1] via ifdef, but actually
do we support sdk 10.8 in jdk9?
[1]
http://cr.openjdk.java.net/~serb/8079965/webrev.01/src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m.sdiff.html
On 23.09.15 23:34, Phil Race wrote:
This looks OK except that I have
This looks OK except that I have a suggestion with regards to Apple's
(gratuitous!) enum change
OpenOffice solved this with an ifdef
https://svn.apache.org/viewvc/openoffice/trunk/main/vcl/aqua/source/gdi/salprn.cxx?r1=1591062=1633297=1633297
--
Pete,
The windows installer is not part of OpenJDK so you should redirect this
question to a different list.
-phil.
On 09/01/2015 10:02 AM, Pete Brunet wrote:
Hi, How do I make an install image (not just the binary trees I see with
make images)? I need to do a 32 bit build on 64 bit W7 and
The problem with this specific warning is it is in a 3rd party library.
I generally opt for just disabling those until upstream resolves it.
-phil.
On 09/01/2015 09:46 AM, David DeHaven wrote:
and now get the warnings:
-
Compiling 13 files for jdk.policytool
clang: error: unknown
snapshot.
[1] http://openjdk.java.net/projects/jdk8u/releases/8u66.html
Regards,
Sean.
On 21/07/2015 20:11, Phil Race wrote:
Bug : https://bugs.openjdk.java.net/browse/JDK-8130938
8071710 fixed the issue of libfontmanager and libt2k linking against
X11 on JDK 9 for Solaris.
This was subsequently
Bug : https://bugs.openjdk.java.net/browse/JDK-8130938
8071710 fixed the issue of libfontmanager and libt2k linking against X11
on JDK 9 for Solaris.
This was subsequently backported to JDK8u but one line was missed so
incorrectly libt2k
still depends on X11 libraries on 8u.
This is a
On 06/05/2015 07:30 AM, Tim Bell wrote:
Hi
I would not recommend copying files off some other system.
The last time I started with a brand-new minimal Solaris 11.x install,
I needed to add:
sudo pkg install gnu-tar system/header system/picl x11/library/libx11
x11/library/libxrender
E_STATEMENT_NOT_REACHED is a favourite of SunStudio and
I recently fixed one such warning (in closed code so I can't point to it
here)
but I did not see this one .. however I was using jprt and locally
Solaris 10 SPARC. So perhaps it is something to do with the headers ?
Ironically the warning
Looks OK to me. I've added 2d-dev (owner of the lib).
I don't think this will cause any issue for closed builds but we'll
address it if it does.
-phil.
On 5/28/15 7:25 PM, Andrew Hughes wrote:
- Original Message -
Bug: https://bugs.openjdk.java.net/browse/JDK-8081447
Webrev:
+1
-phil.
On 05/21/2015 12:11 AM, Erik Joelsson wrote:
Hello Pete,
This looks good to me.
/Erik
On 2015-05-21 07:33, Pete Brunet wrote:
Please review the following change for 8u:
http://cr.openjdk.java.net/~ptbrunet/JDK-8077296/webrev.00/
Background:
- As part of the open sourcing of the
Perhaps JAWS is not well behaved w.r.t multiple DLL versions ?
Does it happen only on win 8 ? If you boot the same system into win 8 or
win 8.1 is it OK ?
What do you see logged by hotspot from typing Ctrl-Break in the shell ?
Other than that, debugging is very likely going to require you
What makes java.xml.bind so special that make 3.81 should barf on it,
but no other modules?
Nothing that I can see. Its very strange.
-phil.
On 04/16/2015 02:02 AM, Magnus Ihse Bursie wrote:
On 2015-04-15 01:44, David Katleman wrote:
We went through this exercise in January.
RE
, JDK-8072023
https://bugs.openjdk.java.net/browse/JDK-8072023.
Until we update gnumake for windows (JDK-8072023
https://bugs.openjdk.java.net/browse/JDK-8072023), issues like what
Phil found with gnumake 3.81 should be fixed.
Thanks
Dave
On 4/14/2015 3:42 PM, Phil Race wrote
in the
same error I reported in my initial email.
Exactly how did you run make to have this happen?
I typed make :-). Running in a cygwin shell that is inside a cmd.exe
shell (not a cygwin window).
Same as I have always done.
-phil.
/Erik
On 2015-04-11 00:39, Phil Race wrote:
For some
of
cygwin make (3.81).
Updating my path to pick up a newer cygwin version (4.1) it went smoothly.
Maybe the README-builds.html should not say Any GNU make 3.81 or newer
-phil.
On 4/14/2015 10:41 AM, Phil Race wrote:
On 4/12/2015 11:34 PM, Erik Joelsson wrote:
That looks weird. What does your
For some time (a couple of weeks) I have run into the following error
whenever I try to build on Windows on my system
I've been using forever .. I have worked around it by doing builds
using JPRT but its getting annoying.
Does anyone have a clue what I am doing wrong. This happens on brand new
Isn't it sufficient to comment out this one line ?
1215 ALL_OTHER_TARGETS += jaccessdocs
.. and add a comment as to why ?
-phil.
On 04/08/2015 10:25 AM, Pete Brunet wrote:
Here is an updated patch.
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/
It simply removes the
from make docs that there is no javadoc
generated for this package on windows build.
Mandy
On 4/8/2015 10:29 AM, Phil Race wrote:
Isn't it sufficient to comment out this one line ?
1215 ALL_OTHER_TARGETS += jaccessdocs
.. and add a comment as to why ?
-phil.
On 04/08/2015 10:25 AM, Pete
I am a bit surprised to note we'd prefer 2012 over 2010.
.. and that we'd been preferring it over 2013. Seems odd to have a version
that was never the 'official' compiler be preferred over offical versions.
It won't affect me as I don't have 2012 but might affect someone else.
So if someone has
AWTEventMonitor.java has a bunch of deprecated methods.
If you don't have time now (I expect you don't) then it can be
revisited later. Open sourcing is different than binary compatibility.
The change jdk/make/copy/Copy-java.gmk suggests that accessbridge
is the only reason the closed version of
On 3/25/2015 10:58 AM, Pete Brunet wrote:
Thanks Phil,
On 3/25/15 11:26 AM, Phil Race wrote:
AWTEventMonitor.java has a bunch of deprecated methods.
If you don't have time now (I expect you don't) then it can be
revisited later. Open sourcing is different than binary compatibility.
These were
I'll admit its been a few weeks since I've build JDK on Windows except
via jprt
but now I can't get past configure and I don't know why its resolving a
variable
that I didn't set instead of looking on my path ..
checking Checking for install src... not found, cannot build installer
checking
One more update: http://cr.openjdk.java.net/~prr/8075277.2/
just adds sun/awt/motif/* to the exclude list.
I'm deleting that directory in another fix but those without those
changes need it
excluded too
-phil.
On 3/16/15 3:05 PM, Phil Race wrote:
There are some files in sun/print some
Bug: https://bugs.openjdk.java.net/browse/JDK-8075277
Fix: http://cr.openjdk.java.net/~prr/8075277/
Although a more complete fix would do something like refactor the source
files,
as that would be less fragile amongst other things, this at least gets
us into a
better shape with minimal
There are some files in sun/print some directories still being used but
for the files
explicitly listed, then in each case all .java files in those
directories are now unused.
So yes, I can make this cleaner and less fragile too!
http://cr.openjdk.java.net/~prr/8075277.1/
-phil.*
*
On 3/16/15
, Phil Race wrote:
Right now to get the extra repos you do
sh get_source.sh http://server.whatits.org
This gets more than most people need which wastes time and disk.
Here is a small change such that you can now do
sh get_source.sh jdk http://server.whatits.org
ie add jdk to indicate you'd like only
Right now to get the extra repos you do
sh get_source.sh http://server.whatits.org
This gets more than most people need which wastes time and disk.
Here is a small change such that you can now do
sh get_source.sh jdk http://server.whatits.org
ie add jdk to indicate you'd like only the repos
I like the overall approach.
We can then attack the warnings lib by lib and/or platform by platform.
I do want to mention that some libs like liblcms are 3rd party open
source libraries
and it may not always be possible to convince upstream to change their code.
-phil.
On 03/04/2015 08:30
, Phil Race wrote:
On 02/03/2015 05:36 AM, Magnus Ihse Bursie wrote:
On 2015-02-02 19:33, Phil Race wrote:
http://bugs.openjdk.java.net/browse/JDK-8071710 added a depedency
check but it was not working because this depends on file
declaration order.
This resolves that which can cause
On 02/03/2015 05:36 AM, Magnus Ihse Bursie wrote:
On 2015-02-02 19:33, Phil Race wrote:
http://bugs.openjdk.java.net/browse/JDK-8071710 added a depedency
check but it was not working because this depends on file declaration
order.
This resolves that which can cause occasional Solaris build
.
On 01/28/2015 05:15 AM, Magnus Ihse Bursie wrote:
On 2015-01-27 22:24, Phil Race wrote:
Hi,
A mistake was made in JDK 8 so that the font libraries for Solaris
are now
being linked against X11 libraries and this is a problem for headless
(server) use
For more details see :
https
Hi,
A mistake was made in JDK 8 so that the font libraries for Solaris are now
being linked against X11 libraries and this is a problem for headless
(server) use
For more details see :
https://bugs.openjdk.java.net/browse/JDK-8071710
I am presenting jdk 9 8 fixes here since this needs a
yep lots of people have reported this/seen this
-phil.
On 12/6/14 1:03 PM, Stuart Marks wrote:
[Adding build-dev to let them know others are seeing this. I'm not on
jigsaw-dev though so this might not make it there.]
Hi Peter,
I ran into this myself the other day and had a wrestling match
Looks good.
-phil.
On 10/28/2014 12:18 PM, Volker Simonis wrote:
Hi,
could you please review the following tiny change which fixes the copy
step of the freetype libraries after 8058756:
http://cr.openjdk.java.net/~simonis/webrevs/8062312/
https://bugs.openjdk.java.net/browse/JDK-8062312
It isn't searching for X11. It is searching for freetype which has no X
dependencies.
freetype is needed on all platforms.
-phil.
On 10/28/2014 12:25 PM, Dave Pointon wrote:
Hi again all ,
Pray tell, does anyone on here have any problem building on 64 bit Windoze
for a 64 bit Windoze target
Ditto.
-phil.
On 10/27/2014 10:33 AM, Tim Bell wrote:
Erik:
Please review this small fix. In configure, there is a check on
Solaris 10 for the definition of XLinearGradient in Xrender.h. The
check is crude in that it's just a plain grep. It also isn't checking
the correct file if using a
I reported this last night David Holmes said this bug was filed :-
https://bugs.openjdk.java.net/browse/JDK-8061574
-phil.
On 10/21/2014 9:11 AM, Eric McCorkle wrote:
I am seeing mysterious build failures on solaris (and solaris only),
that don't seem related to my patch I'm trying to commit.
hudson builds are now failing as below. Did this change below break dev ?
Compiling ec2_aff.c (for libsunec.so)
/localtools/solaris-amd64/SUNWspro/SS12u3-Solaris10u6/SS12u3-slim/bin/cc -DTRACING -DMACRO_MEMSYS_OPS
-DBREAKPTS -DcpuIntel -Di586 -Damd64 -D_LITTLE_ENDIAN= -DSOLARIS -DARCH='amd64'
. A find/replace operation should work. It probably makes sense
to push all changes together.
Regards,
Sean.
[1] http://cr.openjdk.java.net/~chegar/docs/portingScript.html
On 19/09/14 09:28, Magnus Ihse Bursie wrote:
On 2014-09-18 22:42, Phil Race wrote:
https://bugs.openjdk.java.net/browse/JDK
I had considered that but thought that mkdir was more obvious.
I've tried $(install-file) and it seems to work too .. so if that's what
people prefer I'll use that (as below).
-phil.
hg diff make/copy/Copy-java.desktop.gmk
diff --git a/make/copy/Copy-java.desktop.gmk
https://bugs.openjdk.java.net/browse/JDK-8056216
http://cr.openjdk.java.net/~prr/8056216/
This is all just removing the sequence sun/ from various pathnames.
Aside from the make file changes there are over 600 file moves which I
don't think
its worth including in the webrev but they are the
My assumption is the opposite, that most people type 'make' and
nothing more, expecting that if you had to do more to test a code
change builds properly, it would be included in the default target.
If you aren't affecting the images, then you don't expect to need
to build the images.
-phil.
On
Looks good to me.
-phil.
On 9/12/2014 1:48 PM, Mandy Chung wrote:
With the Modular Source Code [1] in JDK 9, the verify-modules target
was added in the build to catch any regression to the module boundaries.
It's important to catch this regression early during jdk development.
This patch
:f08705540498
parent: 10505:88856f58680f
user:chegar
date:Sun Aug 17 15:54:13 2014 +0100
summary: 8054834: Modular Source Code
-phil.
On 09/11/2014 02:36 AM, Magnus Ihse Bursie wrote:
On 2014-09-10 23:10, Phil Race wrote:
Updated webrev :- http://cr.openjdk.java.net/~prr
AM, Magnus Ihse Bursie wrote:
On 2014-09-09 23:17, Phil Race wrote:
After looking at the issues in the bug report below I think the only
think that must be fixed is the unnecessary inclusion of initIDS.c in
libawt_xawt.so
You are correct indeed. I had missed the fact that awt_Font.c,
fontpath.c
of checks in the classes for headless
So I'll leave the OS X files alone
-phil.
On 09/10/2014 12:37 PM, Phil Race wrote:
That means that instead of having to add even more excludes, you can
delete some existing
Doing that leaves just this one :-
ifeq ($(OPENJDK_TARGET_OS), macosx
Updated webrev :- http://cr.openjdk.java.net/~prr/8056213.1/
-phil.
On 09/10/2014 01:28 PM, Phil Race wrote:
I now see InitIDs.m defines more stubs than initIDs.c since
1) some stubs for xawt are instead defined in XToolkit.c
2) some xawt cases (eg Button) have more than an empty stub
After looking at the issues in the bug report below I think the only
think that must be fixed is the unnecessary inclusion of initIDS.c in
libawt_xawt.so
https://bugs.openjdk.java.net/browse/JDK-8056213
http://cr.openjdk.java.net/~prr/8056213/
I've tested this out on Linux and am submitting a
Actually, we need to update the makefiles as well, since these are
listed as exceptions.
Gosh ... I should have remembered that to begin with.
Here's the fixed patch http://cr.openjdk.java.net/~prr/8056209.1
-phil
On 09/05/2014 03:01 AM, Magnus Ihse Bursie wrote:
On 2014-09-04 23:48, Phil
PS i filed https://bugs.openjdk.java.net/browse/JDK-8057711 to track
D3DShaderGen.c
-phil.
On 09/05/2014 08:59 AM, Phil Race wrote:
Actually, we need to update the makefiles as well, since these are
listed as exceptions.
Gosh ... I should have remembered that to begin with.
Here's
https://bugs.openjdk.java.net/browse/JDK-8056209
Proposed removing several files
./windows/native/libawt/sun/java2d/d3d/D3DPipeline.cpp
./windows/native/libawt/sun/java2d/d3d/D3DShaderGen.c
./windows/native/libawt/sun/windows/WBufferStrategy.cpp
After some analysis the actual list of files
* All of the awt-related directories (libawt_* and common) include an
unnecessary extra layer, the sun directory. It is not needed anymore,
Let's *not* do that. It also affects the destination package.
Remember sun.* is the protected top-level package .. and
people won't always be running in
On 8/28/2014 12:36 PM, Phil Race wrote:
* All of the awt-related directories (libawt_* and common) include an
unnecessary extra layer, the sun directory. It is not needed anymore,
Let's *not* do that. It also affects the destination package.
Remember sun.* is the protected top-level package
I understood we now build individual modules so when
I touched one java source file in the desktop module I expected to see only
that one module rebuilt but I see this :-
Compiling 2787 files for java.desktop
Note: Some input files use or override a deprecated API.
Note: Recompile with
On a related note I am scratching my head about why some files
destined to be compiled into libawt or libawt_xawt go into a directory
called 'common'.
Eg OpenGL sources are in common but aren't common to all libs
or even to all awt libs, since they would go into libawt on windows
and libawt_xawt
Looks Ok to me.
-phil.
On 7/17/2014 12:43 PM, David DeHaven wrote:
Ping? Can a build-dev Reviewer approve this?
-DrD-
Please review my trivial backport of JDK-8038027. The actual change is
identical to 9, the difference is the surrounding $(JAVA) is $(JAVA_SMALL) in
JDK 9.
JBS Issue:
BTW .. I just realised I haven't seen a bug ID in this thread.
Does one already exist ?
-phil.
On 5/21/14 5:49 PM, Omair Majid wrote:
* Andrew Hughes gnu.and...@redhat.com [2014-05-21 20:23]:
- Original Message -
* Andrew Hughes gnu.and...@redhat.com [2014-05-21 12:22]:
I'm not keen
On 05/21/2014 08:06 AM, Omair Majid wrote:
I will need to push that closed generated-configure.sh afterwards however
so that closed builds don't break.
Anything I need to do to ensure the pushes are co-ordinated correctly?
Just make sure I notice the push and I'll fix ASAP ..
-phil.
I'm going to apply the patch and run it through open + closed builds
cross-platforms ..
-phil..
On 5/20/2014 10:15 AM, Anthony Petrov wrote:
Thanks for the update, Omair. The fix looks good to me now.
--
best regards,
Anthony
On 5/20/2014 9:11 PM, Omair Majid wrote:
Hi,
Updated webrevs:
-configure.sh afterwards however
so that closed builds don't break.
-phil.
On 05/20/2014 10:18 AM, Phil Race wrote:
I'm going to apply the patch and run it through open + closed builds
cross-platforms ..
-phil..
On 5/20/2014 10:15 AM, Anthony Petrov wrote:
Thanks for the update, Omair. The fix looks
201 - 300 of 388 matches
Mail list logo