Thanks!
--
best regards,
Anthony
On 8/28/2014 1:00 PM, Magnus Ihse Bursie wrote:
On 2014-08-27 12:57, Anthony Petrov wrote:
Hi Magnus,
Those look like reasonable suggestions. Could you please file separate
bugs for each of these issues? Also, please note that most of them
belong to 2D, not
aries.
--
best regards,
Anthony
On 8/25/2014 1:14 PM, Magnus Ihse Bursie wrote:
On 2014-08-20 11:14, Magnus Ihse Bursie wrote:
On 2014-08-18 16:15, Anthony Petrov wrote:
So I'm not sure if the current set of AWT libraries could be
simplified any further.
Hope this helps.
Thank you for the cla
On 8/18/2014 5:47 PM, Magnus Ihse Bursie wrote:
libawt et al:
The relation between libawt, libawt_headless, libjawt, libawt_xawt
and libawt_lwawt are hairy enough to make my brain curl up. I believe
there are simplifications to be made but I gave up trying to figure them
out.
libawt contains
Thanks. Note that your email editor messed up the HTML part of the email
(see below a text-only quote), so here's the correct link to the webrev:
http://cr.openjdk.java.net/~pchelko/9/8047336/webrev.01/
The fix looks fine to me.
--
best regards,
Anthony
On 7/2/2014 3:10 PM, Petr Pchelko wrote
Hi Petr,
The fix looks fine to me. Only one question:
src/share/classes/java/awt/datatransfer/SystemFlavorMap.java
234 } catch (IOException e) {
235 System.err.println("Warning reading flavor mapping: " +
e.getMessage());
Is there a reason to hide the stack trace of the
d need more CCC requests which
consume time.
Thank you.
With best regards. Petr.
On 20 июня 2014 г., at 15:29, Artem Ananiev wrote:
On 6/20/2014 3:19 PM, Anthony Petrov wrote:
Hi Petr,
I ran the following query:
https://www.google.com/#q=custom+flavormap.properties
and the search yielded the
On 6/20/2014 3:29 PM, Artem Ananiev wrote:
On 6/20/2014 3:19 PM, Anthony Petrov wrote:
I ran the following query:
https://www.google.com/#q=custom+flavormap.properties
and the search yielded the following forum thread:
https://community.oracle.com/thread/1293314?start=0&tstart=0
w
Hi Petr,
I ran the following query:
https://www.google.com/#q=custom+flavormap.properties
and the search yielded the following forum thread:
https://community.oracle.com/thread/1293314?start=0&tstart=0
where developers seem to suggest they do edit the
$JDKHOME/jre/lib/flavormap.properties fi
Thanks, Omair.
--
best regards,
Anthony
On 5/23/2014 1:01 AM, Omair Majid wrote:
* Anthony Petrov [2014-05-22 16:48]:
I think that it would be useful to have a bug id prior to sending a review
request, so that a review thread for the bug can be easily found in the
mailing archive. In the
I think that it would be useful to have a bug id prior to sending a
review request, so that a review thread for the bug can be easily found
in the mailing archive. In the future, please do file a bug first and
put its id in the subject line of your review requests.
--
best regards,
Anthony
On
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:
http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01/
http://cr.openjdk.java.net/~omajid/webrevs/system-libjpeg/01.jdk/
* Anthony Petrov
Hi Omair,
common/autoconf/libraries.m4
624 [use libjpeg from build system or OpenJDK source (system, bundled)
@<:bundled@:>@])])
"@<:bundled@:>@" should read "@<:@bundled@:>@" - note the missing @.
make/lib/Awt2dLibraries.gmk
1236 LIBJPEG_CFLAGS := $(JDK_TOPDIR)/src/share/native
Hi Andrew,
"Client code" is basically anything in 2D, AWT, i18n, beans, a11y,
ImageIO, Sound, or Swing. I.e., anything related to GUI/desktop.
In this particular case Omair is changing the SplashScreen code which
belongs to AWT, hence the choice of the client repo for integration.
--
best r
Hi Omair,
Should I be pushing this to jdk9/dev ? (Or to jdk9/client?)
If you change client code, then the fix should go to the client repo to
avoid merge conflicts and allow for more manual testing prior to
integrating the changes into the master repo.
--
best regards,
Anthony
On 2/19/201
Changeset: 43168d403243
Author:anthony
Date: 2013-11-08 20:07 +0400
URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/43168d403243
8027912: [macosx] Provide means to force the headful mode on OS X when running
via ssh
Summary: Bypass AquaSession check if AWT_FORCE_HEADFUL env. var
Hi David,
The fix looks fine to me. Thanks for all your hard work.
--
best regards,
Anthony
On 10/24/2013 03:52 AM, David DeHaven wrote:
Another option (I think would make everyone happy) would be to add a native
method to LWCToolkit.{java,m} that implements isAquaSession and returns a
boo
On 10/23/2013 08:49 PM, David DeHaven wrote:
Not sure about this part. We already force this property to be set in
Embedded without needing any changes in the code you have modified and
I'm not sure if your changes will break what we already do. Why do you
need to do it?
I'm getting concerned a
On 10/23/2013 07:11 PM, Artem Ananiev wrote:
On 10/23/2013 4:34 PM, Anthony Petrov wrote:
On 10/23/2013 08:52 AM, David Holmes wrote:
On 23/10/2013 2:10 PM, David DeHaven wrote:
Updated webrev:
http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/
Summary of changes since last:
- Added
On 10/23/2013 08:52 AM, David Holmes wrote:
On 23/10/2013 2:10 PM, David DeHaven wrote:
Updated webrev:
http://cr.openjdk.java.net/~ddehaven/8025673/jdk.2/
Summary of changes since last:
- Added awt_headless to java_props_t (set to NULL by default which
does not set the property)
Not sure a
We don't have to. IIRC, the choice of HToolkit on Mac was made by chance.
Since we must load the lwawt lib in headless on Mac anyway, we may as
well use the CToolkit (properly wrapped in the HeadlessToolkit). But
there's no need to continue to use the HToolkit on Mac.
--
best regards,
Anthony
Artem is correct. On Mac we can't start a GUI session via ssh, for
example. Thus we choose the headless mode then. The isInAquaSession() is
supposed to perform exactly this check. This logic needs to be preserved.
--
best regards,
Anthony
On 10/22/2013 01:23 PM, Artem Ananiev wrote:
Hi, David
Hi Erik,
The fix looks good to me.
--
best regards,
Anthony
On 10/21/2013 07:08 PM, Erik Joelsson wrote:
"JDK-8025715: Split CompileNativeLibraries.gmk", caused (almost) all
libraries on macosx to be linked incorrectly. I propose we fix this by
removing an ugly hack for libJObjC.dylib, which w
This fix looks fine to me as well.
--
best regards,
Anthony
On 10/20/2013 11:56 PM, David DeHaven wrote:
CCing: build-dev, macosx-port-dev, hotspot-dev
Request for review of JDK-8025673:
https://bugs.openjdk.java.net/browse/JDK-8025673
Proposed changes:
http://cr.openjdk.java.net/~ddehaven/8
Hi David,
The fix looks fine to me.
--
best regards,
Anthony
On 10/20/2013 11:53 PM, David DeHaven wrote:
CCing: build-dev, macosx-port-dev
Request for review of JDK-8016096:
https://bugs.openjdk.java.net/browse/JDK-8016096
Proposed changes:
http://cr.openjdk.java.net/~ddehaven/8016096/
Si
The fix looks fine to me.
--
best regards,
Anthony
On 10/01/2013 09:39 AM, dmitry markov wrote:
Hello,
Could you review a back-port of 7129133 to JDK 7u, please? The back-port
and the main fix integrated into jdk8 are slightly different.
bug: http://bugs.sun.com/view_bug.do?bug_id=7129133
web
Hi Erik,
The fix looks fine to me.
--
best regards,
Anthony
On 08/19/13 16:43, Erik Joelsson wrote:
And again, here we go:
http://cr.openjdk.java.net/~erikj/8023216/webrev.root.01/
/Erik
On 2013-08-19 11:05, Erik Joelsson wrote:
Thanks for the feedback!
I took most of it and made into a c
759/hotspot/webrev.00/hotspot.patch
Thanks to Anthony Petrov who provided the initial set of patches for
this work.
I believe this should go in via the hotspot-rt forest (let me know if
that is not correct), in which case I will need a sponsor from that
team to push the change.
Thanks in advance-
Tim
On 07/10/2013 06:02 PM, Pete Brunet wrote:
On 7/10/13 8:57 AM, Pete Brunet wrote:
On 7/10/13 2:59 AM, Anthony Petrov wrote:
This is a known issue http://bugs.sun.com/view_bug.do?bug_id=8013849
Looks like it's unrelated to a11y and affects any apps with input boxes.
Thanks Anthony, Yo
This is a known issue http://bugs.sun.com/view_bug.do?bug_id=8013849
Looks like it's unrelated to a11y and affects any apps with input boxes.
I'm not an expert in debugging with VS, but I suppose it wants the .pdb
file for the awt.dll. Try locating this file in the build/ directory and
point th
dows_x86/vm/unwind_windows_x86.hpp
webrev and patch file are here:
http://cr.openjdk.java.net/~tbell/8015759/hotspot/webrev.00/
http://cr.openjdk.java.net/~tbell/8015759/hotspot/webrev.00/hotspot.patch
Thanks to Anthony Petrov who provided the initial set of patches for
this work.
I believe this s
[ adding 2d-dev@ ]
On 05/24/2013 11:23 AM, Erik Joelsson wrote:
On 2013-05-23 20:10, David Chase wrote:
One change to add (a by-hand "diff") to
common/autoconf/toolchain_windows.m4 :
AC_MSG_CHECKING([for DirectX SDK lib dir])
if test "x$with_dxsdk_lib" != x; then
DXSDK_LIB_PATH="$wi
here several time myself:)
Nevertheless David, you have my full moral support!
Regards,
Volker
On Thu, May 23, 2013 at 3:09 PM, Anthony Petrov
mailto:anthony.pet...@oracle.com>> wrote:
David,
I pretty much understand the problem you're trying to solve. I
recall myse
se does not do
this, since "repair your path after installing required software" is a good
step not to have in any build process.
On 2013-05-23, at 8:08 AM, Anthony Petrov wrote:
Binaries built with VS2012 won't run on WinXP. You need VS2012sp1 to make them
compatible with X
David,
I have worked around the compatibility of latest DirectX SDK and 32-bit
JDK builds by copying the contents of the \Program Files\Microsoft
DirectX SDK\Lib\x86\* to the Lib\ directory itself. Works like a charm.
--
best regards,
Anthony
On 05/23/13 07:13, David Chase wrote:
I think th
Binaries built with VS2012 won't run on WinXP. You need VS2012sp1 to
make them compatible with XP.
Yes, we don't officially support JDK8 on Windows XP. However, there's a
difference between _not supported_ and _just won't run_.
Hence, if we ever decide to switch to VS2012, we'll most likely w
Hi Morvan,
build-dev@ is the wrong mailing list for this topic. It belongs to
awt-...@openjdk.java.net only. Please re-post this message there.
--
best regards,
Anthony
On 04/17/2013 09:01 PM, Morvan Le Mescam wrote:
Dear all,
When developping a Swing client, I face the following problem :
You can't feed make with the /showInclude output. There's a dedicated
tool in Cygwin (and on *NIX in general) - makedepend. It produces output
that make can parse and understand directly.
--
best regards,
Anthony
On 4/8/2013 20:00, Kelly O'Hair wrote:
I think it's /showIncludes ???
http://msd
Good to know this is unrelated to this fix. Thanks.
--
best regards,
Anthony
On 4/8/2013 17:21, Erik Joelsson wrote:
On 2013-04-08 15:17, Anthony Petrov wrote:
Thanks for clarifying that. Makes sense to me.
The fix looks good to me, btw, although I'm not a build expert.
Also, coul
wrote:
Sjavac also enables parallel execution of java compilation, speeding up
full builds as well. But even if it didn't, being able to verify that
sjavac builds work in jprt will be a must if we are to enable it by
default.
/Erik
On 2013-04-08 14:56, Anthony Petrov wrote:
Just curious:
Just curious: sjavac is supposed to address the issue with slow
incremental builds. JPRT builds are full builds usually. What is the
benefit of using sjavac for full builds?
--
best regards,
Anthony
On 04/08/13 13:44, Erik Joelsson wrote:
Reminder that I would like this reviewed.
/Erik
On 2
It's a known issue:
http://javafx-jira.kenai.com/browse/RT-27210
--
best regards,
Anthony
On 2/15/2013 0:32, Pete Brunet wrote:
I ran into two new problems building JFX on Win 7 this week:
1) I had to unset lowercase tmp and temp. Apparently there is a new
problem with having duplicates, TMP
CC'ing awt-dev@, Yuri, and Artem.
--
best regards,
Anthony
On 11/29/12 18:27, Fredrik Öhrström wrote:
The GensrcX11Wrapper.gmk makefile creates a new sizes.32 or sizes.64 by
running a generated C program
that performs many sizeof calculations on X11 structures. This is cross
compileable.
Fortu
Tim, Kelly: thanks for your review. I'll push the fix via the awt forest
tomorrow.
On 10/29/2012 8:29 PM, Tim Bell wrote:
We're not yet switching JDK builds to VS2012. However, the vsvars.sh
script is useful for other applications in order to set up the build
environment, so I think the propos
Hello,
Please review a fix for
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001764 at:
http://cr.openjdk.java.net/~anthony/8-46-full-vs2012.0/
We're not yet switching JDK builds to VS2012. However, the vsvars.sh
script is useful for other applications in order to set up the build
env
Hi Kelly,
The JDK 8 partial repository (only the jdk itself) builds fine on my Mac
with your changes. The fix looks good to me, although I don't have deep
knowledge of the components being modified.
Thanks for fixing this issue!
--
best regards,
Anthony
On 9/20/2012 5:19 AM, Kelly O'Hair wr
ild-infra makefiles.
The above builds are complete openjdk builds, with no import jdk needed, and no
concerns about
sync issues between jdk components (hotspot<->jdk).
-kto
On Sep 11, 2012, at 6:37 AM, Anthony Petrov wrote:
Magnus,
You've only explained how incremental builds could
On 9/12/2012 1:54 PM, Alan Bateman wrote:
On 12/09/2012 06:46, Fredrik Öhrström wrote:
:
Excellent. I hope you realize how valuable it is that the build system
recompiled the proper source files, then proceed to generate the the
jni headers output
because of native methods in those classes tha
Magnus,
You've only explained how incremental builds could work for Java classes
in the new build-infra. What about incremental builds of native code?
E.g. in AWT we often do the following:
$ cd make/sun/awt (or make/java/awt, or make/sun/lwawt)
$ make
And this re-builds both AWT classes and
+1
--
best regards,
Anthony
On 9/10/2012 6:52 PM, Weijun Wang wrote:
Sorry I was not clear, by "clone the repo(s)", I mean either only the
jdk repo, or plus the jdk/*/closed ones. I almost never clone other
repos (langtools, hotspot, ...).
-Max
On 09/10/2012 10:48 PM, Weijun Wang wrote:
It
This patch won't work for me. I use the following "workaround" patch
instead:
diff -r 8a2bc6e82d81 make/java/Makefile
--- a/make/java/Makefile
+++ b/make/java/Makefile
@@ -58,7 +58,7 @@
endif # PLATFORM
ifeq ($(PLATFORM), macosx)
- SUBDIRS += jobjc
+# SUBDIRS += jobjc
endif # PLATFORM
i
jid wrote:
On 08/13/2012 10:39 AM, Anthony Petrov wrote:
The test looks great, and I like that it doesn't depend on the JAWT
machinery, but tests the actual problematic RPATH entry only.
I generally go for tests that verify behaviour (that jawt-linked
programs are working) rather than
nd see what test Kumar has to offer.
--
best regards,
Anthony
On 08/11/12 00:56, Omair Majid wrote:
Hi Anthony,
On 08/10/2012 08:29 AM, Anthony Petrov wrote:
Actually, if Omair has a good automatic jtreg test, we would be
happy to
get it checked in with this fix. Could we see a webrev for the t
the test is
passed. Systems used for running tests may lack compilers, and this is
perfectly OK.
Having said that, let's wait and see what test Kumar has to offer.
--
best regards,
Anthony
On 08/11/12 00:56, Omair Majid wrote:
Hi Anthony,
On 08/10/2012 08:29 AM, Anthony Petrov wrote:
Actu
On 8/10/2012 4:59 PM, Andrew Hughes wrote:
- Original Message -
On 8/10/2012 4:24 PM, Andrew Hughes wrote:
- Original Message -
Hi Anthony,
a. although this is a build change, I have requested Omair to
provide
a
regression
test, IMO if we had a regression test to begin w
On 8/10/2012 4:24 PM, Andrew Hughes wrote:
- Original Message -
Hi Anthony,
a. although this is a build change, I have requested Omair to provide
a
regression
test, IMO if we had a regression test to begin with, this would
not
have been removed
during the RPATH work. We m
Well, it's complicated. There's problems with JAWT on the Mac currently,
which makes it hard or even impossible to use it on that platform.
We'll add support for the Mac to a test open-sourced with 7190587 once
JAWT is working fine on the Mac in general.
--
best regards,
Anthony
On 8/10/2012
Hi Kumar, Omair,
[ adding awt-dev@ in the loop ]
On 8/10/2012 2:30 PM, Kumar Srinivasan wrote:
a. although this is a build change, I have requested Omair to provide a
regression
test, IMO if we had a regression test to begin with, this would not
have been removed
during the RPATH work.
Hi Omair,
The fix looks good to me. I think Kumar needs to take a look at it, too,
before the fix can be pushed to a repo.
Thanks for finding and fixing this issue.
--
best regards,
Anthony
On 8/10/2012 1:48 AM, Omair Majid wrote:
On 08/09/2012 07:15 AM, Andrew Hughes wrote:
- Original
Looks good to me. Although most of the changes are in Java2D code, so
I'm also CC'ing 2d-dev@ to take a look.
--
best regards,
Anthony
On 7/3/2012 10:23 PM, Erik Joelsson wrote:
The build infra project added the use of the annotation
GenerateNativeHeader. It was addded to java classes without
Hi David,
The fix looks fine to me. Is the empty line 281 OK in Makefiles? I'd
remove it just in case. Besides it would make it more clearer that the
SIZERS_CC commands are related to the SIZERS target.
--
best regards,
Anthony
On 5/25/2012 10:20 AM, David Holmes wrote:
This is a tweak to th
On 4/25/2012 6:15 PM, Magnus Ihse Bursie wrote:
However, this problem may occur again because most developers use the
old build system, and as such won't notice the issue. Is there a plan
to remove the old build system and switch over to the new one?
Yes, there is such a plan. The exact detail
Hi Magnus,
The fix looks fine to me.
However, this problem may occur again because most developers use the
old build system, and as such won't notice the issue. Is there a plan to
remove the old build system and switch over to the new one?
--
best regards,
Anthony
On 4/25/2012 5:44 PM, Magn
Hi Ray,
JDK is buildable on 10.6. Please run Apple Software Update to install
all the latest patches on your Snow Leopard system. This should update
the FreeType lib as well.
--
best regards,
Anthony
On 04/22/12 02:36, Ray Kiddy wrote:
I am seeing differing statements about what is needed
Hi Michael,
Changes to awt/font makefiles look fine to me.
--
best regards,
Anthony
On 03/21/12 19:03, Michael McMahon wrote:
Could I get the following change reviewed please for jdk 8?
It is to fix a number of minor build warnings caused by the macosx changes.
http://cr.openjdk.java.net/~mi
Hi Martin,
On 3/6/2012 6:17 PM, martin burtscher wrote:
if I use BUILD_HEADLESS=true the awt packages are included and useable.
So either I understand BUILD_HEADLESS wrong or it doesnt do what its
supposed to do.
AWT can work w/o a display, e.g. for in-memory image manipulation, or
printing
Hi David,
The fix looks good to me.
--
best regards,
Anthony
On 3/23/2011 4:25 AM, David Holmes wrote:
(build-dev cc'ed as there are some makefile changes (Hi Kelly! :) ) )
webrev:
http://cr.openjdk.java.net/~dholmes/7030063/webrev/
This CR integrates support for SE-Embedded into the AWT. T
Hi Andrew,
On 3/10/2011 3:48 AM, Dr Andrew John Hughes wrote:
* Separating out the client (awt/swing/etc) code from the jdk repo into a
separate repo
Why would we want to do this? IME, there are lots of interdependencies with
the other code and
this would make the build a nightmare.
No
On 6/17/2009 10:13 PM Andrew John Hughes wrote:
Please update the README-builds.html file also as Kelly suggests. Thanks!
Ok here's an updated version with Xrender mentioned in README-builds:
http://fuseyism.com/6851515/webrev.03/
Ok?
Perfect! Approved. Feel free to push to the AWT gate.
--
Andrew,
Please update the README-builds.html file also as Kelly suggests. Thanks!
--
best regards,
Anthony
On 6/17/2009 9:00 PM Anthony Petrov wrote:
On 6/17/2009 8:44 PM Andrew John Hughes wrote:
So should I push the original webrev
http://fuseyism.com/xrender/webrev.01/ (which uses the
On 6/17/2009 8:44 PM Andrew John Hughes wrote:
So should I push the original webrev
http://fuseyism.com/xrender/webrev.01/ (which uses the standard header
instead) to the awt gate?
Given Kelly's point, I'm approving the fix. Please use the CR number
6851515 for your commit message. Thanks for th
So, build-dev,
Any opinions? Can we make sure the header is always present on Sol10u2?
Perhaps we could add it to the requirements list for building OpenJDK?
--
best regards,
Anthony
On 06/16/2009 07:25 PM, Anthony Petrov wrote:
On 06/16/2009 07:21 PM, Andrew John Hughes wrote:
Is it
On 06/16/2009 07:21 PM, Andrew John Hughes wrote:
Is it really necessary to include a chunk of the header file rather
than just doing a #include? If so, may I suggest that the block is
dependent on _XRENDER_H_ not being defined?
The header may be absent on Solaris 10 U2 which is now a supported
wrote:
Anthony Petrov wrote:
Do the following instead:
[extensions]
hgext.fetch =
[defaults]
fetch = -m Merge
OK, ta.
Andrew.
Do the following instead:
[extensions]
hgext.fetch =
[defaults]
fetch = -m Merge
--
best regards,
Anthony
On 06/02/2009 06:43 PM, Andrew Haley wrote:
I can't get the fetch extension to work properly.
I was told that I need to add
[extensions]
hgext.fetch = -m Merge
but that doesn't work:
On 5/15/2009 5:48 PM Jonathan Gibbons wrote:
The irony here is that yesterday I updated my laptop to Ubuntu 9.04, and
(a) the Mercurial package does not completely install correctly
(b) even if it did, it is version 1.1.2.something, and OpenJDK requires
0.9.5.
I don't experience any problems
On 4/27/2009 7:56 PM Dmitri Trembovetski wrote:
On pretty much any system you can tell if a drive is local or not,
albeit in a system specific way.
That would be cool. However I don't see much justification around
verifying for sure if a path is on the network. After all it's just a
warning mes
Jon, Kelly, Xiomara,
Thank you very much for your feedback. I decided to revise the fix to:
1. Leave the current c:\jdk default path for those who still uses it.
2. Issue a warning message on MS Windows platform if the BOOTDIR is
located on the J: drive (that is assumed to be mapped over network
eople rely on this c:/jdk1.6.0
default. With enough warning you might be able to change this.
---
I have been recently working on the JavaFX build dependency issues
and although it's more ant based, some of the techniques could apply
to making OpenJDK builds easier. Unfortunately, there is only
ortunately, there is only 24hrs
in a day. :^{
-kto
Anthony Petrov wrote:
Hello,
Back in 2007 we already discussed this issue with Kelly, but
transitioning to Mercurial just stopped the work. So, I would like to
revive this now.
Here's a part of the output generated by `grep -r BOOTDIR
adme's.
--
best regards,
Anthony
-kto
Anthony Petrov wrote:
Please review the fix for the CR mentioned in the subject. The webrev:
http://cr.openjdk.java.net/~anthony/webrev-6833444.0/
I verified the fix on MS Windows platform, and it works pretty well.
--
best regards,
Anthony
:/jdk1.6.0
default. With enough warning you might be able to change this.
It's OK with me, if you remove c:/jdk ...
Great to hear that! Thanks!
--
best regards,
Anthony
Thanks,
-Xiomara
On 04/23/09 09:31, Anthony Petrov wrote:
Hi Xiomara,
Thank you for the comments!
On 4/23/2009 6:
Hi Xiomara,
Thank you for the comments!
On 4/23/2009 6:27 PM Xiomara Jayasena wrote:
Release Engineering uses c:\jdk ... when building on windows. We will
still need that.
Ups. I'm sorry about that, I really didn't know you use this path. This
was the reason I initiated the discussion on the
Please review the fix for the CR mentioned in the subject. The webrev:
http://cr.openjdk.java.net/~anthony/webrev-6833444.0/
I verified the fix on MS Windows platform, and it works pretty well.
--
best regards,
Anthony
Hello,
Back in 2007 we already discussed this issue with Kelly, but
transitioning to Mercurial just stopped the work. So, I would like to
revive this now.
Here's a part of the output generated by `grep -r BOOTDIR make/*`:
make/common/shared/Defs-solaris.gmk: _BOOTDIR1
=$(SLASH_JAVA)/re/j
Hi Mark,
On 08/28/2008 09:35 PM Mark Wielaard wrote:
On Thu, 2008-08-28 at 14:23 +0400, Anthony Petrov wrote:
1. The patch cuts off the embedded versions of these libraries from
OpenJDK source code. In fact, there may exist systems where these
libraries are not installed. And currently
On 08/28/2008 08:33 PM Martin Buchholz wrote:
I'm thinking:
- the MMX support is in pnggccrd.c,
- but that file is never compiled in OpenJDK
Why? There's the following line in the make/sun/splashscreen/Makefile:
vpath %.c $(SHARE_SRC)/native/$(PKGDIR)/libpng
that effectively includes all *.c
penJDK on future stock Linux systems.
Martin
On Thu, Aug 28, 2008 at 3:11 AM, Anthony Petrov <[EMAIL PROTECTED]> wrote:
Hello Martin,
Thank you for the patch. Though there's a little concern: how does the bare
libpng deal with this issue when compiled using the toolchain you use? I
m
Hi Mark,
Thanks for pointing this. Actually, the patch existing in the IcedTea
seems to have two potential issues that we at Sun are worried about:
1. The patch cuts off the embedded versions of these libraries from
OpenJDK source code. In fact, there may exist systems where these
libraries
e in pnggccrd.c.
+# Newer versions of the PNG-library may not need this option.
+CPPFLAGS += -DPNG_NO_MMX_CODE
Martin
On Wed, Aug 27, 2008 at 5:48 AM, Anthony Petrov <[EMAIL PROTECTED]> wrote:
Hi Martin,
On 08/25/2008 08:17 PM Martin Buchholz wrote:
Thanks for the link, but...
- The fix for 661
Hi Martin,
On 08/25/2008 08:17 PM Martin Buchholz wrote:
Thanks for the link, but...
- The fix for 6613927 is applied in my workspace
And it gets activated when building on a 64-bit system only. Could you
please take a look at the make/sun/splashscreen/Makefile file and make
sure it defines th
Hi Martin,
On 08/24/2008 04:44 AM Martin Buchholz wrote:
../../../build/linux-i586/tmp/sun/sun.awt/splashscreen/obj/png.o: In
function `png_init_mmx_flags':
png.c:(.text+0xbb): undefined reference to `png_mmx_support'
It looks like another reincarnation of
http://bugs.sun.com/view_bug.do?bug_id
Hi Kelly,
On 07/31/2008 10:58 PM Kelly O'Hair wrote:
So no plugin code, no installation bundle code, etc.
Right. But all the currently opensourced code was buildable at that time.
From this point it was clean: VS2005ExpressSP1 + Platform SDK for
Win2003R2 + DirectX SDK June 2007 + cygwin. No
sourced, the community doesn't need to worry about
their compatibility with Express, does it?
--
best regards,
Anthony
If you can use the Express compiler for your OpenJDK work, that's great,
just make sure that's indeed what you are using. ;^)
-kto
Anthony Petrov wrote:
Abo
On 07/30/2008 07:56 PM Erik Trimble wrote:
would make it very nice. Unfortunately, the free version of VS is
actually _very_ different than the Professional version, and not just
the compiler itself (which, has a whole 'nother set of bugs unique to
it...).
AFAIK, that was true for the free ver
ery buildable with the
free Express edition, and once we are building with the Professional
edition, someone can see how much is buildable with the Express edition.
-kto
Anthony Petrov wrote:
On 07/29/2008 11:03 PM Erik Trimble wrote:
I certainly can't speak for Sun on this. But, I don't t
On 07/29/2008 11:03 PM Erik Trimble wrote:
I certainly can't speak for Sun on this. But, I don't think there is
any immediate plans to use GCC on Windows. It would probably be OK if
someone wanted to try, but I can't imagine it being even remotely easy.
There's just so much stuff dependent on
This is a known issue. Anyway, thanks for reporting it! Please refer to
the following bug to track the status of the problem:
http://bugs.sun.com/view_bug.do?bug_id=6613927
Currently the bug is being fixed.
Concerning the possibility of using an external libpng library, we've
got the followin
ed Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
-Original Message-
From: [EMAIL PROTECTED] [mailto:build-dev-
[EMAIL PROTECTED] On Behalf Of Anthony Petrov
Sent: Friday, August 17, 2007 12:21 AM
To: Rishi Khare
Cc: build-dev@openjdk.j
I took some part in testing the VS2005 Express to build the JDK. So far
there's no any major problem present except the following:
http://bugs.sun.com/view_bug.do?bug_id=6523947
However, this RFE has a very simple workaround provided. Please try it
and tell us about the results.
--
best regard
Hmm...
On 08/01/2007 10:58 PM Dan Fabulich wrote:
It is believed to build and work on all platform combinations : windows,
linux, solaris, 32 and 64 bit, but testing has focused on the 32 bit
versions.
"believed to build"? Has anyone yet tried doing the standard OpenJDK
build on Windows, follo
1 - 100 of 101 matches
Mail list logo
