On 2013-11-02 16:14, Daniel D. Daugherty wrote:
> The Gnu make version is 4.0,
I'm pretty sure the OpenJDK builds don't work on any version of
GNUMake newer than 3.81. Checkout this version:
Actually, we have been using 3.81, 3.82 and 3.82.* for a long while
depending on platform. We recently
This seems to be make 4.0 specific. I saw the same error when trying a
home built make 4.0 on Solaris the other day (for a completely different
reason so I didn't pursue the problem).
We will investigate.
/Erik
On 2013-11-02 08:30, Henry Jen wrote:
What I don't understand(misleading me) is th
New webrev posted: http://cr.openjdk.java.net/~erikj/8027698/webrev.jdk.02/
Addressed all comments below. I must have missed the save button before
generating the webrev when adding ucrypto.jar, but it's there now at least.
/Erik
On 2013-11-02 01:35, Bradford Wetmore wrote:
On 11/1/2013 3:
Looks good to me.
I would vote for doing this now.
/Erik
On 2013-10-30 15:22, Magnus Ihse Bursie wrote:
I have started working on removing the old build system. See
https://bugs.openjdk.java.net/browse/JDK-8027566.
I plan do to this in several steps. I have not decided wether to
commit thes
Looks correct, but needs to be compared on all platforms.
/Erik
On 2013-11-01 14:43, Magnus Ihse Bursie wrote:
Here is part 2 of the old build system removal.
This review is based against the previous part, i.e. where the lion's
share of the old make files had been removed.
What remained wa
Here is the final part of the patch to remove the old build system.
(I'll get back with a comprehensive review showing all changes, when the
fix is cleared for inclusion in JDK8.)
This time, I've basically moved the files from "makefiles" to "make",
and updated paths correspondingly.
Apart f
> Unfortunately, WebRev is not very intelligent at presenting these changes.
> :-( I have made modifications to files that I have also moved, but WebRev
> just lists these files as "New" without any reference or diff with the
> original file. I don't know if if is possible to get an improved be
I had this problem recently and I don't think you need restore the files
- just the directory.
I used hg mv to relocate the files but because *all* files were moved out
of the directory so hg deleted the directory. It was sufficient to
mkdir again for webrev to properly recognise the files as
Hello --
Are there any known issues with msvcr100.dll when building OpenJDK8 on Windows
8.1 Pro? Using the setup below, the configure script fails with the following
msvcr100.dll-related errors:
(1) configure: The file type of the located msvcr100.dll is PE32+ executable
for MS Windows (DLL)
You can probably use hg mv -A too, then webrev should pick it up whatever
mercurial prepared in the change set.
Cheers,
Mario
Il 04/nov/2013 18:46 "Phil Race" ha scritto:
> I had this problem recently and I don't think you need restore the files -
> just the directory.
> I used hg mv to relocate
Hi Erik,
Thanks for the update! Looks good, but one minor comment:
SignJars.gmk
78:100:106:111-116 > 80 chars per line.
Brad
On 11/4/2013 2:19 AM, Erik Joelsson wrote:
New webrev posted: http://cr.openjdk.java.net/~erikj/8027698/webrev.jdk.02/
Addressed all comments below.
Changeset: d425685e0b74
Author:cl
Date: 2013-10-31 12:36 -0700
URL: http://hg.openjdk.java.net/jdk8/build/corba/rev/d425685e0b74
Added tag jdk8-b114 for changeset 0bbccf77c23e
! .hgtags
Changeset: ddc3758f68db
Author:cl
Date: 2013-10-31 12:36 -0700
URL: http://hg.openjdk.java.net/jdk8/build/hotspot/rev/ddc3758f68db
Added tag jdk8-b114 for changeset 7fd913010dbb
! .hgtags
Changeset: d3b6da1b3e25
Author:cl
Date: 2013-10-31 12:36 -0700
URL: http://hg.openjdk.java.net/jdk8/build/jaxp/rev/d3b6da1b3e25
Added tag jdk8-b114 for changeset 1b1e12117fe2
! .hgtags
Changeset: e126d8eca69b
Author:cl
Date: 2013-10-31 12:36 -0700
URL: http://hg.openjdk.java.net/jdk8/build/jaxws/rev/e126d8eca69b
Added tag jdk8-b114 for changeset 9ad289610fc6
! .hgtags
Changeset: 62982664dc72
Author:cl
Date: 2013-10-31 12:36 -0700
URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/62982664dc72
Added tag jdk8-b114 for changeset f26a0c8071bd
! .hgtags
Changeset: fea486d30d41
Author:cl
Date: 2013-10-31 12:36 -0700
URL: http://hg.openjdk.java.net/jdk8/build/langtools/rev/fea486d30d41
Added tag jdk8-b114 for changeset 850d2602ae98
! .hgtags
Changeset: f109bb255b80
Author:cl
Date: 2013-10-31 12:36 -0700
URL: http://hg.openjdk.java.net/jdk8/build/nashorn/rev/f109bb255b80
Added tag jdk8-b114 for changeset 79f7b79bf97b
! .hgtags
Changeset: b65d48f6938a
Author:cl
Date: 2013-10-31 12:36 -0700
URL: http://hg.openjdk.java.net/jdk8/build/rev/b65d48f6938a
Added tag jdk8-b114 for changeset 4f2011496393
! .hgtags
Hi
Using a fresh copy of the jdk7u repository, and running make -d sanity, I got
the error below. Why OUTPUTDIR must be absolute or if it must be absolute, why
it is not when running make sanity?
It seems to me that OUTPUTDIR is computed in the jdk subdirectory makefiles
while it is not in t
On Nov 4 2013, at 21:39 , Francis ANDRE
wrote:
> Hi
>
> Using a fresh copy of the jdk7u repository, and running make -d sanity, I got
> the error below. Why OUTPUTDIR must be absolute or if it must be absolute,
> why it is not when running make sanity?
In general, using absolute paths alway
Yes, GNU make 4.0 change the format of MFLAGS so that there is no longer
space between -I and folder.
Cheers,
Henry
On 11/04/2013 01:38 AM, Erik Joelsson wrote:
This seems to be make 4.0 specific. I saw the same error when trying a
home built make 4.0 on Solaris the other day (for a completel
22 matches
Mail list logo
