For reference, with version numbers, here is what worked for me this morning,
for both release and fastdebug builds (including closed bits):
I'm on Mavericks (10.9.5),
using Xcode 4.6.3, (sudo xcode-select -s
/Applications/Xcode4.6.3.app/Contents/Developer)
MacPorts lipo (it works, put it earlier
to approach changes
> to fdlibm to work around new C compiler warnings.
>
> -Joe
>
> On 10/16/2014 6:08 PM, David Chase wrote:
>> I am more competent at modifying FP source code than I am at tinkering with
>> flags in our build system.
>> If someone else is solv
of the build
> system.
>
> Thanks,
>
> -Joe
>
> On 10/16/2014 2:37 PM, David Chase wrote:
>> Rhetorical question, actually — someone clearly did.
>> Someone also did not test it with gcc 4.8.recent on Ubuntu 14 or
>> Clang.current on Mavericks.
>>
Rhetorical question, actually — someone clearly did.
Someone also did not test it with gcc 4.8.recent on Ubuntu 14 or Clang.current
on Mavericks.
One of the offending directories is fdlibm, and I have experience with that, so
since I can’t
get anything else done, I will see about cleaning up tha
That's the same change I tested, so I (not a Reviewer) approve, except I think
the copyright needs to be 2014.
On 2014-02-04, at 5:09 AM, Magnus Ihse Bursie
wrote:
> As reported by David Chase, if the X11 include file contains an older version
> of freetype than the one detected b
On 2014-02-03, at 3:00 PM, Magnus Ihse Bursie
wrote:
> Can you please try the following patch and see if it solves your problem?
>
> diff --git a/make/lib/Awt2dLibraries.gmk b/make/lib/Awt2dLibraries.gmk
> --- a/make/lib/Awt2dLibraries.gmk
> +++ b/make/lib/Awt2dLibraries.gmk
> @@ -792,9 +792,9
On 2014-02-03, at 9:59 AM, Magnus Ihse Bursie
wrote:
> You seem to have gotten a mismatch due to several versions of freetype
> installed.
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
This is Mountain Lion, not the latest version of XCode (i.e., this has all been
working fine for months).
I just pulled, updated, configured, and tried to build and got this:
In file included from
/Users/dr2chase/work/jdk9/jdk/src/share/native/sun/font/freetypeScaler.c:34:
/usr/X11/include/ft2bu
't have.
This succeeded -- it configured properly (fastdebug), built, and the resulting
java (built minutes ago) successfully ran.
David
On 2013-09-19, at 9:22 AM, David Chase wrote:
> That did not have the desired effect on the command line tools. I do still
> have backups, but yuc
d line with "xcode-select".
>
> /Staffan
>
> On 19 sep 2013, at 14:05, David Chase wrote:
>
>> XCode 5 changed things a little:
>>
>> configure: The C compiler (located as /usr/bin/gcc) does not seem to be the
>> required GCC compiler.
>>
And more yet, after an edit and
USE_CLANG=true make images CONF=fastdebug
(note "true", not "1", plus I removed some offending flags)
It fails, for lack of symbols.
Backups are looking better than ever, and I don't recommend this upgrade quite
yet.
Making adlc
Undefined symbols for architecture
/adlparse.cpp:4476:21:
error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
So this is a bit of a mess.
David
On 2013-09-19, at 8:26 AM, David Chase wrote:
> It was not in the code I pulled from jdk8/tl this morning.
> I hacked configure to see how far
n 19.09.2013, at 16:05, David Chase wrote:
>
>> XCode 5 changed things a little:
>>
>> configure: The C compiler (located as /usr/bin/gcc) does not seem to be the
>> required GCC compiler.
>> configure: The result from running with --version was: "Configured w
XCode 5 changed things a little:
configure: The C compiler (located as /usr/bin/gcc) does not seem to be the
required GCC compiler.
configure: The result from running with --version was: "Configured with:
--prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/usr/includ
On 2013-07-23, at 7:38 PM, Tim Bell wrote:
> Hello Leonid:
>
>> Just to satisfy my curiosity: what are advantages of using clang instead of
>> gcc?
>
> I am a mere messenger here, but I am told that clang/clang++:
>
> - is command line compatible with gcc
> - is faster
> - produces better di
On 2013-06-04, at 11:22 PM, Tim Bell wrote:
> Hi Max:
>
>> I'm trying to build 32-bit openjdk on a Windows machine. My Visual Studio
>> 2010 installation includes F#,
>
> That is why the README [1] advises ''Only the C++ part of VS2010 is needed".
That's a misleading instruction, since it se
On 2013-05-28, at 11:27 PM, Tim Bell wrote:
>
> Possibly - but I tried for several days to come up with a build configuration
> that worked for both VS 2010 and 2012.
>
> I ran out of time for that experiment. Nice to have, but if we do not move
> to VS2012 with JDK8, we will have to wait un
quot;x86", not "80x86"
I tweaked my built to handle those two cases. The latest failure I have not
yet worked around:
3) Link complains about an extra argument _build_pch_file.obj when linking adlc
.
Any hints as to how to deal with this last error are welcome.
David
On 2013-05-24
FYI, progress report.
No additional changes to the build, but the instructions may require tweaking.
Did manage successful builds without closed subdirectories, using VS2012 and
DirectX 2010.
Required installation+build of Freetype using instructions from Volker's blog,
adapted slightly
for up
ld on Windows.
David
On 2013-05-24, at 6:06 AM, Erik Joelsson wrote:
> On 2013-05-24 11:41, Anthony Petrov wrote:
>> [ 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
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="$with_dxsdk_lib"
elif test "x$OPENJDK_TARGET_CPU" = "xx86_64"; then
DXSDK_LIB_PATH="$dxsdk_path/Lib/x64"
+
On 2013-05-22, at 8:44 PM, Tim Bell wrote:
> Here is a pointer to the source changes I needed to make, so far:
>
>http://cr.openjdk.java.net/~tbell/VS2012/webrev.00/
>
> You will need to run 'bash common/autoconf/autoconf.sh' after applying the
> patch from the webrev.
>
> It has also bee
o you will be able to build 32-bit only. I
> have not verified that.
>
> Tim
>
> [1] http://hg.openjdk.java.net/jdk8/awt/rev/dd1a80efa7cf
>
>
> On 05/22/13 04:27 PM, David Chase wrote:
>> I hope I'm trying to solve a simpler problem, which is just a build,
I think you need to understand the problem I'm after -- currently, our public
instructions for third-party OpenJDK (8) builds don't work.
They don't build at all, so porting is completely out of the question. I'm
trying to come up with instructions that will at least build something that
will r
I think that there is a 64-bit compiler in there, though it seems to not be the
default.
I saw three different command-line choices, and one is 64-bit, which I am using.
The available copies of the DirectX SDK (later than 2004) were not recognized
as 32-bit
by configure -- doesn't mean that they
so vaguely recall some silly thing with VS2012 that it was for Windows 8
> only and you needed VS2012sp1 to be able to build for Windows releases before
> Windows 8? I'm not sure I remember that right. :^(
>
> -kto
>
> On May 22, 2013, at 4:27 PM, David Chase wrote:
&
I hope I'm trying to solve a simpler problem, which is just a build, as if I
were someone outside Oracle playing with Openjdk. I assume my problems are a
subset of the release problem.
David
On 2013-05-22, at 6:53 PM, Kelly O'Hair wrote:
> Windows VS compilers are a pain. Each release has it
I am persisting in my attempt to compile OpenJDK 8 on Windows 7, using the
tools likely to be handy for someone outside Oracle attempting to do this,
because our existing directions are borken and need to be fixed, if possible.
I'm using VS2012, because that's what someone would normally do in 2
a real adventure:)
>
> Regards,
> Volker
>
>
>
> On Mon, May 20, 2013 at 3:04 PM, David Chase wrote:
> In addition, the instructions must note that if the Express compiler is used,
> the 64-bit compiler is (apparently, according to configure) not provided, and
> hence --with-target-bits=32 is required.
>
> David
>
>
In addition, the instructions must note that if the Express compiler is used,
the 64-bit compiler is (apparently, according to configure) not provided, and
hence --with-target-bits=32 is required.
David
On 2013-05-19, at 4:58 PM, David Chase wrote:
> #3, the DirectX 9.0 link is not maybe dead, it is dead.
> The search for "DirectX 9.0 SDK Update Summer 2004" is also dead; nothing is
> found.
> Searches for "DirectX 9" yield downloads that are not SDKs, sea
This is for Windows 7, following instructions, mostly vanilla.
I restarted after all the various installations.
I'm "following" the instructions at
http://hg.openjdk.java.net/jdk8/jdk8/raw-file/tip/README-builds.html
The non-vanilla step, inspired by the cautionary warnings about paths with
spac
A problem with gcc-4.8 as installed by MacPorts, if we ever intended to build
32-bit binaries:
gcc-mp-4.8 -O -m32 -msse -mpclmul -mavx TryLoop.c -lz
ld: warning: ignoring file /opt/local/lib/gcc48/libgcc_ext.10.5.dylib, missing
required architecture i386 in file /opt/local/lib/gcc48/libgcc_ex
Which version of MacOS? 10.8.3 is current, rumor is 10.9 is coming sometime
later this year, and we had problems obtaining boxes running 10.7 for testing
purposes. We may have a similar problem later this year; I imagine that new
Macs for testing and/or development get purchased after June, 10
Because for me it did not, at least not on a Mac.
My workaround, which was not too painful because the new build seems to use
fully-qualified path names:
touch jdk/src/share/native/java/util/zip/CRC32.c
make images CONF=macosx-x86_64-normal-server-slowdebug LOG=debug
...
touch jdk/src/share/nat
On 2013-04-29, at 5:49 AM, Erik Joelsson wrote:
>>
>> So, do we call this a bug?
>> And assuming we do, it needs fixing in hotspot, jdk, and root, right?
>>
> Yes, and possibly some closed repos too (deploy). A comment on why the
> seemingly redundant macro is added would be good too.
I take
Related bugs: 8008451, 8005879
This may generalize to new build as well, but I have not tested that.
Apparently, when you pass " -mmacosx-version-min=..." to gcc on the Mac,
it quietly generates a definition for MAC_OS_X_VERSION_MIN_REQUIRED .
Parfait (1.1) doesn't know about this trick (why sh
still had the space at the end of the line. Doh!
>
> Thanks for helping out.
>
> David
>
> On 13/04/2013 11:24 PM, David Chase wrote:
>>
>> On 2013-04-12, at 7:00 PM, David Holmes wrote:
>>>
>>> Thanks for the sanity check.
>>>
>>> T
On 2013-04-12, at 7:00 PM, David Holmes wrote:
>
> Thanks for the sanity check.
>
> This implies to me that either
>
> a) it is a phase 1 versus phase 2 issue, but given the content of spec.gmk I
> can't see how that can be the case; or
>
> b) the value of something is not what I naively thi
Sanity check -- this is make 3.81, right?
I checked on both MacOS 10.8 and Ubuntu
Because (as is always the case) "it works for me":
--
JVM_VARIANT_SERVER := true
JVM_VARIANT_CLIENT := true
CLIENT_AND_SERVER1 := $(and $(findstring true, $(JVM_VARIANT_SERVER)),
$(findstring true, $(JVM
Getting to new build on Solaris11-sparc (not necessary for Solaris11-x86).
Here's a recipe that works. It is biased towards modern releases of software.
Note the use of undocumented flag-seting to configure and make at various steps,
and the two out-of-band adjustments to binutils.
1) configure+
On 2013-03-27, at 1:08 PM, Volker Simonis wrote:
> Hi David,
>
> I found a Solaris 11 box today and it seems that this is really a problem of
> binutils 2.19 on Solaris 11.
And vice-versa -- 10 minutes ago I tried gobjcopy 2.15 on the command line (on
Solaris 11, with the same libjvm.so) and
It led to an ugly failure (see below).
I took it off my path, cleaned, configured, and the build (so far) went better.
I checked the version it was picking up, and it was 3.16.
So configure might want to check for this.
(Why is this crap on my path? I no longer remember, it has been there for
alm
PATH=/java/devtools/sparc/bin:/java/devtools/sparc/SUNWspro/SS12u1/bin/:/usr/sfw/bin:/usr/ccs/bin:/home/drchase/bin:/pkg/gnu/bin:/pkg/isv/bin:/pkg/usrdist/bin:/pkg/local/bin:/lab/tools/bin:/lab/east/bin:/usr/bin:/bin
uname -a = SunOS dr-evil 5.10 Generic_142900-03 sun4v sparc SUNW,Sun-Fire-T1000
m
ists all members of the
archive.
David
On 2013-03-26, at 10:40 PM, David Holmes wrote:
> On 27/03/2013 2:33 AM, David Chase wrote:
>> I think I'm doing a vanilla new-build, but obviously I'm not, because it
>> fails.
>> What should I be looking for?
More non-clues. I did a make JOBS=1 LOG=debug, and then reproduced the
creation step with cut and paste:
/java/devtools/sparc/SUNWspro/SS12u1/prod/bin/CC -m64 -xarch=sparc
-library=%none -mt -G -norunpath -z noversion -M mapfile_extended -h libjvm.so
-o libjvm.so JvmOffsets.o (many lines omitt
2**0
> CONTENTS, ALLOC, LOAD, DATA
> 21 .bss 000778a8 01d3ed38 01d3ed38 01c3ed38 2**3
> ALLOC
> 22 .comment 18d3 02477133 2**0
> CONTENTS, READONLY
> 23 .g
ion 1, dynamically
linked, not stripped
What sort of "file" is your libjvm.so?
David
On 2013-03-26, at 2:00 PM, Volker Simonis wrote:
> On Tue, Mar 26, 2013 at 6:43 PM, David Chase wrote:
>>
>> This is Solaris 11, not sure if that matters (configure didn't seem t
This is Solaris 11, not sure if that matters (configure didn't seem to think it
was important enough to mention it).
cmp says /usr/{sfw,ccs}/bin/gobjcopy are equal.
ls says they are the same inode.
Just for grins, I tried putting /usr/sfw/bin earlier in my path, and trying
again (reconfiguring
I think I'm doing a vanilla new-build, but obviously I'm not, because it fails.
What should I be looking for?
the failure:
Linking vm...
ld: warning: symbol '__JvmOffsets' has differing types:
(file JvmOffsets.o type=OBJT; file dtrace.o type=FUNC);
ld: warning: symbol 'CodeCache::_heap' h
I was just browsing through, to be sure I was going to set the knobs right for
some performance testing, and noticed no mention of the repository I had to
clone last night.
David
On 2013-03-15, at 5:17 PM, David DeHaven wrote:
> It's not installed by default, and I'm not sure why you'd want to since Apple
> provides it. But if it's there that could be a concern.
If you install subversion, you get file, and there are other things that (if
installed) will pull in subver
For reference, I build on Mountain Lion, with latest XCode, recent XQuartz, and
some MacPorts.
"grep opt/local config.log" produces:
configure:6295: result: /opt/local/bin/gsed
configure:8107: found /opt/local/bin/port
configure:10420: found /opt/local/bin/pkg-config
configure:10432: result: /op
see:
>
> + $(GENSRC_X11WRAPPERS_TMP)/sizer.$*.exe | $(SORT) > $@.tmp
>
> but this:
>
> +long 4
> +int 4
> +short 2
> +ptr 4
> +Bool 4
> +Atom 4
> +Window 4
> +XExtData.number 0
> ...
>
> does not appear sorted to me.
>
> David H.
> -
On 2013-01-25, at 4:55 PM, Kelly O'Hair wrote:
> Please file JBS Issues.
So this is a new bug that needs filing? I think it's sort of a duplicate, see
below.
> And keep in mind every "Solaris 10" system could be different.
Solaris 10 10/09 s10x_u8wos_08a X86
Builds with jdk8, fails with jdk
I'm trying new-build on a Solaris 10 box, and it goes okay till this comparison:
COMPARING
/export/drchase/jdk8tl/build/solaris-x86_64-normal-server-fastdebug/jdk/gensrc_x11wrappers/sizer/sizes.64
and
/export/drchase/jdk8tl/jdk/src/solaris/classes/sun/awt/X11/generator/sizes.64-solaris-i386
The t
Just a nit, but configure is quite happy to use the PATH environment variable,
not that it mentions this anywhere in the output of "sh configure help". Yes,
I know that PATH is implicit, yes, I know that I am complaining about Unix
documentation, yes I know that the new build system is in fact
On 2013-01-13, at 7:17 PM, David Holmes wrote:
> David,
>
> I could be mistaken but I thought the use of CXX= was intended as a make
> variable to override the value that configure places in the spec.gmk file -
> not as a way to force configure to output something to spec.gmk.
It's entirely
Problem solved: /Developer consider harmful, at least on Mountain Lion.
Removing that and using the compilers installed by XCode in /usr/bin did the
trick.
HOWEVER - it seems dubious to me that configure should ignore the environment
specification of CXX.
I tried the following,
where /usr/local
On 2013-01-10, at 3:56 AM, Staffan Larsen wrote:
> See: http://bugs.sun.com/view_bug.do?bug_id=8004490
>
> Patch: http://hg.openjdk.java.net/jdk8/build/rev/2d9bb72b4e34
>
> /Staffan
I tried the workaround in this patch, and it did not seem to result in a
debuggable hotspot.
I also tried the
On 2013-01-09, at 5:26 PM, Kelly O'Hair wrote:
> Question 1: What specific forest did you get your sources from?
>
> -kto
>> I configured jdk8tl in common/makefiles,
default = http://hg.openjdk.java.net/jdk8/tl
>> Then in hotspot-comp, I also configure for slowdebug, and
default = http://hg
Summary: I wanted to debug, I configured thoroughly with slowdebug, but was not
able to debug the result.
More detailed:
I configured jdk8tl in common/makefiles,
sh ../autoconf/configure --with-debug-level=slowdebug
cleaned, and then built:
make CONF=macosx-x86_64-normal-server-slowdebug imag
On 2013-01-09, at 5:07 AM, Michael McMahon wrote:
> Are you building on a remote filesystem like NFS? Those .DS_Store files get
> created by the finder
> and can cause problems on remote filesystems where they become visible to
> other software.
>
> There is a way to disable creation of .DS_S
I had a failure building on a Mac (Mountain Lion, 10.8.2), both new build and
old build, at this step:
/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/bin/java
-XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput
-Djava.awt.headless=true -Xmx512m -Xms512m -X
>
> New build worked last time I tried it; I will try again after sending this
> email.
New build (jdk8tl) confirmed to (still) work on MacOS 10.8.2 with recent
Developer Tools and XQuartz.
(I got as far as running a properties-printer with the built system.)
David
On 2013-01-07, at 2:41 PM, Kelly O'Hair wrote:
> If someone could document everything that was done to get this working I
> would appreciate it.
>
> We have a bunch of 10.8 macs that we need to figure out how to get them to
> build the jdk for 10.7
> or we have to come up with a better answer
On 2012-12-27, at 7:41 AM, mikhail cherkasov
wrote:
> I have installed all software from the following list:
> http://wiki.se.oracle.com/display/JPG/Build+JDK+on+Mac+OS+X#BuildJDKonMacOSX-System
> I not sure about X11 -does it require separate installation?
Yes, X11 requires separate installat
Would it make sense to use "$@" instead of $* in the argument expansion?
This occurs in get_source.sh, also in the new hgforest.sh.
The use of "$@" I believe preserves the command line argument parsing:
Assume this is script "asdf":
#!/bin/bash
echo quote-dollar-at-quote
for i in "$@" ; do
ech
I'm working with a newly configured Linux box, trying the new build system, and
I think I ran into some glitches (that I worked around).
The box (uname -a)
Linux bran 2.6.39-200.24.1.el6uek.x86_64 #1 SMP Sat Jun 23 02:39:07 EDT 2012
x86_64 x86_64 x86_64 GNU/Linux
Before doing much work, I had
69 matches
Mail list logo
