This patch adds support for compiling and linking against a specific
dxsdk to the new build. This was omitted by mistake during the
conversion from the old build.
This patch adds three new configure parameters:
--with-dxsdk
--with-dxsdk-lib
--with-dxsdk-include
The latter two are constructed
On 2013-02-20 15:20, Erik Joelsson wrote:
Adding check for SKIP_BOOT_CYCLE=false in Jprt.gmk which adds the
target bootcycle-images. Also fixing an issue with bootcycle-images
target that prevented them from creating images.
http://cr.openjdk.java.net/~erikj/8006828/webrev.root.01/
http://c
Erik:
Looks good.
Tim
This patch adds support for compiling and linking against a specific
dxsdk to the new build. This was omitted by mistake during the
conversion from the old build.
This patch adds three new configure parameters:
--with-dxsdk
--with-dxsdk-lib
--with-dxsdk-include
The l
On 05/03/2013 15:14, Erik Joelsson wrote:
:
Discovered some more problems with the bootcycle-images target that
needed to be fixed. A full bootcycle build is still not possible due
to errors like this:
/localhome/mercurial/closed-jdk8-build/jdk/make/tools/src/build/tools/javazic/GenDoc.java:
I've been meaning to ask this for a while but is --with-zlib=system
supposed to work?
With the old build then there is a build variable to use the system zlib
but it only worked (to my knowledge) when doing dynamic linking of C++
runtime.
Attached is what I get currently and maybe we have
I just tried it on my machine (Ubuntu 10.10) and it works. I can imagine
it being sensitive to the exact version of zlib on the system though.
Doing this, my resulting libzip.so is linked against the system libz:
$ ldd images/j2sdk-image/jre/lib/amd64/libzip.so
libz.so.1 => /lib/libz.so.1 (
Thanks.
Pushed to /hg/jdk8/tl.
(only tested on Linux)
On Mon, Mar 4, 2013 at 11:45 PM, Erik Joelsson wrote:
> **
> On 2013-03-04 23:55, Martin Buchholz wrote:
>
>
>
> On Mon, Mar 4, 2013 at 3:34 AM, Erik Joelsson wrote:
>
>> Thanks for the suggestion Martin!
>>
>> I created 8009376 for this and
Martin, Erik,
On 6/03/2013 7:19 AM, Martin Buchholz wrote:
Thanks.
Pushed to /hg/jdk8/tl.
There has to be a corresponding push of the update to closed
generated-configure.sh. This will now break all non OPENJDK builds.
David
(only tested on Linux)
On Mon, Mar 4, 2013 at 11:45 PM, Erik Jo
Martin,
A couple of points of order here
On 6/03/2013 7:19 AM, Martin Buchholz wrote:
Thanks.
Pushed to /hg/jdk8/tl.
You needed to have a jdk8 Reviewer listed for this change. Erik is a
Committer not Reviewer.
(only tested on Linux)
I sincerely hope Erik tested on Windows, BSD and Solar
Oh dear.
Please add in a fixup change if required.
On Tue, Mar 5, 2013 at 1:44 PM, David Holmes wrote:
> Martin, Erik,
>
> On 6/03/2013 7:19 AM, Martin Buchholz wrote:
>
>> Thanks.
>> Pushed to /hg/jdk8/tl.
>>
>
> There has to be a corresponding push of the update to closed
> generated-configure.
On Tue, Mar 5, 2013 at 1:53 PM, David Holmes wrote:
>
> You needed to have a jdk8 Reviewer listed for this change. Erik is a
> Committer not Reviewer.
>
>
That's not obvious. Isn't it jcheck's job to make sure any required
approvals are in?
I should have included more eyeball names on the Reviewe
On 6/03/2013 8:24 AM, Martin Buchholz wrote:
On Tue, Mar 5, 2013 at 1:53 PM, David Holmes mailto:[email protected]>> wrote:
You needed to have a jdk8 Reviewer listed for this change. Erik is a
Committer not Reviewer.
That's not obvious. Isn't it jcheck's job to make sure any requ
On Tue, Mar 5, 2013 at 2:36 PM, David Holmes wrote:
>
> Sorry but that is completely unacceptable. If you are providing changes
> that obviously impact multiple platforms (ie there are platform specific
> changes) then they _must_ be tested on all platforms. If the external
> author/committer can
On 6/03/2013 9:17 AM, Martin Buchholz wrote:
On Tue, Mar 5, 2013 at 2:36 PM, David Holmes mailto:[email protected]>> wrote:
Sorry but that is completely unacceptable. If you are providing
changes that obviously impact multiple platforms (ie there are
platform specific change
On Tue, Mar 5, 2013 at 3:30 PM, David Holmes wrote:
> On 6/03/2013 9:17 AM, Martin Buchholz wrote:
>
>>
>> IMO the right approach is to improve processes so that bad commits don't
>> cause other developers to lose time. Once upon a time, I was actually
>> the tl gatekeeper and I implemented such
On 6/03/2013 9:44 AM, Martin Buchholz wrote:
On Tue, Mar 5, 2013 at 3:30 PM, David Holmes wrote:
On 6/03/2013 9:17 AM, Martin Buchholz wrote:
IMO the right approach is to improve processes so that bad commits don't
cause other developers to lose time. Once upon a time, I was actually
the
On 6/03/2013 10:52 AM, Martin Buchholz wrote:
On Tue, Mar 5, 2013 at 4:36 PM, David Holmes mailto:[email protected]>> wrote:
I disagree. The submitter should be responsible for the "right"
amount of
upfront testing.
Now you are confusing me :) You disagree b
On Tue, Mar 5, 2013 at 4:36 PM, David Holmes wrote:
>
>>> I disagree. The submitter should be responsible for the "right" amount
>> of
>> upfront testing.
>>
>
> Now you are confusing me :) You disagree but say the responsibility is on
> the submitter. Well I certainly agree with that! Our diffe
We need to regenerate the open and closed configure scripts in the tl
forest.
The open change is trivial as it just updates the timestamp:
> hg diff
diff -r c4901c0e0579 common/autoconf/generated-configure.sh
--- a/common/autoconf/generated-configure.sh
+++ b/common/autoconf/generated-configur
2013/3/5 11:39 -0800, [email protected]:
> We need to regenerate the open and closed configure scripts in the tl
> forest.
>
> The open change is trivial as it just updates the timestamp:
>
>> hg diff
> diff -r c4901c0e0579 common/autoconf/generated-configure.sh
> --- a/common/autoconf/gen
20 matches
Mail list logo
