On 05/10/2011 08:45 PM, Kelly O'Hair wrote:
On May 5, 2011, at 4:14 PM, Omair Majid wrote:
Hi Kelly,
Kelly O'Hair writes:
Need reviewer: Added test target and makefile cleanups
6960335: Add top level 'make test' rule that uses test/Makefile, runs
all test batc
Hi,
On 05/11/2011 11:31 AM, [email protected] wrote:
Changeset: 42c22d5a2cd0
Author:bpatel
Date: 2011-05-11 08:30 -0700
URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/42c22d5a2cd0
7043684: Update man pages for JDK 7 tools
Reviewed-by: skannan
Since we are updating man
On 05/09/2011 04:02 PM, Dmitry Samersoff wrote:
Omair,
Will do it tomorrow.
Ping. Just in case you forgot.
Thanks,
Omair
On 05/11/2011 01:03 PM, Kelly O'Hair wrote:
I found this bug:
http://bugs.sun.com/view_bug.do?bug_id=4495986
Which seems to imply that maybe this java-rmi.cgi file doesn't belong in the
"bin" directory at all?
But it also seems to me that the current:
91 ifneq ($(ARCH_DATA_MODEL), 32)
On 05/11/2011 01:49 PM, Kelly O'Hair wrote:
On May 11, 2011, at 10:35 AM, Omair Majid wrote:
Q2: Does it belong somewhere other than the bin directory?
I am not sure. It is not supposed to be executed directly by a
user. But it is an executable file. I think the extension makes it
On 05/11/2011 09:50 PM, Kelly O'Hair wrote:
Please review this change:
7043921: generate java-rmi.cgi on 64 bit platform
http://cr.openjdk.java.net/~ohair/openjdk7/java-rmi-7043921/webrev/
I think this works for you guys, and seems to be a bit more obvious, at least
to me. ;^)
If, as the o
Hi Kelly,
On 05/12/2011 04:39 PM, Kelly O'Hair wrote:
Need reviewers. (Omair, you will want to verify this works for IcedTea).
Some background: this changeset:
http://hg.openjdk.java.net/jdk7/jdk7/rev/47f6b7db1882
Created some issues for people setting ALT_OUTPUTDIR to a vanilla path like
On 05/12/2011 10:00 PM, Kelly O'Hair wrote:
On May 12, 2011, at 4:33 PM, Omair Majid wrote:
Hi Kelly,
On 05/12/2011 04:39 PM, Kelly O'Hair wrote:
Need reviewers. (Omair, you will want to verify this works for IcedTea).
Some background: this changeset:
http://hg.openjdk.jav
Hi Kelly,
On 07/09/2012 06:12 PM, Kelly O'Hair wrote:
> The jdk8/build forest has been in sync for a few days, so anyone willing to
> try the new build system with OpenJDK 8, please
> follow these instructions:
>
> hg clone http://hg.openjdk.java.net/jdk8/build jdk8-build
> cd jdk8-bui
On 07/09/2012 07:44 PM, David Holmes wrote:
> Hi Omair,
>
> The static vs dynamic link check that you see is only in place for the
> JDK libraries not hotspot. For hotspot (which has not been modified as
> part of the build-infra project) you still need to pass STATIC_CXX=false
> as a make variabl
Hi,
I was poking around the LD_LIBRARY_PATH change in the launchers. Joe
Darcy's blog post [1] was a great resource for this (thanks Joe!).
There's one thing I dont quite get and I was hoping someone could shed
some light on this.
Most of the binary launchers contain RPATHS to the jli lib:
$ rea
On 07/19/2012 01:54 PM, Kelly O'Hair wrote:
>
> The java process does not need to have the runtime linker access
> anything from there as far as I know.
Do you think anything might break if an RPATH to jre/lib/ was
added? I have done a custom build of OpenJDK7 with this change and it
seems to be
Hi Kumar,
On 07/23/2012 11:19 AM, Kumar Srinivasan wrote:
> My suggestion is to see if System.loadLibrary can be used, this will
> bode well for the
> modularization effort.
Unfortunately, this bug can come up with proprietary third-party code
that cant be modified by the users of OpenJDK. Also,
Hi Kumar,
On 07/23/2012 11:19 AM, Kumar Srinivasan wrote:
> My suggestion is to see if System.loadLibrary can be used, this will
> bode well for the modularization effort.
I discussed this with the folks at awt-dev and they would prefer to
avoid loading as much as possible. They are strongly aga
On 08/09/2012 07:15 AM, Andrew Hughes wrote:
> - Original Message -
>> Hi Kumar,
>>
>> On 07/23/2012 11:19 AM, Kumar Srinivasan wrote:
>>> My suggestion is to see if System.loadLibrary can be used, this
>>> will
>>> bode well for the modularization effort.
>>
>> I discussed this with the fo
On 08/10/2012 08:20 AM, Andrew Hughes wrote:
>>> I built jdk8/build successfully just last week. What issues are
>>> you seeing?
>>
>> Errors building hotspot, I seem to recall. But I cant reproduce it
>> anymore after pulling today. I can now confirm that the fix works for
>> me
>> with jdk8 too.
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 test please?
I have uploaded a new webrev that includes a test case too:
http://cr.openjdk.java.net
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 implementation deta
On 08/14/2012 07:13 AM, Kumar Srinivasan wrote:
>
>> I see your point. As I told you we'll be open-sourcing a JAWT-specific
>> test under 7190587. This test already provides support for Linux,
>> Solaris, and Windows platforms, and even does a little more than just
>> loads the jawt library.
Awes
On 08/14/2012 05:04 PM, Kumar Srinivasan wrote:
> Hi Omair,
>
> Thumbs up!. please let me know when you actually push I will set the CR,
> so that
> the integrator does not get confused, and I don't get awt push
> notifications.
Pushed:
http://hg.openjdk.java.net/jdk8/awt/jdk/rev/f003387c33ad
>
Hi,
On 08/24/2012 03:30 PM, Developer Ubuntu wrote:
> Hi,
> I am getting following error building JDK7 source.
It looks like you are trying to build hg.openjdk.java.net/jdk7/tl/.
That's very out-of-date. Most of the problems you have mentioned here
are fixed in the jdk7u (the u is for updates)
Hi,
I have a webrev at:
http://cr.openjdk.java.net/~omajid/webrevs/system-giflib/00/
It introduces a configure option --with-giflib that (similar to the
existing --with-zlib) allows specifying whether the build should use the
system installed giflib or the one bundled with OpenJDK.
I have not te
On 03/08/2013 12:26 PM, Phil Race wrote:
> If I understand correctly, this removes the directory containing
> the JDK's copy of giflib sources from the set of locations to be
> compiled etc, and replaces it with just a link line pointer to use
> "libgif" which is then expected to be on the default
On 03/13/2013 12:16 PM, Andrew Hughes wrote:
> 1. It took some time to work out how to get back to the usual 'noisy' build
> as the
> default seems to subdue all the useful output. VERBOSE=true broke the build
> when
> it tried to use 'true' as a Makefile target. It turns out the solution is
Hi,
jdk/makefiles/CompileNativeLibraries.gmk has a little note:
TODO Set DISABLE_INTREE_EC in configure if
src/share/native/sun/security/ec/impl is not present
The webrev at http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/00/
implements this. Does this look okay for jdk8/build ? Can I get a
Hi,
Updated webrev at:
http://cr.openjdk.java.net/~omajid/webrevs/intree-ec/01/
I switched from DISABLE_INTREE_EC to ENABLE_INTREE_EC to avoid the
confusion with double negatives.
Note that because of the ifeq comparison, if you use the new build
system and just update the jdk tree, the ifeq ($E
On 03/14/2013 03:14 PM, Vincent Ryan wrote:
> The DISABLE_INTREE_EC flag is designed to control whether the Elliptic Curve
> support in the
> JDK source tree is skipped during a build. It is used to avoid the
> duplication of EC libraries on
> platforms where an EC library is already present.
>
Hi Andrew,
On 03/13/2013 05:08 AM, Andrew Hughes wrote:
> Given this is essentially a binary option (system giflib or bundled giflib),
> why is AC_ARG_ENABLE not being used instead of AC_ARG_WITH? It would simplify
> the logic here and is what we use in the equivalent IcedTea check which has
> be
Hi,
Updated webrev at:
http://cr.openjdk.java.net/~omajid/webrevs/system-giflib/01/
The webrev borrows some idioms that Andrew Hughes pointed out, and uses
system headers for giflib too.
I checked this by building --with-libgif=system and also by removing the
src/share/native/sun/awt/giflib dir
On 03/14/2013 07:39 PM, Omair Majid wrote:
> I checked this by building --with-libgif=system
Typo. I meant '--with-giflib=bundled' (I had also removed the system
giflib headers at that point to ensure the bundled copy was used).
Thanks,
Omair
--
PGP Key: 66484681 (http:
On 03/15/2013 02:05 PM, Andrew Hughes wrote:
>> Might want to update configure to check for these libs on linux.
>>
>
> Well that won't work everywhere:
>
> $ apt-get install libx11-dev libxext-dev libxt-dev libxrender-dev
> bash: apt-get: command not found
>
> so this advice has limited usage a
On 03/13/2013 10:02 PM, David Holmes wrote:
> Bug ID: 8010030
The bug is not public, so I am not sure what the summary of the issue
is. Is it "Allow configure to detect if EC implementation is present"? I
ask because often the developer who files the bug gives it a different
(often better) summar
Hi,
On 03/15/2013 07:15 AM, David Holmes wrote:
> On 15/03/2013 7:04 PM, Erik Joelsson wrote:
>> And as David pointed out, please notify me and Tim Bell when you push
>
> If I am added to that list we will have global timezone coverage :)
> Though we should all see the push notifications anyway,
Hi,
The repository at http://hg.openjdk.java.net/jdk8/build/nashorn is empty
with no changesets. Now the build fails (on 'make all') with an error:
## Starting nashorn
/bin/sh: line 0: cd: /home/omajid/devel/jdk8-build/nashorn/makefiles: No
such file or directory
make: *** [nashorn-only] Error 1
On 03/15/2013 03:55 PM, Omair Majid wrote:
> In file included from
> /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/jdk/gensrc_x11wrappers/sizer.64.c:11:0:
> /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/solaris/native/sun/awt/awt_p.h:51:36:
> fatal error: X1
Hi Erik,
On 03/19/2013 05:19 AM, Erik Joelsson wrote:
> On 2013-03-18 21:39, Omair Majid wrote:
>> A one-line fix is:
>> http://cr.openjdk.java.net/~omajid/webrevs/x11-header-check/00/
>>
> Nice find and simple fix. The "break" is even mentioned in the
>
On 03/15/2013 05:42 AM, Erik Joelsson wrote:
>> On 2013-03-15 04:10, Andrew Hughes wrote:
>>> On 03/08/2013 12:26 PM, Phil Race wrote:
If I understand correctly, this removes the directory containing
the JDK's copy of giflib sources from the set of locations to be
compiled etc, and r
Hi,
I tried using the new build system to build zero and ran into a bunch of
problems. The following webrev allows me to build zero successfully.
http://cr.openjdk.java.net/~omajid/webrevs/zero-newbuild/00/
Any thoughts, comments or suggestions?
Thanks,
Omair
--
PGP Key: 66484681 (http://pgp.
Hi,
On 03/27/2013 04:55 AM, Erik Joelsson wrote:
> Work on this was already initiated in this thread:
>
> http://mail.openjdk.java.net/pipermail/build-infra-dev/2013-February/003059.html
>
Whoops. I was not aware of this. Thanks for pointing this out.
> Would be good if these efforts could be
Hi,
On 03/27/2013 10:05 AM, Roman Kennke wrote:
> Am Mittwoch, den 27.03.2013, 09:42 -0400 schrieb Omair Majid:
>> Roman, how do you want to proceed?
>
> I'd go with Erik's suggestion and keep your part for JDK changes, and
> mine for the rest, if that is ok with y
On 03/20/2013 03:49 AM, Erik Joelsson wrote:
> This looks good to me. Thanks!
I would like to push this. Could I get a bug ID, please?
Thanks,
Omair
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
On 04/02/2013 01:45 PM, Mike Duigou wrote:
> Done!
>
> JDK-8011278 : Allow using a system-installed giflib
>
Thanks. I have pushed the changesets:
http://hg.openjdk.java.net/jdk8/build/rev/f3cdfb3d360d
http://hg.openjdk.java.net/jdk8/build/jdk/rev/9c76ea43d491
Cheers,
Omair
--
PGP Key: 664846
Hi,
Updated patch at:
http://cr.openjdk.java.net/~omajid/webrevs/zero-newbuild/02/
On 04/02/2013 05:21 AM, Erik Joelsson wrote:
> I know it's not always obvious where things belong but I would put the
> INCLUDE_SA logic in jdk-options.m4 somewhere close after the JVM_VARIANT
> variables have been
On 04/02/2013 10:42 PM, Tim Bell wrote:
> I regret the fact that I did not test the fix for 8009988 (see below)
> when I reviewed it. The script as written there assumes that the
> 'which' utility will return nothing if the command is not found. On
> some platforms (Solaris and Windows/Cygwin to
On 04/03/2013 11:17 AM, Erik Joelsson wrote:
> On 2013-04-03 16:54, Andrew Hughes wrote:
>> Do we have a bug ID? Assuming I don't find any issues, we should be
>> good to go.
> JDK-8011388: Support building zero and zeroshark with the new build
>
> /Erik
I have pushed the changes:
http://hg.open
On 04/08/2013 03:26 PM, Andrew Hughes wrote:
>> I have pushed the changes:
>> http://hg.openjdk.java.net/jdk8/build/rev/653ff6bcf0b1
>> http://hg.openjdk.java.net/jdk8/build/jdk/rev/fddd158b872a
>>
>> Thank you everyone for all (very patient) reviews and suggestions!
>>
>
> I'm quite surprised to
On 04/09/2013 06:01 PM, Brad Wetmore wrote:
> Mike/Omair/Eric,
>
> This putback has likely broken the old JDK build (i.e. in jdk/make)
>
> JDK-8011812: JDK-8011278 breaks the old build
Sorry for this.
> At least deploy and JCE are still stuck on the old build.
I would like to avoid this i
Hi,
The following webrev makes zero build succesfully on arm:
http://cr.openjdk.java.net/~omajid/webrevs/zero-on-arm/00/
The only problem I ran into while trying to build zero on armv7l is that
the gcc there does not like -m32. The changes make the build system
check whether the compiler supports
Hi Erik,
On 04/17/2013 03:31 AM, Erik Joelsson wrote:
> On 2013-04-17 04:05, Omair Majid wrote:
>> The following webrev makes zero build succesfully on arm:
>> http://cr.openjdk.java.net/~omajid/webrevs/zero-on-arm/00/
>>
>> The only problem I ran into while trying to b
On 04/29/2013 05:35 AM, Erik Joelsson wrote:
> Looks good!
Thanks for the review! Could I get a bug id so I can push this to
jdk8/build?
Thanks,
Omair
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
On 04/29/2013 12:09 PM, Mike Duigou wrote:
> Done. JDK-8013480 created
Thanks! I have pushed the changesets:
http://hg.openjdk.java.net/jdk8/build/rev/1dfcc874461e
http://hg.openjdk.java.net/jdk8/build/jdk/rev/12af7c32c648
> and assigned to you.
I cant access https://jbs.oracle.com/bugs/browse/
On 04/30/2013 05:57 AM, Erik Joelsson wrote:
> Open part of this review:
>
> The docs team will start producing separate man pages for openjdk and
> oraclejdk. Here are the necessary changes to the makefiles to support
> this. This was already done for 7u, but these are the changes for 8.
>
> htt
On 05/02/2013 12:38 PM, Jonathan Gibbons wrote:
> On 05/02/2013 08:58 AM, Andrew Hughes wrote:
>>> The man pages in the
>>> >jdk source tree are generated files that the docs team periodically
>>> updates.
>>> >
>> Will the source files be added to the OpenJDK trees at some point?
>>
>
> Purely
On 05/21/2013 10:22 AM, Erik Joelsson wrote:
> Open part of this review. Moving logic for choosing open or oracle man
> pages to closed makefile.
>
> http://cr.openjdk.java.net/~erikj/8014970/webrev.jdk.01/
Looks okay to me.
Cheers,
Omair
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint
* Magnus Ihse Bursie [2015-02-03 08:48]:
> In a somewhat related area: I've been toying with the idea of rewriting the
> build-readme in markdown instead, and just generate the html file. Updating
> proper, consistent html formatting for a document like this is quite
> painful, and we never seem t
Hi,
* Jiri Vanek [2015-01-26 09:08]:
> jhat.1 have wrong url in "see also" section in openjdk7 [1]
Unfortunately, as far as I am aware, the man pages in the openjdk
repositories are generated from master sources maintained by the docs
team (elsewhere?) [1]. I am not sure if it's okay to just pu
Hi,
* Omair Majid [2014-11-18 11:57]:
> * Magnus Ihse Bursie [2014-10-13 07:49]:
> > On 2014-10-13 10:57, Erik Joelsson wrote:
> > >I think it's still used by the hotspot makefiles (sa-jdi.jar). Seems weird
> > >that we still set it in configure but then ignore
Hi,
I discovered a bug in SetupNativeCompilation that results in some C++
code being built with wrong CXXFLAGS.
Bug: https://bugs.openjdk.java.net/browse/JDK-8087156
Webrev:
http://cr.openjdk.java.net/~omajid/webrevs/8087156-setupnativecompilation/00/
It turns out that debugging flags are autom
* Magnus Ihse Bursie [2015-06-12 09:02]:
> Looks good to me too.
Thanks for the review! Sorry I was unable to credit you since I already
pushed the patch.
> However, this is not the first time we've encountered a problem like this. I
> ran into a similar problem some time ago. It's a very brittl
Hi,
* Alex Kashchenko [2015-07-20 14:21]:
> On 07/20/2015 03:00 PM, Antoine NIVOL wrote:
> >The last logic instrument doesn't work after a few secondes (30 or 45) of
> >execution.
> >
> >the error stack is below :
> >C [ntdll.dll+0x52d37] RtlFreeHeap+0xcd
> >C [ntdll.dll+0x52ce8] RtlFreeHeap
(moving from jdk9-dev)
Hi,
I have created a webrev at:
http://cr.openjdk.java.net/~omajid/webrevs/8139932-typo-makefile-jpeg/00/
Typo in makefile changes for 8043805 [Allow using a system-installed libjpeg]
Reviewed-by: omajid, prr
Contributed-by: Matthias Klose
Regards,
Omair
* Philip Race
* Yasumasa Suenaga [2015-11-16 04:38]:
> I would like to propose JDK-8036003: Add
> --with-debug-symbols=[none|internal|external|zipped] .
>
> I had posted this enhancement which provides new make variable [1].
> But it does not fit current jdk 9. So I propose it again as new configure
> option
* Magnus Ihse Bursie [2015-11-18 13:15]:
> * Maybe the name of the flag should reflect the fact that we're
> talking about native debug information, and not the java classes. Or
> maybe that's just understood..?
Actually, I wouldn't mind at all if this option included debug
information for jav
* David Holmes [2015-11-18 07:01]:
> My main point of contention is that zipping is simply a packaging choice for
> the externally generated symbols - and we already have a configure option to
> control that so I don't see why we would want to double up on that part. (I
> don't think we have a dep
Hi,
Bug: https://bugs.openjdk.java.net/browse/JDK-8154394
Webrev: http://cr.openjdk.java.net/~omajid/webrevs/8154394-bad-test/00/
I was building OpenJDK 9 as:
$ bash ../configure --disable-javac-server
And I saw a funny looking message in the configure output
jdk9-dev/common/autoconf/g
* Erik Joelsson [2016-04-18 03:09]:
> I'll push it in your name. Thanks for fixing!
Thank you for the quick review and taking care of the fix!
Omair
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
* Andrew Hughes [2016-07-07 11:53]:
> Sadly, I celebrated too soon; it seems that change just delayed the failure
> until much later in the build.
>
> I've found the problem though. In
> src/share/vm/utilities/globalDefinitions.hpp,
> we have:
>
> #ifdef max
> #undef max
> #endif
>
> #ifdef mi
* Erik Joelsson [2016-10-10 09:55]:
> Please review this change, which reorganizes src.zip into modules
> directories. It also includes the source of any imported modules into
> src.zip.
My main use case for src.zip is stepping into JDK code and setting
breakpoints when I am debugging my applicat
* Mandy Chung [2016-10-31 16:32]:
> Yes this change impacts IDE.
>
> We have contacted some IDE vendors including NetBeans, IntelliJ,
> JDeveloper, Eclipse about this proposed change and confirm that they
> are ok with the proposed change from several of them.
Great to hear this. Thanks!
Omair
Hi,
I have been working on building preview versions of OpenJDK 9 for
Fedora. You can see the latest build here:
https://copr.fedorainfracloud.org/coprs/omajid/openjdk9/build/509314/
One thing that I just realized is that we build OpenJDK 9 using the
configure option --with-native-debug-symbols=i
Hi,
webrev:
http://cr.openjdk.java.net/~omajid/webrevs/system-icu/00/
This implements support for linking against the system-installed ICU
instead of building and linking against the bundled copy of ICU in
OpenJDK8. Now someone building OpenJDK can delete the .../font/layout
directory and use con
add USE_EXTERNAL_ICU_LE to spec.gmk.in.
You are right, of course. Fixed.
> Are ICU_LE_CFLAGS and ICE_LE_LIBS supposed to be empty?
Yes, they are empty on bundled builds. On system builds, they may not
be. On my machine, with --with-icu-le=system, I get:
ICU_LE_CFLAGS:=
ICU_LE_LIBS:=-licule
Hi Phil,
Updated webrev:
http://cr.openjdk.java.net/~omajid/webrevs/system-icu/01/
It's still against jdk8/build and missing support for the old build system.
On 06/05/2013 02:02 PM, Phil Race wrote:
> Since this entirely affects a 2D component, please include 2d-dev in
> this discussion.
> I wo
On 07/24/2013 03:44 PM, Helio Frota wrote:
> Hi,
>
> Another problem:
>
> configure: error: Could not find all X11 headers (shape.h Xrender.h
> XTest.h). You might be able to fix this by running 'sudo yum install
> libXtst-devel'.
> configure exiting with result code 1
>
> I did this, but the er
On 07/24/2013 04:11 PM, Helio Frota wrote:
> Hi,
>
> I got the same problem with GCC 4.8.1 and Manjaro distribution ( distro
> son of archlinux )
>
> Generating precompiled header precompiled.hpp.gch
> cc1plus: error: the "stabs" debug format cannot be used with
> pre-compiled headers [-Werror=de
Hi Steven,
On 07/03/2013 03:19 PM, Steven R. Loomis wrote:
> Omair,
> I didn't hear back from you on this list, but I will reply here with
> more details.
Sorry about the delay, I got busy with unrelated work.
> See diffs below. I would be very suspicious of how this
> could run without cras
On 08/07/2013 06:02 PM, Константин Периков wrote:
> Hi,
>
> I'm trying to build OpenJDK 8 on Arch Linux and get warnings, that crash
> compilation. Is there any flag to ignore this warnings?
I don't think there is a general flag that does this.
The only case where warnings cause the build to fai
On 08/07/2013 06:40 PM, Chris Hegarty wrote:
>
> On 7 Aug 2013, at 23:22, Omair Majid wrote:
>
>> On 08/07/2013 06:02 PM, Константин Периков wrote:
>>> Hi,
>>>
>>> I'm trying to build OpenJDK 8 on Arch Linux and get warnings, that crash
>>>
Hi,
OpenJDK fails to build with zero currently on 32 bit architectures.
There's a non-architecture-specific compilation error that I fixed [1].
That makes zero build/run on 64-bit architectures. However, the build
still fails on 32-bit. The error says that a jvm.cfg can not be found
for zero.
The
On 08/12/2013 12:51 AM, David Holmes wrote:
> Hi Omair,
>
> On 10/08/2013 1:25 AM, Omair Majid wrote:
>> Hi,
>>
>> OpenJDK fails to build with zero currently on 32 bit architectures.
>> There's a non-architecture-specific compilation error that I fixed [1].
Hi,
On 08/15/2013 12:46 AM, David Holmes wrote:
> On 14/08/2013 1:53 AM, Omair Majid wrote:
>> Updated webrev:
>> http://cr.openjdk.java.net/~omajid/webrevs/zero-jvm-config/01/
>
> That looks good to me.
I am still looking for another reviewer.
Thanks,
Omair
--
PG
On 08/21/2013 04:16 AM, Erik Joelsson wrote:
> I thought one was sufficient, but you have an OK from me too.
>
Whoops. Did I confuse the hotspot reviewer requirements with build-dev
reviewer requrirements?
Can I get a bug id?
Thanks,
Omair
> On 2013-08-20 21:32, Omair Majid wro
On 08/21/2013 10:15 AM, Erik Joelsson wrote:
> On 2013-08-21 16:03, Omair Majid wrote:
>> On 08/21/2013 04:16 AM, Erik Joelsson wrote:
>>> I thought one was sufficient, but you have an OK from me too.
>>>
>> Whoops. Did I confuse the hotspot reviewer requir
On 05/16/2013 12:12 PM, Sergey Bylokhov wrote:
> Hi, Staffan.
> Try this version: http://cr.openjdk.java.net/~serb/forest.py
> I update forest extension a little bit to work with mercurial 2.3+.
> ps: It was my first code on python.
For mercurial 2.3, maybe try this:
https://bitbucket.org/gxti/hgf
On 08/26/2013 02:52 PM, Dmitry Samersoff wrote:
> Common practice is to have generated configure.sh in source bundle, but
> don't have it in source control.
Yes, this is certainly how it was designed to be used. Autoconf itself,
for example, does this. It's source repository [1] does not contain a
On 08/28/2013 07:47 AM, Erik Joelsson wrote:
> While installing a new system I too stumbled over the help messages from
> configure and decided to try and fix them this time. I believe that
> these suggestions will actually work and cover everything.
>
> http://cr.openjdk.java.net/~erikj/8003162/w
On 09/03/2013 04:26 PM, Mike Duigou wrote:
> Hello all;
>
> The base url for the openjdk bug database was recently changed. This
> changeset ensures that webrev generates correct urls for the bugs it
> links to.
>
> http://cr.openjdk.java.net/~mduigou/JDK-8024201/0/
Something unexpected caught m
Hi,
Over in Fedora-land, we are trying to build OpenJDK (using zero) on
s390(x) [1]. One of the changes needed is updating the platform.m4 file
to teach it about s390(x). The following webrev does that:
http://cr.openjdk.java.net/~omajid/webrevs/s390-platform/00/
The patch was written by Dan Horá
On 09/05/2013 05:10 AM, Magnus Ihse Bursie wrote:
> On 2013-09-04 21:26, Omair Majid wrote:
>> Over in Fedora-land, we are trying to build OpenJDK (using zero) on
>> s390(x) [1]. One of the changes needed is updating the platform.m4 file
>> to teach it about s390(x). The follo
Hi,
On 09/05/2013 05:43 AM, Dmitry Samersoff wrote:
> It might make sense to set
>
> VAR_CPU to ESA_390
>
> VAR_CPU_ARCH to ESA_390 or ever to ESA_3xx
>
> for both s390 and s390x.
>
> s370 diverged over time to a variety of more or less compatible series
> and it's possible the same happens
On 07/24/2013 02:33 PM, Alan Bateman wrote:
> On 10/07/2013 12:01, Omair Majid wrote:
>> On 07/09/2013 03:40 AM, Erik Joelsson wrote:
>>> I would like to see a comment explaining why the option was needed. Is
>>> this a bug in gcc or has the checking just become better
On 09/09/2013 01:40 PM, Omair Majid wrote:
> On 09/05/2013 05:10 AM, Magnus Ihse Bursie wrote:
>> On 2013-09-04 21:26, Omair Majid wrote:
>>> Over in Fedora-land, we are trying to build OpenJDK (using zero) on
>>> s390(x) [1]. One of the changes needed is updating the pl
On 09/11/2013 06:22 AM, Erik Joelsson wrote:
> On 2013-09-10 22:30, Omair Majid wrote:
>> On 09/09/2013 01:40 PM, Omair Majid wrote:
>>> http://cr.openjdk.java.net/~omajid/webrevs/s390-platform/01/
>> If there are no further concerns, shall I go ahead and push?
> Loo
* Magnus Ihse Bursie [2013-11-18 13:19]:
> So, finally it has happened. The old build system is now removed.
> The patch was just submitted to the tl forest, from where it will
> move to master in a few days.
Congrats! This is fantastic news!
Cheers,
Omair
--
PGP Key: 66484681 (http://pgp.mit.
* Sean Mullan [2013-11-27 12:16]:
> On 11/27/2013 10:46 AM, Wang Weijun wrote:
> >>What security libs have j2 in their names?
> >
> >libj2gss.so etc.
>
> Any idea what the compatibility risk of removing the "2" would be?
>
> This seems less prominent because it doesn't say "j2se", "j2re" or
> "j
Hi,
The following webrevs modify the build system to allow building against
the system-installed copy of libpng as well as using the bundled copy of
libpng
ROOT: http://cr.openjdk.java.net/~omajid/webrevs/system-libpng/01/
JDK: http://cr.openjdk.java.net/~omajid/webrevs/system-libpng/01-jdk/
A n
* David Chase [2014-02-03 11:57]:
> At first I agreed with you, but after looking a little more I think I have
> been using the same one all along,
> and it just changed. Perhaps this is just an early warning. Or perhaps my
> X11 is old and stale.
There's certainly been a change in how freetyp
* Magnus Ihse Bursie [2014-02-03 14:42]:
>
> On 2014-02-03 18:43, Omair Majid wrote:
> >Hi,
> >
> >The following webrevs modify the build system to allow building against
> >the system-installed copy of libpng as well as using the bundled copy of
> >libpng
>
* Andrew Hughes [2014-02-04 19:26]:
> > On 2014-02-03 18:43, Omair Majid wrote:
> > > The following webrevs modify the build system to allow building against
> > > the system-installed copy of libpng as well as using the bundled copy of
> > > libpng
> > &
Hi,
* Magnus Ihse Bursie [2014-02-12 17:49]:
>
> On 2014-02-12 18:47, Andrew Hughes wrote:
> >>To be extremely clear: Andrew, do you object to bringing Omairs patch,
> >>as it is, into OpenJDK?
> >>
> >Yes.
>
> Okay then.
>
> I'll put a mental note to revisit libpng when cleaning up
> librarie
1 - 100 of 152 matches
Mail list logo
