Re: RFR: 8278885: Remove Windows ARM64 int8_t workaround in G1

[Martijn Verburg]

On Thu, 16 Dec 2021 23:44:55 GMT, aamarsh  wrote:

> Please review this small change to revert a previous workaround that avoided 
> an MSVC issue. 
> 
> This issue has now been fixed in VS 16.8 and higher. 
> 
> I also updated some documentation to reflect this change.

> /sponser

I think it's _sponsor_

-

PR: https://git.openjdk.java.net/jdk/pull/6872

Re: Building OpenJDK 1.8 on Solaris SPARC 10 fails with compiler error

[Martijn Verburg]

Hi Matthias,

We're building Solaris builds from the same source over at
https://adoptopenjdk.net - feel free to use those binaries (
https://adoptopenjdk.net/releases.html#sparcv9_solaris) and/or our build
scripts (github.com/adoptopenjdk/openjdk-build).  When there are genuine
upstream fixes to the build scripts, we send patches upstream to here
(OpenJDK proper), but mostly it's configuring things just so :-).

Cheers,
Martijn


On Thu, 23 May 2019 at 11:39, David Holmes  wrote:

> Hi Matthias,
>
> Disabling "warnings are errors" may let you compile okay, perhaps even
> with 12.6. But you're really on your own at that point. There may be
> other issues beyond simple warnings.
>
> Good luck. :)
>
> David
>
> On 23/05/2019 7:31 pm, Matthias Apitz wrote:
> >
> > Hello David,
> >
> > Thanks for the quick reply and hints.
> >
> > El día jueves, mayo 23, 2019 a las 07:19:21p. m. +1000, David Holmes
> escribió:
> >
> >>> Based on the source openjdk-8u40-src-b25-10_feb_2015.zip we do the
> following steps:
> >>
> >> Why such old sources? You are better off getting the latest released 8u
> >> source.
> >
> > I was told that this was the latest version, we will look better.
> >
> >> You can't build JDK 8u with Solaris Studio 12.6, it's too recent and
> >> will complain about too many issues in the code. The supported 8u
> >> compiler is 12.1
> >>
> >> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
> >
> > Seems that the latest available version on oracle.com is 12.3. We
> > will give this a try.
> >
> > Re/ the 12.6 I helped me with this small change:
> >
> > diff -c hotspot/make/solaris/makefiles/adlc.make*
> > *** hotspot/make/solaris/makefiles/adlc.makeThu May 23 11:17:53 2019
> > --- hotspot/make/solaris/makefiles/adlc.make.orig   Wed Feb 11
> > 02:08:09 2015
> > ***
> > *** 74,80 
> ># CFLAGS_WARN holds compiler options to suppress/enable warnings.
> ># Compiler warnings are treated as errors
> >ifeq ($(shell expr $(COMPILER_REV_NUMERIC) \>= 509), 1)
> > !   CFLAGS_WARN = +w
> >endif
> >CFLAGS += $(CFLAGS_WARN)
> >
> > --- 74,80 
> ># CFLAGS_WARN holds compiler options to suppress/enable warnings.
> ># Compiler warnings are treated as errors
> >ifeq ($(shell expr $(COMPILER_REV_NUMERIC) \>= 509), 1)
> > !   CFLAGS_WARN = +w -errwarn
> >endif
> >CFLAGS += $(CFLAGS_WARN)
> >
> > This let compile the source in question, but we stop here and move over
> > to 12.3
> >
> > Thanks again
> >
> >   matthias
> >
> >
> >
>

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

[Martijn Verburg]

Hi Kim,

I like this initiative.  I'm wondering if some of these rules can be easily
codified or written into a jcheck style checker (ccheck?) so that Authors
can adhere to the conventions and not rely on a Human review to pick out
where that convention isn't met.

Cheers,
Martijn


On Wed, 3 Oct 2018 at 20:13, Kim Barrett  wrote:

> I've submitted a JEP for
>
> (1) enabling the use of C++14 Language Features when building the JDK,
>
> (2) define a process for deciding and documenting which new features
> can be used or are forbidden in HotSpot code,
>
> (3) provide an initial list of permitted and forbidden new features.
>
> https://bugs.openjdk.java.net/browse/JDK-8208089
>
>

Re: Syntax error with set-vs-env.sh: - building jdk8u on Windows (cygwin)

[Martijn Verburg]

Hi Magnus,

Not sure if this helps but we had a `\M` char in our PATH setting via
ansible (to indicate that we wanted the PATH set as a system env).  We came
to the conclusion that we actually want the path set in user space on our
hosts and so we happily removed that `\M`.

Cheers,
Martijn


On Wed, 19 Sep 2018 at 09:00, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> On 2018-09-17 14:13, Martijn Verburg wrote:
> > Hi Erik,
> >
> > Thanks for the info, inside that shell script we noticed the
> concatenation
> > of PATH with whatever the host already had got corrupted (because of the
> > way we set it).  We've fixed our ansible scripts locally and the build is
> > now going through again.
> Good that you could solve it.
>
> If you have any suggestions on how to make the script more robust in
> case other users have a PATH like yours, I'm all ears.
>
> /Magnus
>
> >
> > Cheers,
> > Martijn
> >
> >
> > On Fri, 14 Sep 2018 at 18:11, Erik Joelsson 
> > wrote:
> >
> >> That code was rather recently touched in 8u when backporting support for
> >> devkits and newer versions of Visual Studio. What is the contents of the
> >> generated set-vs-env.sh?
> >>
> >> /Erik
> >>
> >>
> >> On 2018-09-14 05:29, Martijn Verburg wrote:
> >>> Hi all,
> >>>
> >>> AdoptOpenJDK recently started seeing this error (full configure details
> >>> below the horizontal), has anyone else experienced this:
> >>>
> >>> configure: Setting extracted environment variables
> >>>
> >>
> /cygdrive/c/cygwin64/tmp/tmp.wVFLippfrz/workspace/build/src/build/windows-x86_64-normal-server-release/vs-env/
> >>> syntax error near unexpected token `('
> >>>
> >>
> /cygdrive/c/cygwin64/tmp/tmp.wVFLippfrz/workspace/build/src/build/windows-x86_64-normal-server-release/vs-env/set-vs-env.sh:
> >>> line 2: `VS_INCLUDE="C:\Program Files (x86)\Microsoft Visual Studio
> >>> 10.0\VC\INCLUDE;C:\Program Files (x86)\Microsoft Visual Studio
> >>> 10.0\VC\ATLMFC\INCLUDE;C:\Program Files (x86)\Microsoft
> >>> SDKs\Windows\v7.0A\include; "'
> >>> configure exiting with result code 2
> >>>
> >>> Looks like a typical shell expansion bug but it's only recently cropped
> >> up.
> >>> 
> >>>
> >>>
> >>
> [C:\Users\jenkins\workspace\build-scripts\jobs\jdk8u\jdk8u-windows-x64-hotspot]
> >>> Running shell script
> >>> + ./build-farm/make-adopt-build-farm.sh
> >>> BUILD TYPE:
> >>> VERSION: jdk8u
> >>> ARCHITECTURE x64
> >>> VARIANT: hotspot
> >>> OS: windows
> >>> Detecting boot jdk for: jdk8u
> >>> Found build version: 8
> >>> Boot jdk version: 7
> >>> Boot jdk: /cygdrive/c/openjdk/jdk7
> >>> Filename will be: OpenJDK8U_x64_windows_hotspot_2018-09-14-10-51.zip
> >>> Starting
> >>>
> >>
> /cygdrive/c/Users/jenkins/workspace/build-scripts/jobs/jdk8u/jdk8u-windows-x64-hotspot/build-farm/../makejdk-any-platform.sh
> >>> to configure, build (Adopt)OpenJDK binary
> >>> Working dir is ./build/
> >>> # 
> >>> # OPENJDK BUILD CONFIGURATION:
> >>> # 
> >>> BUILD_CONFIG[BRANCH]="dev"
> >>>
> >>
> BUILD_CONFIG[BUILD_FULL_NAME]="cygwin_nt-6.1-x86_64-normal-server-release"
> >>> BUILD_CONFIG[BUILD_VARIANT]=""
> >>> BUILD_CONFIG[CLEAN_DOCKER_BUILD]="false"
> >>> BUILD_CONFIG[CLEAN_GIT_REPO]="true"
> >>> BUILD_CONFIG[CONFIGURE_ARGS_FOR_ANY_PLATFORM]=""
> >>> BUILD_CONFIG[CONTAINER_NAME]="openjdk_container"
> >>> BUILD_CONFIG[COPY_MACOSX_FREE_FONT_LIB_FOR_JDK_FLAG]="false"
> >>> BUILD_CONFIG[COPY_MACOSX_FREE_FONT_LIB_FOR_JRE_FLAG]="false"
> >>> BUILD_CONFIG[DOCKER]="docker"
> >>> BUILD_CONFIG[DOCKER_FILE_PATH]=""
> >>> BUILD_CONFIG[DOCKER_SOURCE_VOLUME_NAME]="openjdk-source-volume"
> >>> BUILD_CONFIG[FREETYPE]="true"
> >>> BUILD_CONFIG[FREETYPE_DIRECTORY]=""
> >>> BUILD_CONFIG[FREETYPE_FONT_BUILD_TYPE_PARAM]=""
> >>> BUILD_CONFIG[FREETYPE_FONT_VERSION]="2.4.0"
> >>> BUILD_CONFIG[JDK_BOOT_DIR]="/cygdrive/c

Re: Syntax error with set-vs-env.sh: - building jdk8u on Windows (cygwin)

[Martijn Verburg]

Hi Erik,

Thanks for the info, inside that shell script we noticed the concatenation
of PATH with whatever the host already had got corrupted (because of the
way we set it).  We've fixed our ansible scripts locally and the build is
now going through again.

Cheers,
Martijn


On Fri, 14 Sep 2018 at 18:11, Erik Joelsson 
wrote:

> That code was rather recently touched in 8u when backporting support for
> devkits and newer versions of Visual Studio. What is the contents of the
> generated set-vs-env.sh?
>
> /Erik
>
>
> On 2018-09-14 05:29, Martijn Verburg wrote:
> > Hi all,
> >
> > AdoptOpenJDK recently started seeing this error (full configure details
> > below the horizontal), has anyone else experienced this:
> >
> > configure: Setting extracted environment variables
> >
> /cygdrive/c/cygwin64/tmp/tmp.wVFLippfrz/workspace/build/src/build/windows-x86_64-normal-server-release/vs-env/
> > syntax error near unexpected token `('
> >
> /cygdrive/c/cygwin64/tmp/tmp.wVFLippfrz/workspace/build/src/build/windows-x86_64-normal-server-release/vs-env/set-vs-env.sh:
> > line 2: `VS_INCLUDE="C:\Program Files (x86)\Microsoft Visual Studio
> > 10.0\VC\INCLUDE;C:\Program Files (x86)\Microsoft Visual Studio
> > 10.0\VC\ATLMFC\INCLUDE;C:\Program Files (x86)\Microsoft
> > SDKs\Windows\v7.0A\include; "'
> > configure exiting with result code 2
> >
> > Looks like a typical shell expansion bug but it's only recently cropped
> up.
> >
> > 
> >
> >
> [C:\Users\jenkins\workspace\build-scripts\jobs\jdk8u\jdk8u-windows-x64-hotspot]
> > Running shell script
> > + ./build-farm/make-adopt-build-farm.sh
> > BUILD TYPE:
> > VERSION: jdk8u
> > ARCHITECTURE x64
> > VARIANT: hotspot
> > OS: windows
> > Detecting boot jdk for: jdk8u
> > Found build version: 8
> > Boot jdk version: 7
> > Boot jdk: /cygdrive/c/openjdk/jdk7
> > Filename will be: OpenJDK8U_x64_windows_hotspot_2018-09-14-10-51.zip
> > Starting
> >
> /cygdrive/c/Users/jenkins/workspace/build-scripts/jobs/jdk8u/jdk8u-windows-x64-hotspot/build-farm/../makejdk-any-platform.sh
> > to configure, build (Adopt)OpenJDK binary
> > Working dir is ./build/
> > # 
> > # OPENJDK BUILD CONFIGURATION:
> > # 
> > BUILD_CONFIG[BRANCH]="dev"
> >
> BUILD_CONFIG[BUILD_FULL_NAME]="cygwin_nt-6.1-x86_64-normal-server-release"
> > BUILD_CONFIG[BUILD_VARIANT]=""
> > BUILD_CONFIG[CLEAN_DOCKER_BUILD]="false"
> > BUILD_CONFIG[CLEAN_GIT_REPO]="true"
> > BUILD_CONFIG[CONFIGURE_ARGS_FOR_ANY_PLATFORM]=""
> > BUILD_CONFIG[CONTAINER_NAME]="openjdk_container"
> > BUILD_CONFIG[COPY_MACOSX_FREE_FONT_LIB_FOR_JDK_FLAG]="false"
> > BUILD_CONFIG[COPY_MACOSX_FREE_FONT_LIB_FOR_JRE_FLAG]="false"
> > BUILD_CONFIG[DOCKER]="docker"
> > BUILD_CONFIG[DOCKER_FILE_PATH]=""
> > BUILD_CONFIG[DOCKER_SOURCE_VOLUME_NAME]="openjdk-source-volume"
> > BUILD_CONFIG[FREETYPE]="true"
> > BUILD_CONFIG[FREETYPE_DIRECTORY]=""
> > BUILD_CONFIG[FREETYPE_FONT_BUILD_TYPE_PARAM]=""
> > BUILD_CONFIG[FREETYPE_FONT_VERSION]="2.4.0"
> > BUILD_CONFIG[JDK_BOOT_DIR]="/cygdrive/c/openjdk/jdk7"
> > BUILD_CONFIG[JDK_PATH]="j2sdk-image"
> > BUILD_CONFIG[JRE_PATH]="j2re-image"
> > BUILD_CONFIG[JVM_VARIANT]="server"
> > BUILD_CONFIG[KEEP_CONTAINER]="false"
> > BUILD_CONFIG[MAKE_ARGS_FOR_ANY_PLATFORM]=""
> > BUILD_CONFIG[MAKE_COMMAND_NAME]="make"
> > BUILD_CONFIG[NUM_PROCESSORS]="1"
> > BUILD_CONFIG[OPENJDK_BUILD_NUMBER]=""
> > BUILD_CONFIG[OPENJDK_CORE_VERSION]="jdk8"
> > BUILD_CONFIG[OPENJDK_FOREST_NAME]="jdk8u"
> > BUILD_CONFIG[OPENJDK_SOURCE_DIR]="src"
> > BUILD_CONFIG[OPENJDK_UPDATE_VERSION]=""
> > BUILD_CONFIG[OS_ARCHITECTURE]="x86_64"
> > BUILD_CONFIG[OS_KERNEL_NAME]="cygwin_nt-6.1"
> > BUILD_CONFIG[REPOSITORY]="adoptopenjdk/openjdk-jdk8u"
> > BUILD_CONFIG[REUSE_CONTAINER]="true"
> > BUILD_CONFIG[SHALLOW_CLONE_OPTION]="--depth=1"
> > BUILD_CONFIG[SIGN]="false"
> > BUILD_CONFIG[TAG]=""
> > BUILD_CONFIG[TARGET_DIR]="target/"
> >
> BUILD_CONFIG[TARGET_FILE_NAME]="OpenJDK8U_x64_windows_hotspot_2018-09-14-10-51.zip"
> > BUILD_CONFIG[TMP_CONTAINER_NAME]="openjdk-copy-src"
&

Syntax error with set-vs-env.sh: - building jdk8u on Windows (cygwin)

[Martijn Verburg]

Hi all,

AdoptOpenJDK recently started seeing this error (full configure details
below the horizontal), has anyone else experienced this:

configure: Setting extracted environment variables
/cygdrive/c/cygwin64/tmp/tmp.wVFLippfrz/workspace/build/src/build/windows-x86_64-normal-server-release/vs-env/
syntax error near unexpected token `('
/cygdrive/c/cygwin64/tmp/tmp.wVFLippfrz/workspace/build/src/build/windows-x86_64-normal-server-release/vs-env/set-vs-env.sh:
line 2: `VS_INCLUDE="C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\INCLUDE;C:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\ATLMFC\INCLUDE;C:\Program Files (x86)\Microsoft
SDKs\Windows\v7.0A\include; "'
configure exiting with result code 2

Looks like a typical shell expansion bug but it's only recently cropped up.



[C:\Users\jenkins\workspace\build-scripts\jobs\jdk8u\jdk8u-windows-x64-hotspot]
Running shell script
+ ./build-farm/make-adopt-build-farm.sh
BUILD TYPE:
VERSION: jdk8u
ARCHITECTURE x64
VARIANT: hotspot
OS: windows
Detecting boot jdk for: jdk8u
Found build version: 8
Boot jdk version: 7
Boot jdk: /cygdrive/c/openjdk/jdk7
Filename will be: OpenJDK8U_x64_windows_hotspot_2018-09-14-10-51.zip
Starting
/cygdrive/c/Users/jenkins/workspace/build-scripts/jobs/jdk8u/jdk8u-windows-x64-hotspot/build-farm/../makejdk-any-platform.sh
to configure, build (Adopt)OpenJDK binary
Working dir is ./build/
# 
# OPENJDK BUILD CONFIGURATION:
# 
BUILD_CONFIG[BRANCH]="dev"
BUILD_CONFIG[BUILD_FULL_NAME]="cygwin_nt-6.1-x86_64-normal-server-release"
BUILD_CONFIG[BUILD_VARIANT]=""
BUILD_CONFIG[CLEAN_DOCKER_BUILD]="false"
BUILD_CONFIG[CLEAN_GIT_REPO]="true"
BUILD_CONFIG[CONFIGURE_ARGS_FOR_ANY_PLATFORM]=""
BUILD_CONFIG[CONTAINER_NAME]="openjdk_container"
BUILD_CONFIG[COPY_MACOSX_FREE_FONT_LIB_FOR_JDK_FLAG]="false"
BUILD_CONFIG[COPY_MACOSX_FREE_FONT_LIB_FOR_JRE_FLAG]="false"
BUILD_CONFIG[DOCKER]="docker"
BUILD_CONFIG[DOCKER_FILE_PATH]=""
BUILD_CONFIG[DOCKER_SOURCE_VOLUME_NAME]="openjdk-source-volume"
BUILD_CONFIG[FREETYPE]="true"
BUILD_CONFIG[FREETYPE_DIRECTORY]=""
BUILD_CONFIG[FREETYPE_FONT_BUILD_TYPE_PARAM]=""
BUILD_CONFIG[FREETYPE_FONT_VERSION]="2.4.0"
BUILD_CONFIG[JDK_BOOT_DIR]="/cygdrive/c/openjdk/jdk7"
BUILD_CONFIG[JDK_PATH]="j2sdk-image"
BUILD_CONFIG[JRE_PATH]="j2re-image"
BUILD_CONFIG[JVM_VARIANT]="server"
BUILD_CONFIG[KEEP_CONTAINER]="false"
BUILD_CONFIG[MAKE_ARGS_FOR_ANY_PLATFORM]=""
BUILD_CONFIG[MAKE_COMMAND_NAME]="make"
BUILD_CONFIG[NUM_PROCESSORS]="1"
BUILD_CONFIG[OPENJDK_BUILD_NUMBER]=""
BUILD_CONFIG[OPENJDK_CORE_VERSION]="jdk8"
BUILD_CONFIG[OPENJDK_FOREST_NAME]="jdk8u"
BUILD_CONFIG[OPENJDK_SOURCE_DIR]="src"
BUILD_CONFIG[OPENJDK_UPDATE_VERSION]=""
BUILD_CONFIG[OS_ARCHITECTURE]="x86_64"
BUILD_CONFIG[OS_KERNEL_NAME]="cygwin_nt-6.1"
BUILD_CONFIG[REPOSITORY]="adoptopenjdk/openjdk-jdk8u"
BUILD_CONFIG[REUSE_CONTAINER]="true"
BUILD_CONFIG[SHALLOW_CLONE_OPTION]="--depth=1"
BUILD_CONFIG[SIGN]="false"
BUILD_CONFIG[TAG]=""
BUILD_CONFIG[TARGET_DIR]="target/"
BUILD_CONFIG[TARGET_FILE_NAME]="OpenJDK8U_x64_windows_hotspot_2018-09-14-10-51.zip"
BUILD_CONFIG[TMP_CONTAINER_NAME]="openjdk-copy-src"
BUILD_CONFIG[TMP_SPACE_BUILD]="true"
BUILD_CONFIG[USER_SUPPLIED_CONFIGURE_ARGS]="
--with-freetype-include=/cygdrive/c/openjdk/freetype/include
--with-freetype-lib=/cygdrive/c/openjdk/freetype/lib64 --disable-ccache"
BUILD_CONFIG[USE_DOCKER]="false"
BUILD_CONFIG[USE_SSH]="false"
BUILD_CONFIG[WORKING_DIR]="./build/"
BUILD_CONFIG[WORKSPACE_DIR]="/cygdrive/c/Users/jenkins/workspace/build-scripts/jobs/jdk8u/jdk8u-windows-x64-hotspot/workspace"
JDK Image folder name: j2sdk-image
JRE Image folder name: j2re-image
[debug] COPY_MACOSX_FREE_FONT_LIB_FOR_JDK_FLAG=false
[debug] COPY_MACOSX_FREE_FONT_LIB_FOR_JRE_FLAG=false



OpenJDK repo tag is jdk8u181-b13
Version: 181 13
Completed configuring the version string parameter, config args are now:
 --with-milestone=adoptopenjdk --with-build-number=13
Overriding JDK_BOOT_DIR, set to /cygdrive/c/openjdk/jdk7
Boot dir set to /cygdrive/c/openjdk/jdk7
Windows or Windows-like environment detected, skipping configuring
environment for custom Boot JDK and other 'configure' settings.
Completed configuring the version string parameter, config args are now:
 --with-milestone=adoptopenjdk --with-build-number=13
--with-boot-jdk=/cygdrive/c/openjdk/jdk7
 --with-freetype-include=/cygdrive/c/openjdk/freetype/include
--with-freetype-lib=/cygdrive/c/openjdk/freetype/lib64 --disable-ccache
Configuring command and using the pre-built config params...
Should have the source, I'm at /tmp/tmp.wVFLippfrz/workspace/build/src
Currently at '/tmp/tmp.wVFLippfrz/workspace/build/src'
Running ./configure with arguments 'bash ./configure
 --with-milestone=adoptopenjdk --with-build-number=13
--with-boot-jdk=/cygdrive/c/openjdk/jdk7
 --with-freetype-include=/cygdrive/c/openjdk/freetype/include
--with-freetype-lib=/cygdrive/c/openjdk/freetype/lib64 --disable-ccache '
Should have the source, I'm at 

Re: RFR: JDK-8200132: Remove jre images and bundles

[Martijn Verburg]

Thanks Erik,

We do have quite a few requests to build that jRE for AdoptOpenJDK
binaries, and this should let us continue doing that.

Cheers,
Martijn

On 5 June 2018 at 09:41, Alan Bateman  wrote:

> On 04/06/2018 22:22, Erik Joelsson wrote:
>
>> Given the feedback, I have revised the patch to restore the ability to
>> produce a legacy jre image, but it is still removed from the default
>> "product-images" and "images" targets. To build it you need to specify it
>> explicitly as "legacy-jre-image" (or mac-legacy-jre-bundle for the macosx
>> specific image layout). I still removed the bundle targets for the jre
>> image as I very much doubt anyone except Oracle was using them anyway. In
>> addition to this, I also updated the help text a bit to reflect these
>> changes.
>>
>> Will this be good enough for those that still need a JRE image?
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8200132/webrev.02/index.html
>>
> This looks okay to me, and seems better than the configure option
> mentioned in one of the mails.
>
> I think you will still need to do some communication about this change,
> maybe to jdk-dev so that folks that may be relying on the jre image know
> that they need to build the legacy-jre-image target.
>
> I suspect this area of the build will be re-visited again if the Java
> Packager JEP goes ahead as that will need a similar list of modules and
> maybe options.
>
> -Alan.
>

Re: Supported platforms

[Martijn Verburg]

Hi all,

Apologies for being late to the thread.  We're looking to provide a central
place for OpenJDK binaries to be produced and have some level of community
support for the more esoteric platforms.  Perhaps this is a place where you
can get some extra assistance in keeping a particular port vibrant (having
regularly tested builds helps)p.

See the following for details:

* https://www.github.com/adoptopejdk/TSC - Build Farm overview
* https://www.adoptopenjdk.net (end user site)
* https://www.adoptopenjdk.net/slack (join ~200 volunteers!)
* https://ci.adoptopenjdk.net (Jenkins cluster)

It's still a work in progress but many of the OpenJDK vendors you know of
today are involved (Oracle, IBM, Red Hat, SAP et al) and so we're hopeful
that the collaboration there will help the more esoteric platforms that do
gain genuine popularity and support can flourish without adding further
burden on a single vendor.

We'll be following a very strong policy of reporting and submitting patches
upstream to OpenJDK / OpenJ9 / , exactly how it
works today with various porting and downstream implementations today.
This isn't strictly an OpenJDK effort, so please do head over to
https://www.adoptopenjdk.net/slack to find out more or ping the
adoption-discuss mailing list here at OpenJDK.

Cheers,
Martijn

On 10 April 2018 at 10:24, David Holmes  wrote:

> On 10/04/2018 7:17 PM, Aleksei Voitylov wrote:
>
>> David,
>>
>> see inline:
>>
>>
>> On 10/04/2018 11:00, David Holmes wrote:
>>
>>> Hi Aleksei,
>>>
>>> This is all news to me. Good news, but unexpected. As far as I was aware
>>> the 32-bit ARM port was dying a slow death and would eventually get
>>> removed. 64-bit ARM is of course very much alive and well under the Aarch64
>>> porters - though I'm unclear if you are using that code for ARMv8 or the
>>> Oracle contributed code that used to be closed?
>>>
>> You are welcome :) We are doing everything possible to keep it running,
>> so I don't see any reason within OpenJDK to it being removed. Regarding
>> ARMv8 port, we are working with Cavium, Redhat, and Linaro on supporting
>> the AARCH64 port.
>>
>>>
>>> I'm also unclear whether you are pushing changes back up to OpenJDK for
>>> these platforms, or maintaining them locally? I haven't noticed anything
>>> (other than build tweaks) and am curious about the release of a Minimal VM
>>> for JDK 10 given the Minimal VM effectively died along with the stand-alone
>>> Client VM.
>>>
>> We push everything upstream.
>>
>
> I don't recall seeing anything related to 32-bit ARM, but perhaps it's all
> in areas I don't see (like compiler and gc).
>
> I'm not sure why you believe Minimal VM and Client VM died in OpenJDK 10.
>> From what I remember, there was some decision related to Client VM for
>> Oracle binaries, but support for C1 and Minimal VM was not removed from
>> OpenJDK codebase. This is what I get with BellSoft Liberica binaries built
>> from OpenJDK on Raspberry Pi:
>>
>
> Sorry I was mis-remembering. Of course C1 and Minimal still exist in the
> 32-bit code. Though I would be concerned that with a focus on 64-bit it
> will be easy for engineers to overlook things that should be inside one of
> the INCLUDE_XXX guards. (Particularly as we don't do any 32-bit builds and
> for the most part don't even have the capability to perform them.)
>
> Cheers,
> David
>
> pi@rpi-3:~ $ java -version
>>> openjdk version "10-BellSoft" 2018-03-20
>>> OpenJDK Runtime Environment (build 10-BellSoft+0)
>>> OpenJDK Server VM (build 10-BellSoft+0, mixed mode)
>>> pi@rpi-3:~ $ java -minimal -version
>>> openjdk version "10-BellSoft" 2018-03-20
>>> OpenJDK Runtime Environment (build 10-BellSoft+0)
>>> OpenJDK Minimal VM (build 10-BellSoft+0, mixed mode)
>>> pi@rpi-3:~ $ java -client -version
>>> openjdk version "10-BellSoft" 2018-03-20
>>> OpenJDK Runtime Environment (build 10-BellSoft+0)
>>> OpenJDK Client VM (build 10-BellSoft+0, mixed mode)
>>>
>>
>> pi@rpi-3:~ $ java -minimal -XX:+PrintFlagsFinal HW | grep C1
>>>  bool C1OptimizeVirtualCallProfiling   =
>>> true  {C1 product} {default}
>>>  bool C1ProfileBranches=
>>> true  {C1 product} {default}
>>>  bool C1ProfileCalls   =
>>> true  {C1 product} {default}
>>>  bool C1ProfileCheckcasts  =
>>> true  {C1 product} {default}
>>>  bool C1ProfileInlinedCalls=
>>> true  {C1 product} {default}
>>>  bool C1ProfileVirtualCalls=
>>> true  {C1 product} {default}
>>>  bool C1UpdateMethodData   =
>>> false {C1 product} {default}
>>>  bool InlineSynchronizedMethods=
>>> true  {C1 product} {default}
>>>  bool LIRFillDe

Re: RFR 8190378: Java EE and CORBA modules removal

[Martijn Verburg]

One could almost shed a tear - of joy!  This is exactly the use case for
the module system that the developer community at large will understand.
Thanks for this change and a leaner meaner JDK.

Cheers,
Martijn

On 8 February 2018 at 13:37, Lance Andersen 
wrote:

>
> > On Feb 8, 2018, at 3:04 AM, Alan Bateman 
> wrote:
> >
> > On 07/02/2018 16:57, Lance Andersen wrote:
> >> Hi all,
> >>
> >> I think we are at a point where we are ready to start reviewing  the
> changes to remove the Java EE and CORBA modules as JEP 320, JDK-8189188,
> has been  targeted to JDK 11.
> >> The CSR for removing the modules has been approved:
> https://bugs.openjdk.java.net/browse/JDK-8193757 <
> https://bugs.openjdk.java.net/browse/JDK-8193757>
> >>
> >>  The open webrev can be found at:  http://cr.openjdk.java.net/~
> lancea/8190378/open_changes/  lancea/8190378/open_changes/>
> >>
> > 800 KLOC deleted, wonderful!
> >
> > The update to technology-summary.html page means its html title no
> longer matches the contents. We should probably change it to "JCP
> Technologies in JDK 11" for now.
>
> I updated the webrev. Thanks for catching that (btw we missed this for JDK
> 10)
> >
> > The removal of test cases from the tests in tools/launcher/modules
> removes most of the test coverage for the upgrade module path. We'll need
> to replace these sub-tests. Can you create an issue to track that?
>
> I can do that
> >
> > Everything else looks good and it's okay to track residual issues with
> other JIRA issues. I think the important thing is to get this monster patch
> into JDK builds soon so that libraries and the eco system can start to
> adjust.
>
> Thank you Alan for the review
>
> Best
> Lance
> >
> > -Alan
>
>  
>   <
> http://oracle.com/us/design/oracle-email-sig-198324.gif>
>  Lance Andersen|
> Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> lance.ander...@oracle.com 
>
>
>
>

Re: Correct Compiler for ARM / Arch64 for the jdk8u forest? (-m64 not supported)

[Martijn Verburg]

Hi Erik/Andrew/Dalibor,

Ah that clears it up - we were getting confused with what port was in
mainstream or not.  OK, we'll pick the ssh://hg.openjdk.java.net/
aarch64-port/jdk8u for our Java 8 build (Zero is interesting, but of less
use to the wider community) and then we'll see what happens for 9 and 10 a
little down the line.

Thanks all again for the speedy assistance!

Cheers,
Martijn

On 20 April 2017 at 13:17, dalibor topic  wrote:

> If this is related to yesterday's similar query [0], then I assume you're
> using http://hg.openjdk.java.net/jdk8u/jdk8u/ for the build.
>
> There is no dedicated ARM port in JDK 8u. You would need to build the Zero
> interpreter instead, if you are building from the forest above, or, as
> Andrew suggested, use a different forest from the AArch64 Port Project.
>
> cheers,
> dalibor topic
>
> [0] http://mail.openjdk.java.net/pipermail/build-dev/2017-April/
> 018974.html
>
>
> On 20.04.2017 13:16, Martijn Verburg wrote:
>
>> Hi all,
>>
>> We've been putting together a community build farm and have wrangled from
>> ARM machines. We are building from jdk8u and have the following
>> configuration:
>>
>> -
>>
>> A new configuration has been successfully created in
>> /home/jenkins/workspace/george_arm_test/openjdk/build/linux-
>> aarch64-normal-server-release
>> using configure arguments
>> '--with-boot-jdk=/usr/lib/jvm/java-1.7.0-openjdk-arm64 --enable-ccache
>> --with-jvm-variants=server
>> --with-cacerts-file=/home/jenkins/workspace/george_arm_test/
>> cacerts_area/security/cacerts
>> --with-alsa=/home/jenkins/workspace/george_arm_test/alsa-lib-1.0.27.2
>> --with-freetype=/home/jenkins/workspace/george_arm_test/open
>> jdk/installedfreetype
>> --with-x=/usr/include/X11 --with-debug-level=release'.
>>
>> Configuration summary:
>> * Debug level:release
>> * JDK variant:normal
>> * JVM variants:   server
>> * OpenJDK target: OS: linux, CPU architecture: aarch64, address length: 64
>>
>> Tools summary:
>> * Boot JDK:   java version "1.7.0_95" OpenJDK Runtime Environment
>> (IcedTea 2.6.4) (7u95-2.6.4-3) OpenJDK 64-Bit Server VM (build 24.95-b01,
>> mixed mode)  (at /usr/lib/jvm/java-1.7.0-openjdk-arm64)
>> * C Compiler: gcc-5 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 5.4.0
>> version 5.4.0 (at /usr/bin/gcc-5)
>> * C++ Compiler:   g++-5 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 5.4.0
>> version 5.4.0 (at /usr/bin/g++-5)
>>
>> Build performance summary:
>> * Cores to use:   16
>> * Memory limit:   128878 MB
>> * ccache status:  installed and in use
>>
>> Configured the JDK
>>
>> --
>>
>> We notice that the configure output states:
>>
>> checking if the C compiler supports "-m64"... no
>> checking if the C++ compiler supports "-m64"... no
>> checking if both compilers support "-m64"... no
>> checking if the C compiler supports "-m64"... no
>> checking if the C++ compiler supports "-m64"... no
>> checking if both compilers support "-m64"... no
>>
>> -
>>
>> The hotspot build then fails (predictably enough) at:
>>
>> CCACHE_COMPRESS=1  CCACHE_SLOPPINESS=time_macros /usr/local/bin/ccache
>> /usr/bin/g++-5 -DLINUX -D_GNU_SOURCE -DAMD64 -DPRODUCT -I.
>> -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/
>> src/share/vm/prims
>> -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/share/vm
>> -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/
>> src/share/vm/precompiled
>> -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/cpu/x86/vm
>> -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/
>> src/os_cpu/linux_x86/vm
>> -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/os/linux/vm
>> -I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/os/posix/vm
>> -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.71-b00\""
>> -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"jenkins\""
>> -DHOTSPOT_LIB_ARCH=\"aarch64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\""
>>  -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64
>> -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64
>> -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti
>> -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64  -pipe
>> -fno-strict-aliasing  -g -fno-omit-frame-pointer -O3  -DVM_LITTLE_ENDIAN
>

Correct Compiler for ARM / Arch64 for the jdk8u forest? (-m64 not supported)

[Martijn Verburg]

Hi all,

We've been putting together a community build farm and have wrangled from
ARM machines. We are building from jdk8u and have the following
configuration:

-

A new configuration has been successfully created in
/home/jenkins/workspace/george_arm_test/openjdk/build/linux-aarch64-normal-server-release
using configure arguments
'--with-boot-jdk=/usr/lib/jvm/java-1.7.0-openjdk-arm64 --enable-ccache
--with-jvm-variants=server
--with-cacerts-file=/home/jenkins/workspace/george_arm_test/cacerts_area/security/cacerts
--with-alsa=/home/jenkins/workspace/george_arm_test/alsa-lib-1.0.27.2
--with-freetype=/home/jenkins/workspace/george_arm_test/openjdk/installedfreetype
--with-x=/usr/include/X11 --with-debug-level=release'.

Configuration summary:
* Debug level:release
* JDK variant:normal
* JVM variants:   server
* OpenJDK target: OS: linux, CPU architecture: aarch64, address length: 64

Tools summary:
* Boot JDK:   java version "1.7.0_95" OpenJDK Runtime Environment
(IcedTea 2.6.4) (7u95-2.6.4-3) OpenJDK 64-Bit Server VM (build 24.95-b01,
mixed mode)  (at /usr/lib/jvm/java-1.7.0-openjdk-arm64)
* C Compiler: gcc-5 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 5.4.0
version 5.4.0 (at /usr/bin/gcc-5)
* C++ Compiler:   g++-5 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) 5.4.0
version 5.4.0 (at /usr/bin/g++-5)

Build performance summary:
* Cores to use:   16
* Memory limit:   128878 MB
* ccache status:  installed and in use

Configured the JDK

--

We notice that the configure output states:

checking if the C compiler supports "-m64"... no
checking if the C++ compiler supports "-m64"... no
checking if both compilers support "-m64"... no
checking if the C compiler supports "-m64"... no
checking if the C++ compiler supports "-m64"... no
checking if both compilers support "-m64"... no

-

The hotspot build then fails (predictably enough) at:

CCACHE_COMPRESS=1  CCACHE_SLOPPINESS=time_macros /usr/local/bin/ccache
/usr/bin/g++-5 -DLINUX -D_GNU_SOURCE -DAMD64 -DPRODUCT -I.
-I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/share/vm/prims
-I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/share/vm
-I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/share/vm/precompiled
-I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/cpu/x86/vm
-I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/os_cpu/linux_x86/vm
-I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/os/linux/vm
-I/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/os/posix/vm
-I../generated -DHOTSPOT_RELEASE_VERSION="\"25.71-b00\""
-DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"jenkins\""
-DHOTSPOT_LIB_ARCH=\"aarch64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\""
 -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64
-DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64
-DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti
-fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64  -pipe
-fno-strict-aliasing  -g -fno-omit-frame-pointer -O3  -DVM_LITTLE_ENDIAN
-D_LP64=1 -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function
-Wunused-value -std=gnu++98 -c -MMD -MP -MF
../generated/dependencies/precompiled.hpp.gch.d -fpch-deps -x c++-header
/home/jenkins/workspace/george_arm_test/openjdk/hotspot/src/share/vm/precompiled/precompiled.hpp
-o precompiled.hpp.gch
*g++-5: error: unrecognized command line option '-m64'*

-

We're inexperienced at build on this architecture, I assuming that we
either need a compiler that supports -m64 or that -m64 should not be passed
through in this case?

Cheers,
Martijn

Re: Building latest jdk9 dev on Mac OS X 10.12.1 - Undefined symbols (_libiconv) causing build to fail?

[Martijn Verburg]

Hi Michel,

That helps actually - confirms that it's like my unique set up, a reverse
of the usual WFM!

Cheers,
Martijn

On Thu, 15 Dec 2016 at 23:47, Michel Trudeau 
wrote:

>
>
>
>
> Just a reference point.
>
>
>
>
>
> I updated to the latest Sierra update and latest Xcode update yesterday
>
> and I can build OpenJDK 9 successfully using the following two commands
>
>
>
>
>
> bash configure --with-freetype-include=/usr/X11/include/freetype2
>
> --with-freetype-lib=/usr/X11/lib --disable-warnings-as-errors
>
>
>
>
>
> make images
>
>
>
>
> Thanks,
> Michel
>
>
>
>
>
>
>
>
>
>
>
> Phil Race wrote:
>
>
> A complete stab in the dark, but did you install the xcode
>
> command line
>
> tools ?
>
>
>
>
>
>
>
>
>
> -phil.
>
>
>
>
>
>
>
>
>
> On 12/15/2016 07:24 AM, Martijn Verburg wrote:
>
>
>
>
> Hi Erik,
>
>
>
>
>
> Thanks, that's fine. As an FYI I swapped to using gcc and g++
>
> compilers but
>
>
> still get the same error so more digging is required, will update
>
> here
>
>
> if/when I find the culprit
>
>
>
>
>
> Cheers,
>
>
> Martijn
>
>
>
>
>
> On 15 December 2016 at 09:45, Erik Joelsson
>
>  
>
>
> wrote:
>
>
>
>
>
> Hello,
>
>
>
>
>
> I'm not a native Mac user so I only ever build for Mac using the
>
>
> officially picked toolchains at Oracle, which is currently Xcode
>
> 6.3. At
>
>
> the time when we made that choice, 7.0 was still in beta. Support
>
> for newer
>
>
> toolchains is a community effort and not something we in the build
>
> team are
>
>
> able to actively pursue.
>
>
>
>
>
> /Erik
>
>
>
>
>
>
>
>
>
>
>
> On 2016-12-15 10:29, Martijn Verburg wrote:
>
>
>
>
>
> Hi all,
>
>
>
>
>
> I've updated my toolchain slightly and am now on XCode 8.2, Mac OS X
>
>
> 10.12.2:
>
>
>
>
>
> 
>
>
>
>
>
> Configuration summary:
>
>
> * Debug level:release
>
>
> * HS debug level: product
>
>
> * JDK variant:normal
>
>
> * JVM variants:   server
>
>
> * OpenJDK target: OS: macosx, CPU architecture: x86, address length:
>
> 64
>
>
> * Version string: 9-internal+0-adhoc.karianna.jdk9dev (9-internal)
>
>
>
>
>
> Tools summary:
>
>
> * Boot JDK:   java version "1.8.0_112" Java(TM) SE Runtime
>
> Environment
>
>
> (build 1.8.0_112-b16) Java HotSpot(TM) 64-Bit Server VM (build
>
> 25.112-b16,
>
>
> mixed mode)  (at
>
>
> /Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home)
>
>
> * Toolchain:  clang (clang/LLVM from Xcode 8.2)
>
>
> * C Compiler: Version 8.0.0 (at /usr/bin/clang)
>
>
> * C++ Compiler:   Version 8.0.0 (at /usr/bin/clang++)
>
>
>
>
>
> Build performance summary:
>
>
> * Cores to use:   8
>
>
> * Memory limit:   16384 MB
>
>
>
>
>
> 
>
>
>
>
>
> The same build error as reported below still occurs.  Is it the case
>
> that
>
>
> clang at this version is not yet supported?
>
>
>
>
>
>
>
>
> Cheers,
>
>
> Martijn
>
>
>
>
>
> On 8 December 2016 at 20:38, Martijn Verburg
>
>  
>
>
> wrote:
>
>
>
>
>
> Hi all,
>
>
> I got past my previous issue (thanks
>
> Dmitry!), but I now have a new one
>
>
> (after a fresh clone).  I notice I'm using the clang compiler by
>
> default,
>
>
> not sure if that's supported.
>
>
>
>
>
> -
>
>
>
>
>
>
>
>
> ld: warning: object file (/Users/karianna/Documents/
>
>
> workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
>
>
> x86_64-normal-server-release/support/native/java.base/libjli_static.a)
>
>
> was built for newer OSX version (10.12) than being linked (10.7)
>
>
> Creating support/modules_libs/java.rmi/librmi.dylib from 1 file(s)
>
>
> Creating support/modules_cmds/java.rmi/rmid from 1 file(s)
>
>
> Creating support/modules_cmds/java.rmi/rmiregistry from 1 file(s)
>
>
> ld: warning: object file (/Users/karianna/Documents/
>
>
> workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
>
>
> x86_64-normal-server-release/support/native/java.b

Re: Building latest jdk9 dev on Mac OS X 10.12.1 - Undefined symbols (_libiconv) causing build to fail?

[Martijn Verburg]

Hi Phil,

Good call! But yes I had done that. It may be down to a potential issue
with a macports install of libconv.

Nothing like debugging native line for Christmas 🙂.

Cheers,
Martijn


On Thu, 15 Dec 2016 at 23:44, Phil Race  wrote:

> A complete stab in the dark, but did you install the xcode command line
>
> tools ?
>
>
>
> -phil.
>
>
>
> On 12/15/2016 07:24 AM, Martijn Verburg wrote:
>
> > Hi Erik,
>
> >
>
> > Thanks, that's fine. As an FYI I swapped to using gcc and g++ compilers
> but
>
> > still get the same error so more digging is required, will update here
>
> > if/when I find the culprit
>
> >
>
> > Cheers,
>
> > Martijn
>
> >
>
> > On 15 December 2016 at 09:45, Erik Joelsson 
>
> > wrote:
>
> >
>
> >> Hello,
>
> >>
>
> >> I'm not a native Mac user so I only ever build for Mac using the
>
> >> officially picked toolchains at Oracle, which is currently Xcode 6.3. At
>
> >> the time when we made that choice, 7.0 was still in beta. Support for
> newer
>
> >> toolchains is a community effort and not something we in the build team
> are
>
> >> able to actively pursue.
>
> >>
>
> >> /Erik
>
> >>
>
> >>
>
> >>
>
> >> On 2016-12-15 10:29, Martijn Verburg wrote:
>
> >>
>
> >>> Hi all,
>
> >>>
>
> >>> I've updated my toolchain slightly and am now on XCode 8.2, Mac OS X
>
> >>> 10.12.2:
>
> >>>
>
> >>> 
>
> >>>
>
> >>> Configuration summary:
>
> >>> * Debug level:release
>
> >>> * HS debug level: product
>
> >>> * JDK variant:normal
>
> >>> * JVM variants:   server
>
> >>> * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
>
> >>> * Version string: 9-internal+0-adhoc.karianna.jdk9dev (9-internal)
>
> >>>
>
> >>> Tools summary:
>
> >>> * Boot JDK:   java version "1.8.0_112" Java(TM) SE Runtime
> Environment
>
> >>> (build 1.8.0_112-b16) Java HotSpot(TM) 64-Bit Server VM (build
> 25.112-b16,
>
> >>> mixed mode)  (at
>
> >>> /Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home)
>
> >>> * Toolchain:  clang (clang/LLVM from Xcode 8.2)
>
> >>> * C Compiler: Version 8.0.0 (at /usr/bin/clang)
>
> >>> * C++ Compiler:   Version 8.0.0 (at /usr/bin/clang++)
>
> >>>
>
> >>> Build performance summary:
>
> >>> * Cores to use:   8
>
> >>> * Memory limit:   16384 MB
>
> >>>
>
> >>> 
>
> >>>
>
> >>> The same build error as reported below still occurs.  Is it the case
> that
>
> >>> clang at this version is not yet supported?
>
> >>>
>
> >>>
>
> >>> Cheers,
>
> >>> Martijn
>
> >>>
>
> >>> On 8 December 2016 at 20:38, Martijn Verburg  >
>
> >>> wrote:
>
> >>>
>
> >>> Hi all,
>
> >>>> I got past my previous issue (thanks Dmitry!), but I now have a new
> one
>
> >>>> (after a fresh clone).  I notice I'm using the clang compiler by
> default,
>
> >>>> not sure if that's supported.
>
> >>>>
>
> >>>> -
>
> >>>>
>
> >>>>
>
> >>>> ld: warning: object file (/Users/karianna/Documents/
>
> >>>> workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
>
> >>>> x86_64-normal-server-release/support/native/java.base/libjli_static.a)
>
> >>>> was built for newer OSX version (10.12) than being linked (10.7)
>
> >>>> Creating support/modules_libs/java.rmi/librmi.dylib from 1 file(s)
>
> >>>> Creating support/modules_cmds/java.rmi/rmid from 1 file(s)
>
> >>>> Creating support/modules_cmds/java.rmi/rmiregistry from 1 file(s)
>
> >>>> ld: warning: object file (/Users/karianna/Documents/
>
> >>>> workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
>
> >>>> x86_64-normal-server-release/support/native/java.base/libjli_static.a)
>
> >>>> was built for newer OSX version (10.12) than being

Re: Building latest jdk9 dev on Mac OS X 10.12.1 - Undefined symbols (_libiconv) causing build to fail?

[Martijn Verburg]

Hi Erik,

Thanks, that's fine. As an FYI I swapped to using gcc and g++ compilers but
still get the same error so more digging is required, will update here
if/when I find the culprit

Cheers,
Martijn

On 15 December 2016 at 09:45, Erik Joelsson 
wrote:

> Hello,
>
> I'm not a native Mac user so I only ever build for Mac using the
> officially picked toolchains at Oracle, which is currently Xcode 6.3. At
> the time when we made that choice, 7.0 was still in beta. Support for newer
> toolchains is a community effort and not something we in the build team are
> able to actively pursue.
>
> /Erik
>
>
>
> On 2016-12-15 10:29, Martijn Verburg wrote:
>
>> Hi all,
>>
>> I've updated my toolchain slightly and am now on XCode 8.2, Mac OS X
>> 10.12.2:
>>
>> 
>>
>> Configuration summary:
>> * Debug level:release
>> * HS debug level: product
>> * JDK variant:normal
>> * JVM variants:   server
>> * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
>> * Version string: 9-internal+0-adhoc.karianna.jdk9dev (9-internal)
>>
>> Tools summary:
>> * Boot JDK:   java version "1.8.0_112" Java(TM) SE Runtime Environment
>> (build 1.8.0_112-b16) Java HotSpot(TM) 64-Bit Server VM (build 25.112-b16,
>> mixed mode)  (at
>> /Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home)
>> * Toolchain:  clang (clang/LLVM from Xcode 8.2)
>> * C Compiler: Version 8.0.0 (at /usr/bin/clang)
>> * C++ Compiler:   Version 8.0.0 (at /usr/bin/clang++)
>>
>> Build performance summary:
>> * Cores to use:   8
>> * Memory limit:   16384 MB
>>
>> ============
>>
>> The same build error as reported below still occurs.  Is it the case that
>> clang at this version is not yet supported?
>>
>>
>> Cheers,
>> Martijn
>>
>> On 8 December 2016 at 20:38, Martijn Verburg 
>> wrote:
>>
>> Hi all,
>>>
>>> I got past my previous issue (thanks Dmitry!), but I now have a new one
>>> (after a fresh clone).  I notice I'm using the clang compiler by default,
>>> not sure if that's supported.
>>>
>>> -
>>>
>>>
>>> ld: warning: object file (/Users/karianna/Documents/
>>> workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
>>> x86_64-normal-server-release/support/native/java.base/libjli_static.a)
>>> was built for newer OSX version (10.12) than being linked (10.7)
>>> Creating support/modules_libs/java.rmi/librmi.dylib from 1 file(s)
>>> Creating support/modules_cmds/java.rmi/rmid from 1 file(s)
>>> Creating support/modules_cmds/java.rmi/rmiregistry from 1 file(s)
>>> ld: warning: object file (/Users/karianna/Documents/
>>> workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
>>> x86_64-normal-server-release/support/native/java.base/libjli_static.a)
>>> was built for newer OSX version (10.12) than being linked (10.7)
>>> ld: warning: object file (/Users/karianna/Documents/
>>> workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
>>> x86_64-normal-server-release/support/native/java.base/libjli_static.a)
>>> was built for newer OSX version (10.12) than being linked (10.7)
>>> *Undefined symbols for architecture x86_64:*
>>> *  "_libiconv", referenced from:*
>>> *  _convertUft8ToPlatformString in EncodingSupport_md.o*
>>> *  "_libiconv_open", referenced from:*
>>> *  _convertUft8ToPlatformString in EncodingSupport_md.o*
>>> *ld: symbol(s) not found for architecture x86_64*
>>> *clang: error: linker command failed with exit code 1 (use -v to see
>>> invocation)*
>>> cp: /Users/karianna/Documents/workspace/AdoptOpenJDK_
>>> Projects/jdk9dev/build/macosx-x86_64-normal-server-release/
>>> make-support/failure-logs/support_native_java.instrument_
>>> libinstrument_BUILD_LIBINSTRUMENT_link.log:
>>> No such file or directory
>>> make[3]: *** [/Users/karianna/Documents/workspace/AdoptOpenJDK_
>>> Projects/jdk9dev/build/macosx-x86_64-normal-server-release/
>>> support/modules_libs/java.instrument/libinstrument.dylib] Error 1
>>> make[2]: *** [java.instrument-libs] Error 2
>>> make[2]: *** Waiting for unfinished jobs
>>> ld: warning: object file (/Users/karianna/Documents/
>>> workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
>>> x86_64-normal-server-release/support/native/java.base/libjli_static.a)
>>> was built for newer OSX version (10.12) than being linked (10.7)
>>>
>>>
>>> Cheers,
>>> Martijn
>>>
>>>
>

Re: Building latest jdk9 dev on Mac OS X 10.12.1 - Undefined symbols (_libiconv) causing build to fail?

[Martijn Verburg]

Hi all,

I've updated my toolchain slightly and am now on XCode 8.2, Mac OS X
10.12.2:



Configuration summary:
* Debug level:release
* HS debug level: product
* JDK variant:normal
* JVM variants:   server
* OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
* Version string: 9-internal+0-adhoc.karianna.jdk9dev (9-internal)

Tools summary:
* Boot JDK:   java version "1.8.0_112" Java(TM) SE Runtime Environment
(build 1.8.0_112-b16) Java HotSpot(TM) 64-Bit Server VM (build 25.112-b16,
mixed mode)  (at
/Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home)
* Toolchain:  clang (clang/LLVM from Xcode 8.2)
* C Compiler: Version 8.0.0 (at /usr/bin/clang)
* C++ Compiler:   Version 8.0.0 (at /usr/bin/clang++)

Build performance summary:
* Cores to use:   8
* Memory limit:   16384 MB



The same build error as reported below still occurs.  Is it the case that
clang at this version is not yet supported?


Cheers,
Martijn

On 8 December 2016 at 20:38, Martijn Verburg 
wrote:

> Hi all,
>
> I got past my previous issue (thanks Dmitry!), but I now have a new one
> (after a fresh clone).  I notice I'm using the clang compiler by default,
> not sure if that's supported.
>
> -
>
>
> ld: warning: object file (/Users/karianna/Documents/
> workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
> x86_64-normal-server-release/support/native/java.base/libjli_static.a)
> was built for newer OSX version (10.12) than being linked (10.7)
> Creating support/modules_libs/java.rmi/librmi.dylib from 1 file(s)
> Creating support/modules_cmds/java.rmi/rmid from 1 file(s)
> Creating support/modules_cmds/java.rmi/rmiregistry from 1 file(s)
> ld: warning: object file (/Users/karianna/Documents/
> workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
> x86_64-normal-server-release/support/native/java.base/libjli_static.a)
> was built for newer OSX version (10.12) than being linked (10.7)
> ld: warning: object file (/Users/karianna/Documents/
> workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
> x86_64-normal-server-release/support/native/java.base/libjli_static.a)
> was built for newer OSX version (10.12) than being linked (10.7)
> *Undefined symbols for architecture x86_64:*
> *  "_libiconv", referenced from:*
> *  _convertUft8ToPlatformString in EncodingSupport_md.o*
> *  "_libiconv_open", referenced from:*
> *  _convertUft8ToPlatformString in EncodingSupport_md.o*
> *ld: symbol(s) not found for architecture x86_64*
> *clang: error: linker command failed with exit code 1 (use -v to see
> invocation)*
> cp: /Users/karianna/Documents/workspace/AdoptOpenJDK_
> Projects/jdk9dev/build/macosx-x86_64-normal-server-release/
> make-support/failure-logs/support_native_java.instrument_libinstrument_BUILD_LIBINSTRUMENT_link.log:
> No such file or directory
> make[3]: *** [/Users/karianna/Documents/workspace/AdoptOpenJDK_
> Projects/jdk9dev/build/macosx-x86_64-normal-server-release/
> support/modules_libs/java.instrument/libinstrument.dylib] Error 1
> make[2]: *** [java.instrument-libs] Error 2
> make[2]: *** Waiting for unfinished jobs
> ld: warning: object file (/Users/karianna/Documents/
> workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-
> x86_64-normal-server-release/support/native/java.base/libjli_static.a)
> was built for newer OSX version (10.12) than being linked (10.7)
>
>
> Cheers,
> Martijn
>

Building latest jdk9 dev on Mac OS X 10.12.1 - Undefined symbols (_libiconv) causing build to fail?

[Martijn Verburg]

Hi all,

I got past my previous issue (thanks Dmitry!), but I now have a new one
(after a fresh clone).  I notice I'm using the clang compiler by default,
not sure if that's supported.

-


ld: warning: object file
(/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-x86_64-normal-server-release/support/native/java.base/libjli_static.a)
was built for newer OSX version (10.12) than being linked (10.7)
Creating support/modules_libs/java.rmi/librmi.dylib from 1 file(s)
Creating support/modules_cmds/java.rmi/rmid from 1 file(s)
Creating support/modules_cmds/java.rmi/rmiregistry from 1 file(s)
ld: warning: object file
(/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-x86_64-normal-server-release/support/native/java.base/libjli_static.a)
was built for newer OSX version (10.12) than being linked (10.7)
ld: warning: object file
(/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-x86_64-normal-server-release/support/native/java.base/libjli_static.a)
was built for newer OSX version (10.12) than being linked (10.7)
*Undefined symbols for architecture x86_64:*
*  "_libiconv", referenced from:*
*  _convertUft8ToPlatformString in EncodingSupport_md.o*
*  "_libiconv_open", referenced from:*
*  _convertUft8ToPlatformString in EncodingSupport_md.o*
*ld: symbol(s) not found for architecture x86_64*
*clang: error: linker command failed with exit code 1 (use -v to see
invocation)*
cp:
/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-x86_64-normal-server-release/make-support/failure-logs/support_native_java.instrument_libinstrument_BUILD_LIBINSTRUMENT_link.log:
No such file or directory
make[3]: ***
[/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-x86_64-normal-server-release/support/modules_libs/java.instrument/libinstrument.dylib]
Error 1
make[2]: *** [java.instrument-libs] Error 2
make[2]: *** Waiting for unfinished jobs
ld: warning: object file
(/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9dev/build/macosx-x86_64-normal-server-release/support/native/java.base/libjli_static.a)
was built for newer OSX version (10.12) than being linked (10.7)


Cheers,
Martijn

Re: Compile error with jdk9-dev latest HEAD - missing com.sun.tools.jdi - on Mac OS X 10.12.1

[Martijn Verburg]

Hi Dmitry,

That's resolved that particular issue.  Out of curiosity, why id the usual
get_source.sh call not remove those files?

I know have a different issue, but I'll create a new thread for that.

Cheers,
Martijn

On 6 December 2016 at 14:22, Dmitry Samersoff 
wrote:

> Martijn,
>
> Could I ask you to clone fresh sources?
>
> SA-JDI classes was removed in Aug see - JDK-8158050
>
> -Dmitry
>
> On 2016-12-06 16:44, Martijn Verburg wrote:
> > Hi all,
> >
> > Just ran make clean image this morning and got:
> >
> > ...
> > ...
> > === Output from failing command(s) repeated here ===
> > * For target jdk_modules_jdk.hotspot.agent__the.jdk.hotspot.agent_batch:
> > /Users/karianna/Documents/workspace/AdoptOpenJDK_
> Projects/jdk9-dev/hotspot/src/jdk.hotspot.agent/share/
> classes/sun/jvm/hotspot/jdi/SACoreAttachingConnector.java:43:
> > error: package com.sun.tools.jdi does not exist
> > public
> > SACoreAttachingConnector(com.sun.tools.jdi.VirtualMachineManagerService
> > ignored) {
> >  ^
> > /Users/karianna/Documents/workspace/AdoptOpenJDK_
> Projects/jdk9-dev/hotspot/src/jdk.hotspot.agent/share/
> classes/sun/jvm/hotspot/jdi/SADebugServerAttachingConnector.java:42:
> > error: package com.sun.tools.jdi does not exist
> > public
> > SADebugServerAttachingConnector(com.sun.tools.jdi.
> VirtualMachineManagerService
> > ignored) {
> > ^
> > /Users/karianna/Documents/workspace/AdoptOpenJDK_
> Projects/jdk9-dev/hotspot/src/jdk.hotspot.agent/share/
> classes/sun/jvm/hotspot/jdi/SAPIDAttachingConnector.java:41:
> > error: package com.sun.tools.jdi does not exist
> > public
> > SAPIDAttachingConnector(com.sun.tools.jdi.VirtualMachineManagerService
> > ignored) {
> > ^
> > /Users/karianna/Documents/workspace/AdoptOpenJDK_
> Projects/jdk9-dev/hotspot/src/jdk.hotspot.agent/share/
> classes/sun/jvm/hotspot/jdi/VirtualMachineImpl.java:265:
> > error: package com.sun.tools.jdi does not exist
> >
> > ((com.sun.tools.jdi.VirtualMachineManagerImpl)mgr)
> .addVirtualMachine(this);
> >^
> >... (rest of output omitted)
> >
> > Before I dig further, has anyone else run across this?
> >
> > Cheers,
> > Martijn
> >
>
>
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.
>

Compile error with jdk9-dev latest HEAD - missing com.sun.tools.jdi - on Mac OS X 10.12.1

[Martijn Verburg]

Hi all,

Just ran make clean image this morning and got:

...
...
=== Output from failing command(s) repeated here ===
* For target jdk_modules_jdk.hotspot.agent__the.jdk.hotspot.agent_batch:
/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9-dev/hotspot/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/jdi/SACoreAttachingConnector.java:43:
error: package com.sun.tools.jdi does not exist
public
SACoreAttachingConnector(com.sun.tools.jdi.VirtualMachineManagerService
ignored) {
 ^
/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9-dev/hotspot/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/jdi/SADebugServerAttachingConnector.java:42:
error: package com.sun.tools.jdi does not exist
public
SADebugServerAttachingConnector(com.sun.tools.jdi.VirtualMachineManagerService
ignored) {
^
/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9-dev/hotspot/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/jdi/SAPIDAttachingConnector.java:41:
error: package com.sun.tools.jdi does not exist
public
SAPIDAttachingConnector(com.sun.tools.jdi.VirtualMachineManagerService
ignored) {
^
/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9-dev/hotspot/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/jdi/VirtualMachineImpl.java:265:
error: package com.sun.tools.jdi does not exist

((com.sun.tools.jdi.VirtualMachineManagerImpl)mgr).addVirtualMachine(this);
   ^
   ... (rest of output omitted)

Before I dig further, has anyone else run across this?

Cheers,
Martijn

Re: A couple of Build Issues (Mac OS X El Capitan / XCode 7.1)

[Martijn Verburg]

Nevermind, I wasn't building from the dev forest!

Cheers,
Martijn

On 24 October 2015 at 15:58, Martijn Verburg 
wrote:

> Hi all,
>
> I'm seeing a couple of issues when running make clean images
> (Configuration Summary is posted at the bottom):
>
> 1.) No rule to make CopyInterimCLDRConverter.gmk - this doesn't halt the
> build immediately, but looks suspicious.
>
> ..
> Compiling 5 files for BUILD_GENMODULESLIST
> make[3]: CopyInterimCLDRConverter.gmk: No such file or directory
> make[3]: *** No rule to make target `CopyInterimCLDRConverter.gmk'.  Stop.
> make[2]: *** [interim-cldrconverter] Error 2
> make[2]: *** Waiting for unfinished jobs
> ..
>
> 2.) An error due to a warning despite switching
> on --disable-warnings-as-errors
>
> 
>  
> /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:691:21:
> warning: 'ePtAttachDeprecated' is deprecated: PT_ATTACH is deprecated. See
> PT_ATTACHEXC [-Wdeprecated-declarations]
>   if ((res = ptrace(PT_ATTACH, pid, 0, 0)) < 0) {
> ^
> /usr/include/sys/ptrace.h:85:19: note: expanded from macro 'PT_ATTACH'
> #define PT_ATTACH   ePtAttachDeprecated /* trace some running
> process */
> ^
> /usr/include/sys/ptrace.h:71:2: note: 'ePtAttachDeprecated' has been
> explicitly marked deprecated here
> ePtAttachDeprecated __deprecated_enum_msg("PT_ATTACH is
> deprecated. See PT_ATTACHEXC") = 10
> ^
> 1 warning generated.
> 
>
> --
>
> Configuration summary:
> * Debug level:release
> * HS debug level: product
> * JDK variant:normal
> * JVM variants:   server
> * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
>
> Tools summary:
> * Boot JDK:   java version "1.8.0_60" Java(TM) SE Runtime Environment
> (build 1.8.0_60-b27) Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23,
> mixed mode)  (at
> /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home)
> * Toolchain:  clang (clang/LLVM)
> * C Compiler: Version Apple LLVM version 7.0.0 (clang-700.1.76)
> Target: x86_64-apple-darwin15.0.0 Thread model: posix (at /usr/bin/clang)
> * C++ Compiler:   Version Apple LLVM version 7.0.0 (clang-700.1.76)
> Target: x86_64-apple-darwin15.0.0 Thread model: posix (at /usr/bin/clang++)
>
> Build performance summary:
> * Cores to use:   4
> * Memory limit:   16384 MB
>
> Cheers,
> Martijn
>

A couple of Build Issues (Mac OS X El Capitan / XCode 7.1)

[Martijn Verburg]

Hi all,

I'm seeing a couple of issues when running make clean images (Configuration
Summary is posted at the bottom):

1.) No rule to make CopyInterimCLDRConverter.gmk - this doesn't halt the
build immediately, but looks suspicious.

..
Compiling 5 files for BUILD_GENMODULESLIST
make[3]: CopyInterimCLDRConverter.gmk: No such file or directory
make[3]: *** No rule to make target `CopyInterimCLDRConverter.gmk'.  Stop.
make[2]: *** [interim-cldrconverter] Error 2
make[2]: *** Waiting for unfinished jobs
..

2.) An error due to a warning despite switching
on --disable-warnings-as-errors


 
/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:691:21:
warning: 'ePtAttachDeprecated' is deprecated: PT_ATTACH is deprecated. See
PT_ATTACHEXC [-Wdeprecated-declarations]
  if ((res = ptrace(PT_ATTACH, pid, 0, 0)) < 0) {
^
/usr/include/sys/ptrace.h:85:19: note: expanded from macro 'PT_ATTACH'
#define PT_ATTACH   ePtAttachDeprecated /* trace some running
process */
^
/usr/include/sys/ptrace.h:71:2: note: 'ePtAttachDeprecated' has been
explicitly marked deprecated here
ePtAttachDeprecated __deprecated_enum_msg("PT_ATTACH is deprecated.
See PT_ATTACHEXC") = 10
^
1 warning generated.


--

Configuration summary:
* Debug level:release
* HS debug level: product
* JDK variant:normal
* JVM variants:   server
* OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64

Tools summary:
* Boot JDK:   java version "1.8.0_60" Java(TM) SE Runtime Environment
(build 1.8.0_60-b27) Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23,
mixed mode)  (at
/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home)
* Toolchain:  clang (clang/LLVM)
* C Compiler: Version Apple LLVM version 7.0.0 (clang-700.1.76) Target:
x86_64-apple-darwin15.0.0 Thread model: posix (at /usr/bin/clang)
* C++ Compiler:   Version Apple LLVM version 7.0.0 (clang-700.1.76) Target:
x86_64-apple-darwin15.0.0 Thread model: posix (at /usr/bin/clang++)

Build performance summary:
* Cores to use:   4
* Memory limit:   16384 MB

Cheers,
Martijn

Build success!

[Martijn Verburg]

Hi all,

In an attempt to be the most annoying person on build-dev in June (do you
hand out prizes, because I'm totally winning).  I'm now at the "error:
comparison of array 'rasterP->sppsm.offsets' not equal to a null pointer is
always true" bug aka https://bugs.openjdk.java.net/browse/JDK-8080993

The workaround suggested in that bug does the trick and I have jdk9
building once more.  Thnaks all!

Cheers,
Martijn

Re: Mac OS X - error: out-of-line definition of 'getenv' does not match any declaration in 'os' in os_bsd.cpp

[Martijn Verburg]

Hi David,

My bad, I was using http://hg.openjdk.java.net/jdk9/dev as opposed
to http://hg.openjdk.java.net/jdk9/jdk9 - of course this leads to my third
build issue which I'll post about with a separate title. Apologies all, I
appreciate it's painful to deal with the endless queries on my part, please
stack up the beverages score of what I owe all of you when we next meet in
person!


Cheers,
Martijn

On 17 June 2015 at 13:49, David Holmes  wrote:

> On 17/06/2015 9:06 PM, Martijn Verburg wrote:
>
>> Hi all,
>>
>> Building jdk9 on latest Mac OS X, XCode/Clang etc.  Not sure if the Mac OS
>> X build still needs to rely on BSD as such  I'll dig further but
>> figured it was worth reporting the initial error.
>>
>> ---
>>
>> Note: Recompile with -Xlint:unchecked for details.
>>
>> /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9/hotspot/src/os/bsd/vm/os_bsd.cpp:196:10:
>> error: out-of-line definition of 'getenv' does not match any declaration
>> in
>> 'os'
>> bool os::getenv(const char* name, char* buf, int len) {
>>
>
> os::getenv was removed. Are you working with an up to date and consistent
> source forest ??
>
> David
>
>
>^~
>
>> 1 error generated.
>> make[10]: *** [os_bsd.o] Error 1
>> make[10]: *** Waiting for unfinished jobs
>> make[9]: *** [the_vm] Error 2
>> make[8]: *** [product] Error 2
>> make[7]: *** [generic_build2] Error 2
>> make[6]: *** [product] Error 2
>> make[5]: *** [all_product_universal] Error 2
>> make[4]: *** [universal_product] Error 2
>> make[3]: ***
>>
>> [/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp]
>> Error 2
>> make[2]: *** [hotspot] Error 2
>>
>> ERROR: Build failed for targets 'clean images' in configuration
>> 'macosx-x86_64-normal-server-release' (exit code 2)
>> Hint: If caused by a warning, try configure --disable-warnings-as-errors
>>
>> make[1]: *** [main] Error 2
>> make: *** [clean] Error 2
>>
>> Cheers,
>> Martijn
>>
>>

Mac OS X - error: out-of-line definition of 'getenv' does not match any declaration in 'os' in os_bsd.cpp

[Martijn Verburg]

Hi all,

Building jdk9 on latest Mac OS X, XCode/Clang etc.  Not sure if the Mac OS
X build still needs to rely on BSD as such  I'll dig further but
figured it was worth reporting the initial error.

---

Note: Recompile with -Xlint:unchecked for details.
/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9/hotspot/src/os/bsd/vm/os_bsd.cpp:196:10:
error: out-of-line definition of 'getenv' does not match any declaration in
'os'
bool os::getenv(const char* name, char* buf, int len) {
 ^~
1 error generated.
make[10]: *** [os_bsd.o] Error 1
make[10]: *** Waiting for unfinished jobs
make[9]: *** [the_vm] Error 2
make[8]: *** [product] Error 2
make[7]: *** [generic_build2] Error 2
make[6]: *** [product] Error 2
make[5]: *** [all_product_universal] Error 2
make[4]: *** [universal_product] Error 2
make[3]: ***
[/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp]
Error 2
make[2]: *** [hotspot] Error 2

ERROR: Build failed for targets 'clean images' in configuration
'macosx-x86_64-normal-server-release' (exit code 2)
Hint: If caused by a warning, try configure --disable-warnings-as-errors

make[1]: *** [main] Error 2
make: *** [clean] Error 2

Cheers,
Martijn

Re: Error: SPEC mismatch! Current working directory does not match either TOPDIR, ORIGINAL_TOPDIR or CANONICAL_TOPDIR

[Martijn Verburg]

Hi Erik,

Thanks, renaming the directory to match the casing got me past that step.
I'm on the next issue now, I'll post with a separate subject.

Cheers,
Martijn

On 17 June 2015 at 11:28, Erik Joelsson  wrote:

> Hello Martijn,
>
> I believe this is a problem of string comparisons of file paths and
> character case. The file system on Macosx is case insensitive, but we
> aren't treating it as such properly. The difference is in the 'p' in
> 'project' in the directory name 'AdoptOpenJDK_projects'. The directory name
> on disk and the CWD are not in agreement of the case of that character. As
> a workaround, try CDing out and into the directory again but with the
> proper name and then rerun configure and make.
>
> /Erik
>
>
> On 2015-06-17 12:00, Martijn Verburg wrote:
>
>> Hi all,
>>
>> Sitting in the build OpenJDK workshop at Devoxx UK and I have the
>> following
>> issue on Mac OS X (building jdk9).
>>
>> Error: SPEC mismatch! Current working directory
>> /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9
>>
>> ---
>>
>> Seems to be related to:
>> http://hg.openjdk.java.net/jdk9/jdk9/rev/f077ae77feb1 and/or
>> http://hg.openjdk.java.net/jdk9/jdk9/rev/f658baecb743  ?
>>
>> ---
>>
>> Full configure and command details:
>>
>> A new configuration has been successfully created in
>>
>> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/build/macosx-x86_64-normal-server-release
>> using configure arguments
>>
>> '--with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/'.
>>
>> Configuration summary:
>> * Debug level:release
>> * HS debug level: product
>> * JDK variant:normal
>> * JVM variants:   server
>> * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
>>
>> Tools summary:
>> * Boot JDK:   java version "1.8.0_45" Java(TM) SE Runtime Environment
>> (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02,
>> mixed mode)  (at
>> /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home)
>> * Toolchain:  clang (clang/LLVM)
>> * C Compiler: Version Apple LLVM version 6.1.0 (clang-602.0.53) (based
>> on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix
>> (at
>> /usr/bin/clang)
>> * C++ Compiler:   Version Apple LLVM version 6.1.0 (clang-602.0.53) (based
>> on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix
>> (at
>> /usr/bin/clang++)
>>
>> Build performance summary:
>> * Cores to use:   4
>> * Memory limit:   16384 MB
>>
>> Martijns-MacBook-Pro:jdk9 karianna$ make clean install
>> Compiling 5 files for BUILD_GENMODULESLIST
>> Error: SPEC mismatch! Current working directory
>> /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9
>> does not match either TOPDIR, ORIGINAL_TOPDIR or CANONICAL_TOPDIR
>> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9
>> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9
>> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9
>>
>> /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9/make/Init.gmk:206:
>> *** Cannot continue.  Stop.
>> make: *** [clean] Error 2
>>
>> Cheers,
>> Martijn
>>
>
>

Error: SPEC mismatch! Current working directory does not match either TOPDIR, ORIGINAL_TOPDIR or CANONICAL_TOPDIR

[Martijn Verburg]

Hi all,

Sitting in the build OpenJDK workshop at Devoxx UK and I have the following
issue on Mac OS X (building jdk9).

Error: SPEC mismatch! Current working directory
/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9

---

Seems to be related to:
http://hg.openjdk.java.net/jdk9/jdk9/rev/f077ae77feb1 and/or
http://hg.openjdk.java.net/jdk9/jdk9/rev/f658baecb743  ?

---

Full configure and command details:

A new configuration has been successfully created in
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/build/macosx-x86_64-normal-server-release
using configure arguments
'--with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/'.

Configuration summary:
* Debug level:release
* HS debug level: product
* JDK variant:normal
* JVM variants:   server
* OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64

Tools summary:
* Boot JDK:   java version "1.8.0_45" Java(TM) SE Runtime Environment
(build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02,
mixed mode)  (at
/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home)
* Toolchain:  clang (clang/LLVM)
* C Compiler: Version Apple LLVM version 6.1.0 (clang-602.0.53) (based
on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix (at
/usr/bin/clang)
* C++ Compiler:   Version Apple LLVM version 6.1.0 (clang-602.0.53) (based
on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix (at
/usr/bin/clang++)

Build performance summary:
* Cores to use:   4
* Memory limit:   16384 MB

Martijns-MacBook-Pro:jdk9 karianna$ make clean install
Compiling 5 files for BUILD_GENMODULESLIST
Error: SPEC mismatch! Current working directory
/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9
does not match either TOPDIR, ORIGINAL_TOPDIR or CANONICAL_TOPDIR
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9
/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9/make/Init.gmk:206:
*** Cannot continue.  Stop.
make: *** [clean] Error 2

Cheers,
Martijn

Re: Mac OS X build errors missing instancetype + further issues just after building jdk.xml.ws

[Martijn Verburg]

Hi David,

Yes that is/was the original goal :-).  I note Vadim's later post about the
latest Clang support patch needing to land in jdk9, I'll wait until that
happens and post a followup.

Cheers,
Martijn

On 16 April 2015 at 22:18, David DeHaven  wrote:

> Sorry, I've had my blinders on for a few weeks. What's the original goal
> here? Are you just trying to build OpenJDK 9 on Mac OS X? If you're using
> clang in Xcode then it should "just work".
>
> -DrD-
>
> > On Apr 16, 2015, at 6:35 AM, Martijn Verburg 
> wrote:
> >
> > Hi David,
> >
> > Thanks for your response!  I was using GCC as I had a host of other
> errors when using clang :-|.  I'll post those in a separate mail for
> comparison.
> >
> > Cheers,
> > Martijn
> >
> > On 15 April 2015 at 18:22, David DeHaven 
> wrote:
> >
> > > Mac OS X 10.10.3, latest Xcode (6.3), using GCC 4.8
> > >
> > > 
> > >
> > > After getting past the defined(__OPENBSD__) bug I'm running into a
> host of
> > > new errors starting with:
> > >
> > >
> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26:
> > >
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/objc/NSObject.h:22:1:
> > > error: unknown type name 'instancetype'
> > > - (instancetype)self;
> > > ^
> >
> > You're using an SDK that's intended to be used exclusively with clang. I
> think you'd have to go back to MacOSX10.8.sdk for compatibility with gcc.
> >
> > I'm curious why you're even trying to compile with gcc?
> >
> > -DrD-
> >
> >
>
>

Re: Mac OS X build errors missing instancetype + further issues just after building jdk.xml.ws

[Martijn Verburg]

Hi David,

Thanks for your response!  I was using GCC as I had a host of other errors
when using clang :-|.  I'll post those in a separate mail for comparison.

Cheers,
Martijn

On 15 April 2015 at 18:22, David DeHaven  wrote:

>
> > Mac OS X 10.10.3, latest Xcode (6.3), using GCC 4.8
> >
> > 
> >
> > After getting past the defined(__OPENBSD__) bug I'm running into a host
> of
> > new errors starting with:
> >
> >
> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26:
> >
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/objc/NSObject.h:22:1:
> > error: unknown type name 'instancetype'
> > - (instancetype)self;
> > ^
>
> You're using an SDK that's intended to be used exclusively with clang. I
> think you'd have to go back to MacOSX10.8.sdk for compatibility with gcc.
>
> I'm curious why you're even trying to compile with gcc?
>
> -DrD-
>
>

Mac OS X build errors missing instancetype + further issues just after building jdk.xml.ws

[Martijn Verburg]

Hi all,

Mac OS X 10.10.3, latest Xcode (6.3), using GCC 4.8



After getting past the defined(__OPENBSD__) bug I'm running into a host of
new errors starting with:

/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/objc/NSObject.h:22:1:
error: unknown type name 'instancetype'
 - (instancetype)self;
 ^



The error listings are strong with this one, so I've paste binned the full
output :-)

http://pastebin.com/REgQA8i5

Cheers,
Martijn

Re: Build attempts to install /usr/local/jvm/ binary in an invalid location on Mac OS X

[Martijn Verburg]

Hi Magnus,

Thanks for the detailed explanation, appreciated as always!  I'll just
execute make clean images for now and reference the binary via its absolute
path as required.

Of course I'm now onto the next build error ;-).  But I'll open a separate
thread for that tomorrow.

Cheers,
Martijn

On 14 April 2015 at 11:46, Magnus Ihse Bursie  wrote:

> Hi Martijn,
>
> On 2015-04-14 10:05, Martijn Verburg wrote:
>
>> Hi all,
>>
>> Using Configuration:
>>
>> using configure arguments '--with-boot-jdk=/Library/
>> Java/JavaVirtualMachines
>> /jdk1.8.0_40.jdk/Contents/Home/ --with-tools-dir=/opt/local/bin/ --with-
>> toolchain-type=gcc --with-freetype-lib=/usr/X11/lib/ --with-freetype
>> -include=/usr/X11/include/freetype2/'.
>>
>> -
>>
>> It attempts to install a binary at /usr/local/jvm/openjdk-1.9.0-internal.
>> /
>> usr/local/jvm doesn't exist on Mac OS X and can't be created (need sudo)
>>
>
> The "install" target is probably in need of a lot of TLC. I wouldn't be
> surprised if it has bit-rotted. However, in all normal circumstances,
> running it *will* require root/sudo credentials -- the whole point is to
> install the newly built JDK into a system-wide location.
> The suggested commands for doing this is:
> > bash configure --prefix=...
> > make all
> > sudo make install
>
> so that you don't run more of the build than necessary as root. Also note
> that, in theory, you should be able to select another location using the
> build-in autoconf --prefix option. If you select a path writable by your
> user, you will not require the sudo part. I'm not sure how well tested that
> is, though.
>
> /Magnus
>
>

Build attempts to install /usr/local/jvm/ binary in an invalid location on Mac OS X

[Martijn Verburg]

Hi all,

Using Configuration:

using configure arguments '--with-boot-jdk=/Library/Java/JavaVirtualMachines
/jdk1.8.0_40.jdk/Contents/Home/ --with-tools-dir=/opt/local/bin/ --with-
toolchain-type=gcc --with-freetype-lib=/usr/X11/lib/ --with-freetype
-include=/usr/X11/include/freetype2/'.

-

It attempts to install a binary at /usr/local/jvm/openjdk-1.9.0-internal.  /
usr/local/jvm doesn't exist on Mac OS X and can't be created (need sudo)




Compiling 5 files for BUILD_GENMODULESLIST
Building targets 'clean install' in configuration
'macosx-x86_64-normal-server-release'
Cleaning hotspot build artifacts ... done
Cleaning jdk build artifacts ... done
Cleaning bootcycle-build build artifacts ... done
Cleaning test build artifacts ... done
Cleaning buildtools build artifacts ... done
Cleaning support build artifacts ... done
Cleaning images build artifacts ... done
Cleaning make-support build artifacts ... done
Cleaning test-make build artifacts ... done
Cleaning bundles build artifacts ... done
Cleaned all build artifacts.
Compiling 5 files for BUILD_GENMODULESLIST
Installing jdk image into /usr/local/jvm/openjdk-1.9.0-internal
and creating 0 links from /usr/local/bin into the jdk.
mkdir: /usr/local/jvm/openjdk-1.9.0-internal: Permission denied
make[3]: *** [install] Error 1
make[2]: *** [install] Error 2
make[1]: *** [main] Error 2
make: *** [clean] Error 2

Cheers,
Martijn

BSD variables not declared? (jdk8 & jdk 9 builds)

[Martijn Verburg]

Hi all,

On Mac OS X 10.10.2 using gcc 4.8 run make clean images

When compiling either jdk8 or jdk9 from scratch I get the following BSD
undefined errors:

Compiling
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp:1150:7:
error: "__FreeBSD__" is not defined [-Werror=undef]
 #elif __FreeBSD__
   ^
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp:1152:7:
error: "__OpenBSD__" is not defined [-Werror=undef]
 #elif __OpenBSD__
   ^
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp:1154:7:
error: "__NetBSD__" is not defined [-Werror=undef]
 #elif __NetBSD__
   ^



Cheers,
Martijn

Re: FYI: Build system rewrite in Ant

[Martijn Verburg]

I'm personally willing to provide a ANT to MAVEN conversion tool which will
allow for a more verbose an rdable build system.  It will also ensure that
dependencies are always downloaded at all times ensuring network pipes are
kept clean.

Cheers,
Martijn

On 1 April 2015 at 10:21, David Katleman (Oracle)  wrote:

> +1
>
> Please say were going to use the extension that predict build failures
> before they occur and provides an automated root cause analysis.  I believe
> is called Ant predictive recursive interpreter language with Forensic
> object oriented linguistic syntax.
>
>
> > On Apr 1, 2015, at 1:33 AM, Magnus Ihse Bursie <
> magnus.ihse.bur...@oracle.com> wrote:
> >
> > The build system currently uses make to build OpenJDK. This is a
> technology that has been around for decades, and in places this legacy
> clearly shows.
> >
> > An alternative build tool, Ant, is based on cutting-edge technology.
> Compared to the native GNU Make, Ant is based on Java™ technology, which
> makes portability issues a thing of the past. Ant is also directed using
> modern XML systems, with well-defined tags, compared to the aged and
> idiosyncratic Makefile syntax.
> >
> > The Build Team has therefore decided to rewrite the current build system
> from scratch in Ant. The old Makefiles will be put in maintenance mode
> while the new Ant scripts are being developed. To facilitate a speedy
> switch, all new build enhancements must be expressed in Ant logic, starting
> today. No modifications in the old Makefiles will be accepted by the Build
> Team.
> >
> > To increase the robustness of the code base, the new build system will
> automatically check the integrity of all source code files before
> compilation. Each source file therefore must be accompanied by a Integrity
> Manifest (.Ingeg_Manif.xml). For instance, the file Object.java would have
> an Object.java.Integ_Manif.xml. This is a simple xml file, describing the
> purpose of the source code file, and a log of mercurial changeset id:s. An
> example file could looks like this:
> >
> > http://openjdk.java.net/ns/manifest/integrity/1";>
> >net.java.openjdk.build.ant.manifest.integrity
> >
> >
> >
> >   Object.java
> >   Class Object is the root of the class
> hierarchy.
> >
> >
> >
> >
> >
> >
> >541a8cef4e0d
> >
> mercurial
> >
> >
> >458adf31ad5b
> >
> mercurial
> >
> >
> >0846eddb56d5
> >
> mercurial
> >
> >
> >
> > 
> >
> > Each time a new version of the file is committed to the mercurial repo,
> the developer just has to add a new committed-change stanza to the block in
> the .Ingeg_Manif.xml file. Since the changeset ID is not known before hand,
> the Integrity Manifest file must be updated in a subsequent commit.
> >
> > But fear not! To assist developers in preserving the integrity of the
> source files, an addition to jcheck has been developed. If the subsequent
> commit does not properly describe the previous changeset ID, the original
> changeset will be automatically reverted, so no untracked changes will be
> stored permanently in the revision control system.
> >
> > Finally, to fully utilize the promise of portability that the Ant and
> Java™ technology brings, platforms with portability issues will be removed
> from the supported platform matrix. Currently, this only includes
> non-POSIX-compliant operating systems, since these have been known to cause
> various platform issues in the build system. The only known
> non-POSIX-compliant OS that the OpenJDK build system currently supports is
> the Windows OS family, so this reduction in support is hopefully not too
> burdensome.
> >
> > These changes will take immediate effect of today, April 1 2015.
> >
> > That's all for today, folks! :-)
> >
> > /Magnus
>

Re: Build error with javac Main not being found when building java.transaction module on Mac OS X

[Martijn Verburg]

Hi Magnus,

I had been working on the README-build.html file, but apart from that
nothing else.

Cheers,
Martijn

On 10 February 2015 at 08:53, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> That sounds a bit weird. get_source should do a pull and update on the
> top-level repo as well, so a separate hg update should not be needed.
>
> Did you have local changes requiring a merge?
>
> /Magnus
>
> > 9 feb 2015 kl. 12:46 skrev Martijn Verburg :
> >
> > @Erik and everyone else,
> >
> > , my sincere apologies and thank you for your
> > patience!  Indeed the modules.xml file was out of date. My script which
> > executes 'hg update' each morning had been silently failing for some
> time.
> > This is a good lesson for the build guide though, I'll add a note to
> remind
> > people that once they clone the top level repository that they should
> also
> > hg update as well as ./get_source.sh.
> >
> > I now have separate build errors (of course!), these ones seem a little
> > more genuine, around the compilation / linking of desktop code with Mac
> > native libs.  There are too many to list, but here's an example of one
> below
> >
> > ===
> >
> > Creating libjsound.dylib from 17 file(s)
> > In file included from /usr/include/dispatch/dispatch.h:51:0,
> > from
> >
> /System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15,
> > from
> >
> /System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13,
> > from
> >
> /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55,
> > from
> > /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:6,
> > from
> > /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12,
> > from
> >
> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/jdk/src/java.desktop/macosx/native/libosxapp/AWT_debug.h:29,
> > from
> >
> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/jdk/src/java.desktop/macosx/native/libosxapp/AWT_debug.m:26:
> > /usr/include/dispatch/object.h:143:15: error: expected identifier or '('
> > before '^' token
> > typedef void (^dispatch_block_t)(void);
> >   ^
> > /usr/include/dispatch/object.h:362:3: error: unknown type name
> > 'dispatch_block_t'
> >   dispatch_block_t notification_block);
> >   ^
> >
> > Is this perhaps me using an unsupported compiler?  My C/C++ toolchain is:
> >
> > ...
> > * Toolchain:  clang (clang/LLVM)
> > * C Compiler: Version Apple LLVM version 6.0 (clang-600.0.56) (based
> on
> > LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at
> > /usr/bin/clang)
> > * C++ Compiler:   Version Apple LLVM version 6.0 (clang-600.0.56) (based
> on
> > LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at
> > /usr/bin/clang++)
> > ...
> >
> >
> >
> > Cheers,
> > Martijn
> >
> >> On 9 February 2015 at 10:35, Erik Joelsson 
> wrote:
> >>
> >> Then please check that your top level repo is properly up to date. It
> >> should contain:
> >>
> >>  
> >>java.transaction
> >>java.base
> >>java.rmi
> >>
> >>  javax.transaction
> >>
> >>  
> >>
> >> /Erik
> >>
> >>
> >> On 2015-02-09 11:32, Martijn Verburg wrote:
> >>
> >> Hi Erik,
> >>
> >> You're correct, the module-deps.gmk file does not have java.transaction
> >> in there.
> >>
> >> modules.xml does contain it as an export for java.corba (which depends
> >> on java.base), i.e.
> >>
> >>   
> >>java.corba
> >>java.base
> >>java.desktop
> >>java.logging
> >>java.naming
> >>java.rmi
> >> ...
> >>
> >>   javax.transaction
> >>
> >> ...
> >>
> >> I'm also going to try Magnus's suggestion.
> >>
> >> Cheers,
> >> Martijn
> >>
> >> On 9 February 2015 at 09:32, Erik Joelsson 
> >> wrote:
> >>
> >>> So you have the source files for java.transaction in your jdk repo.
> Does
> >>> your modules.xml list that module? At the start of the build, we
> genera

Re: Build error with javac Main not being found when building java.transaction module on Mac OS X

[Martijn Verburg]

@Erik and everyone else,

, my sincere apologies and thank you for your
patience!  Indeed the modules.xml file was out of date. My script which
executes 'hg update' each morning had been silently failing for some time.
This is a good lesson for the build guide though, I'll add a note to remind
people that once they clone the top level repository that they should also
hg update as well as ./get_source.sh.

I now have separate build errors (of course!), these ones seem a little
more genuine, around the compilation / linking of desktop code with Mac
native libs.  There are too many to list, but here's an example of one below

===

Creating libjsound.dylib from 17 file(s)
In file included from /usr/include/dispatch/dispatch.h:51:0,
 from
/System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15,
 from
/System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13,
 from
/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55,
 from
/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:6,
 from
/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12,
 from
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/jdk/src/java.desktop/macosx/native/libosxapp/AWT_debug.h:29,
 from
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/jdk/src/java.desktop/macosx/native/libosxapp/AWT_debug.m:26:
/usr/include/dispatch/object.h:143:15: error: expected identifier or '('
before '^' token
 typedef void (^dispatch_block_t)(void);
   ^
/usr/include/dispatch/object.h:362:3: error: unknown type name
'dispatch_block_t'
   dispatch_block_t notification_block);
   ^

Is this perhaps me using an unsupported compiler?  My C/C++ toolchain is:

...
* Toolchain:  clang (clang/LLVM)
* C Compiler: Version Apple LLVM version 6.0 (clang-600.0.56) (based on
LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at
/usr/bin/clang)
* C++ Compiler:   Version Apple LLVM version 6.0 (clang-600.0.56) (based on
LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at
/usr/bin/clang++)
...



Cheers,
Martijn

On 9 February 2015 at 10:35, Erik Joelsson  wrote:

>  Then please check that your top level repo is properly up to date. It
> should contain:
>
>   
> java.transaction
> java.base
> java.rmi
> 
>   javax.transaction
> 
>   
>
> /Erik
>
>
> On 2015-02-09 11:32, Martijn Verburg wrote:
>
> Hi Erik,
>
>  You're correct, the module-deps.gmk file does not have java.transaction
> in there.
>
>  modules.xml does contain it as an export for java.corba (which depends
> on java.base), i.e.
>
>
> java.corba
> java.base
> java.desktop
> java.logging
> java.naming
> java.rmi
>  ...
> 
>javax.transaction
> 
>  ...
>
>  I'm also going to try Magnus's suggestion.
>
>  Cheers,
> Martijn
>
> On 9 February 2015 at 09:32, Erik Joelsson 
> wrote:
>
>> So you have the source files for java.transaction in your jdk repo. Does
>> your modules.xml list that module? At the start of the build, we generate
>> build//make-support/module-deps.gmk from modules.xml from which
>> we construct the correct make dependencies between module targets. I'm
>> guessing java.transaction is not showing up in your module-deps.gmk.
>>
>> If java.transaction doesn't show up in modules-deps.gmk, we are missing
>> that java.transaction-java depends on java.base-java, so make will start
>> running java.transaction-java earlier than it should.
>>
>> /Erik
>>
>>
>> On 2015-02-06 16:45, Martijn Verburg wrote:
>>
>>> Hi Erik/Alan,
>>>
>>> Not sure if this information is useful at all but the following tmp file
>>> was left behind:
>>>
>>>
>>> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/build/macosx-
>>> x86_64-normal-server-release/jdk/modules/java.transaction/_
>>> the.java.transaction_batch.tmp
>>>
>>> It contains:
>>>
>>>
>>> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/jdk/src/java.transaction/share/classes/javax/transaction/InvalidTransactionException.java
>>>
>>> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/jdk/src/java.transaction/share/classes/javax/transaction/TransactionRequiredException.java
>>>
>>> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/jdk/src/java.transaction/share/classes/javax/transaction/TransactionRolledbackExce

Re: Build error with javac Main not being found when building java.transaction module on Mac OS X

[Martijn Verburg]

/Documents/workspace/AdoptOpenJDK_projects/jdk9/jdk/make
-I/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/jdk/make/copy
MODULE=jdk.jdwp.agent MAKEFILE_PREFIX=Copy)
(cd /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/jdk/make
&& /usr/bin/make  VERBOSE="" LOG_LEVEL="debug" -R -I
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/make/common
SPEC="/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9/build/macosx-x86_64-normal-server-release/spec.gmk"
VERBOSE="" MAIN_TARGETS="all" LOG_LEVEL="debug" LOG="debug" -f
CopySamples.gmk)
SetupCopyFiles(COPY_LIBS_TO_LIB)
...
...

=======

To Erik's later suggestion, there's also no mention of java.transaction in
the module-deps.gmk file.

Cheers,
Martijn

On 6 February 2015 at 23:16, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> On 2015-02-06 17:46, Martijn Verburg wrote:
>
>>
>> /Users/karianna/Documents/workspace/AdoptOpenJDK_
>> projects/jdk9/build/macosx-x86_64-normal-server-release/
>> buildtools/interim_langtools.jar
>> does not exist!  So it's not being built correctly or moved to the right
>> place.
>>
>> I'm not seeing any other clues (even at trace) that indicates why
>> interim_langtools.jar has not been built
>>
>
> Sometimes mercurial forests can get messed up. If an unmodified source
> fails to compile after dist-clean, this can be the case. One thing to to is
> to try and re-clone the forest. Make sure get_source.sh runs to completion
> without any errors.
>
> Otherwise, you have narrowed down the issue quite well. We need to figure
> out why interim_langtools.jar is not being built.
>
> Start by rm -rf build && configure.
>
> Then run "make interim-langtools". Check the contents of
> build/$BUILD/buildtools. Is it there? If so, you should be able to do just
> "make" and continue.
>
> Otherwise, start again with more logging. rm -rf build && configure &&
> make interim-langtools LOG=debug  (trace is not being helpful).
>
> /Magnus
>

Re: Build error with javac Main not being found when building java.transaction module on Mac OS X

[Martijn Verburg]

Hi Erik,

You're correct, the module-deps.gmk file does not have java.transaction in
there.

modules.xml does contain it as an export for java.corba (which depends on
java.base), i.e.

  
java.corba
java.base
java.desktop
java.logging
java.naming
java.rmi
 ...

  javax.transaction

...

I'm also going to try Magnus's suggestion.

Cheers,
Martijn

On 9 February 2015 at 09:32, Erik Joelsson  wrote:

> So you have the source files for java.transaction in your jdk repo. Does
> your modules.xml list that module? At the start of the build, we generate
> build//make-support/module-deps.gmk from modules.xml from
> which we construct the correct make dependencies between module targets.
> I'm guessing java.transaction is not showing up in your module-deps.gmk.
>
> If java.transaction doesn't show up in modules-deps.gmk, we are missing
> that java.transaction-java depends on java.base-java, so make will start
> running java.transaction-java earlier than it should.
>
> /Erik
>
>
> On 2015-02-06 16:45, Martijn Verburg wrote:
>
>> Hi Erik/Alan,
>>
>> Not sure if this information is useful at all but the following tmp file
>> was left behind:
>>
>> /Users/karianna/Documents/workspace/AdoptOpenJDK_
>> projects/jdk9/build/macosx-
>> x86_64-normal-server-release/jdk/modules/java.transaction/_
>> the.java.transaction_batch.tmp
>>
>> It contains:
>>
>> /Users/karianna/Documents/workspace/AdoptOpenJDK_
>> projects/jdk9/jdk/src/java.transaction/share/classes/javax/transaction/
>> InvalidTransactionException.java
>> /Users/karianna/Documents/workspace/AdoptOpenJDK_
>> projects/jdk9/jdk/src/java.transaction/share/classes/javax/transaction/
>> TransactionRequiredException.java
>> /Users/karianna/Documents/workspace/AdoptOpenJDK_
>> projects/jdk9/jdk/src/java.transaction/share/classes/javax/transaction/
>> TransactionRolledbackException.java
>>
>>
>> Cheers,
>> Martijn
>>
>> On 6 February 2015 at 15:42, Martijn Verburg 
>> wrote:
>>
>>  Hi Alan,
>>>
>>> Thanks for the quick response!  I've executed:
>>>
>>> rm -rf build
>>> bash configure
>>> make clean images
>>>
>>> ==
>>>
>>> Unfortunately the same error comes up:
>>>
>>> 
>>> Cleaned all build artifacts.
>>> Building OpenJDK for target 'clean images' in configuration
>>> 'macosx-x86_64-normal-server-release'
>>> 
>>> Compiling 5 files for BUILD_GENMODULESLIST
>>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS
>>> Compiling 3 files for java.transaction
>>> Error: Could not find or load main class com.sun.tools.javac.Main
>>> make[3]: ***
>>> [/Users/karianna/Documents/workspace/AdoptOpenJDK_
>>> projects/jdk9/build/macosx-x86_64-normal-server-release/
>>> jdk/modules/java.transaction/_the.java.transaction_batch]
>>> Error 1
>>> make[2]: *** [java.transaction-java] Error 2
>>> make[2]: *** Waiting for unfinished jobs
>>> 
>>>
>>>
>>> Cheers,
>>> Martijn
>>>
>>> On 6 February 2015 at 11:43, Alan Bateman 
>>> wrote:
>>>
>>>  On 06/02/2015 11:32, Martijn Verburg wrote:
>>>>
>>>>  Hi all,
>>>>>
>>>>> Apologies if this has already been reported before!
>>>>>
>>>>> Build from HEAD (jdk9) today I get the following error running make
>>>>> clean
>>>>> images:
>>>>>
>>>>> make clean images
>>>>> Cleaning hotspot build artifacts ... done
>>>>> Cleaning jdk build artifacts ... done
>>>>> Cleaning bootcycle-build build artifacts ... done
>>>>> Cleaning test build artifacts ... done
>>>>> Cleaning buildtools build artifacts ... done
>>>>> Cleaning support build artifacts ... done
>>>>> Cleaning images build artifacts ... done
>>>>> Cleaning make-support build artifacts ... done
>>>>> Cleaned all build artifacts.
>>>>> Building OpenJDK for target 'clean images' in configuration
>>>>> 'macosx-x86_64-normal-server-release'
>>>>>
>>>>> Compiling 5 files for BUILD_GENMODULESLIST
>>>>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS
>>>>> Compiling 3 files for java.transaction
>>>>> Error: Could not find or load main class com.sun.tools.javac.Main
>>>>> make[3]: ***
>>>>> [/Users/karianna/Documents/workspace/AdoptOpenJDK_
>>>>> projects/jdk9/build/macosx-x86_64-normal-server-release/
>>>>> jdk/modules/java.transaction/_the.java.transaction_batch]
>>>>> Error 1
>>>>> make[2]: *** [java.transaction-java] Error 2
>>>>> make[2]: *** Waiting for unfinished jobs
>>>>>
>>>>>   I wonder if this is residual files left behind from a previous build.
>>>>>
>>>> We did some refactoring a few weeks ago to create the java.transaction
>>>> module and that required moving code between the corba and jdk repo.
>>>>
>>>> Can you blow away your build directory and configure && make again?
>>>>
>>>> -Alan
>>>>
>>>>
>>>
>

Re: README-builds.html update

[Martijn Verburg]

Hi all,

So I started digging into this (just the HTML path to start with) and the
diff got pretty ridiculous. So I'm going to split the work into several
parts:

1.) Fix HTML warnings and convert HTML styling to CSS styling (using
internal stylesheet)

2.) Cosmetic changes to improve readability (change background to white for
contrast, pick a more web readable font etc) and cleaning up any
comments/whitespace in the document.

3.) Structural changes (moving sections around if that seems sensible, I'll
post suggestions first)

4.) Finicky detail changes (the bit that will require the detailed review)

I may combine 1&2 if the diff isn't ridiculously different.

==

If there's further consensus on Markdown then I can give that a go later
(HTML to Markdown converter to start with anyone? ;-)), but I suspect
Markdown readers aren't as ubiquitous as HTML readers and we'd have also
have to include an "export to output type X" step/tool, not sure how much
work that is, where it would get done etc.

Sound reasonable?


Cheers,
Martijn

On 5 February 2015 at 22:43, Omair Majid  wrote:

> * 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 to get it right. Does it sound like a good
> idea?
>
> I really like this idea! With just the right amount of formatting,
> markdown is both easy to read by humans as plain text and turns into
> pretty good looking html too.
>
> Cheers,
> Omair
>
> --
> PGP Key: 66484681 (http://pgp.mit.edu/)
> Fingerprint = F072 555B 0A17 3957 4E95  0056 F286 F14F 6648 4681
>

Re: Build error with javac Main not being found when building java.transaction module on Mac OS X

[Martijn Verburg]

Hi Andrew,

Thanks, that was dense of me not to do that first.

Using debug output I discover that there are more than just one javac
involved, one from interim_langtools.jar



...
SetupJavaCompiler(BOOT_JAVAC)
 [2] JAVAC :=
/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/bin/javac
 [3] FLAGS := -XDignore.symbol.file=true -g -Xlint:all,-deprecation -Werror
...
...
SetupJavaCompiler(GENERATE_USINGJDKBYTECODE)
 [2] JVM :=
/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/bin/java
-XX:+UseSerialGC -Xms32M -Xmx512M
 [3] JAVAC :=
"-Xbootclasspath/p:/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/build/macosx-x86_64-normal-server-release/buildtools/interim_langtools.jar"
-cp
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/build/macosx-x86_64-normal-server-release/buildtools/interim_langtools.jar
com.sun.tools.javac.Main
 [4] FLAGS := -bootclasspath
":/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/build/macosx-x86_64-normal-server-release/jdk/modules/java.transaction"
-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally
 [5] SERVER_DIR :=
 [6] SERVER_JVM :=
/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/bin/java
-d64 -Xms512M -Xmx2048M
...

==

/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/build/macosx-x86_64-normal-server-release/buildtools/interim_langtools.jar
does not exist!  So it's not being built correctly or moved to the right
place.

I'm not seeing any other clues (even at trace) that indicates why
interim_langtools.jar has not been built




Cheers,
Martijn

On 6 February 2015 at 16:24, Andrew Haley  wrote:

> On 02/06/2015 04:20 PM, Martijn Verburg wrote:
> > Is there a way of printing out the absolute path to the javac it might be
> > trying to execute?  I wonder if it goes looking elsewhere during the
> > build...
>
> Are you not building with LOG=debug ?
>
> Andrew.
>
>

Re: Build error with javac Main not being found when building java.transaction module on Mac OS X

[Martijn Verburg]

Hi Alan,

On 6 February 2015 at 16:06, Alan Bateman  wrote:

>  On 06/02/2015 15:42, Martijn Verburg wrote:
>
> Hi Alan,
>
>  Thanks for the quick response!  I've executed:
>
>  rm -rf build
> bash configure
> make clean images
>
>  ==
>
>  Unfortunately the same error comes up:
>
>  
>  Cleaned all build artifacts.
> Building OpenJDK for target 'clean images' in configuration
> 'macosx-x86_64-normal-server-release'
> 
> Compiling 5 files for BUILD_GENMODULESLIST
> Compiling 8 files for BUILD_TOOLS_LANGTOOLS
> Compiling 3 files for java.transaction
> Error: Could not find or load main class com.sun.tools.javac.Main
>
>   I wonder if this last message is the clue. For the boot JDK then does
> bin/javac -version work? I would be surprised to get through the configure
> step if the boot JDK isn't set right but worth checking.
>

According to bash configure my boot JDK is:

* Boot JDK:   java version "1.8.0_31" Java(TM) SE Runtime Environment
(build 1.8.0_31-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07,
mixed mode)  (at
/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home)

Executing:

/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/bin/javac
-version

I get

javac 1.8.0_31

Is there a way of printing out the absolute path to the javac it might be
trying to execute?  I wonder if it goes looking elsewhere during the
build...

Cheers,
Martijn



>
>
> -Alan.
>

Re: Build error with javac Main not being found when building java.transaction module on Mac OS X

[Martijn Verburg]

Hi Erik/Alan,

Not sure if this information is useful at all but the following tmp file
was left behind:

/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/build/macosx-
x86_64-normal-server-release/jdk/modules/java.transaction/_
the.java.transaction_batch.tmp

It contains:

/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/jdk/src/java.transaction/share/classes/javax/transaction/InvalidTransactionException.java
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/jdk/src/java.transaction/share/classes/javax/transaction/TransactionRequiredException.java
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/jdk/src/java.transaction/share/classes/javax/transaction/TransactionRolledbackException.java


Cheers,
Martijn

On 6 February 2015 at 15:42, Martijn Verburg 
wrote:

> Hi Alan,
>
> Thanks for the quick response!  I've executed:
>
> rm -rf build
> bash configure
> make clean images
>
> ==
>
> Unfortunately the same error comes up:
>
> 
> Cleaned all build artifacts.
> Building OpenJDK for target 'clean images' in configuration
> 'macosx-x86_64-normal-server-release'
> 
> Compiling 5 files for BUILD_GENMODULESLIST
> Compiling 8 files for BUILD_TOOLS_LANGTOOLS
> Compiling 3 files for java.transaction
> Error: Could not find or load main class com.sun.tools.javac.Main
> make[3]: ***
> [/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/build/macosx-x86_64-normal-server-release/jdk/modules/java.transaction/_the.java.transaction_batch]
> Error 1
> make[2]: *** [java.transaction-java] Error 2
> make[2]: *** Waiting for unfinished jobs
> ....
>
>
> Cheers,
> Martijn
>
> On 6 February 2015 at 11:43, Alan Bateman  wrote:
>
>> On 06/02/2015 11:32, Martijn Verburg wrote:
>>
>>> Hi all,
>>>
>>> Apologies if this has already been reported before!
>>>
>>> Build from HEAD (jdk9) today I get the following error running make clean
>>> images:
>>>
>>> make clean images
>>> Cleaning hotspot build artifacts ... done
>>> Cleaning jdk build artifacts ... done
>>> Cleaning bootcycle-build build artifacts ... done
>>> Cleaning test build artifacts ... done
>>> Cleaning buildtools build artifacts ... done
>>> Cleaning support build artifacts ... done
>>> Cleaning images build artifacts ... done
>>> Cleaning make-support build artifacts ... done
>>> Cleaned all build artifacts.
>>> Building OpenJDK for target 'clean images' in configuration
>>> 'macosx-x86_64-normal-server-release'
>>>
>>> Compiling 5 files for BUILD_GENMODULESLIST
>>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS
>>> Compiling 3 files for java.transaction
>>> Error: Could not find or load main class com.sun.tools.javac.Main
>>> make[3]: ***
>>> [/Users/karianna/Documents/workspace/AdoptOpenJDK_
>>> projects/jdk9/build/macosx-x86_64-normal-server-release/
>>> jdk/modules/java.transaction/_the.java.transaction_batch]
>>> Error 1
>>> make[2]: *** [java.transaction-java] Error 2
>>> make[2]: *** Waiting for unfinished jobs
>>>
>>>  I wonder if this is residual files left behind from a previous build.
>> We did some refactoring a few weeks ago to create the java.transaction
>> module and that required moving code between the corba and jdk repo.
>>
>> Can you blow away your build directory and configure && make again?
>>
>> -Alan
>>
>
>

Re: Build error with javac Main not being found when building java.transaction module on Mac OS X

[Martijn Verburg]

Hi Alan,

Thanks for the quick response!  I've executed:

rm -rf build
bash configure
make clean images

==

Unfortunately the same error comes up:


Cleaned all build artifacts.
Building OpenJDK for target 'clean images' in configuration
'macosx-x86_64-normal-server-release'

Compiling 5 files for BUILD_GENMODULESLIST
Compiling 8 files for BUILD_TOOLS_LANGTOOLS
Compiling 3 files for java.transaction
Error: Could not find or load main class com.sun.tools.javac.Main
make[3]: ***
[/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/build/macosx-x86_64-normal-server-release/jdk/modules/java.transaction/_the.java.transaction_batch]
Error 1
make[2]: *** [java.transaction-java] Error 2
make[2]: *** Waiting for unfinished jobs



Cheers,
Martijn

On 6 February 2015 at 11:43, Alan Bateman  wrote:

> On 06/02/2015 11:32, Martijn Verburg wrote:
>
>> Hi all,
>>
>> Apologies if this has already been reported before!
>>
>> Build from HEAD (jdk9) today I get the following error running make clean
>> images:
>>
>> make clean images
>> Cleaning hotspot build artifacts ... done
>> Cleaning jdk build artifacts ... done
>> Cleaning bootcycle-build build artifacts ... done
>> Cleaning test build artifacts ... done
>> Cleaning buildtools build artifacts ... done
>> Cleaning support build artifacts ... done
>> Cleaning images build artifacts ... done
>> Cleaning make-support build artifacts ... done
>> Cleaned all build artifacts.
>> Building OpenJDK for target 'clean images' in configuration
>> 'macosx-x86_64-normal-server-release'
>>
>> Compiling 5 files for BUILD_GENMODULESLIST
>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS
>> Compiling 3 files for java.transaction
>> Error: Could not find or load main class com.sun.tools.javac.Main
>> make[3]: ***
>> [/Users/karianna/Documents/workspace/AdoptOpenJDK_
>> projects/jdk9/build/macosx-x86_64-normal-server-release/
>> jdk/modules/java.transaction/_the.java.transaction_batch]
>> Error 1
>> make[2]: *** [java.transaction-java] Error 2
>> make[2]: *** Waiting for unfinished jobs
>>
>>  I wonder if this is residual files left behind from a previous build. We
> did some refactoring a few weeks ago to create the java.transaction module
> and that required moving code between the corba and jdk repo.
>
> Can you blow away your build directory and configure && make again?
>
> -Alan
>

Re: Build error with javac Main not being found when building java.transaction module on Mac OS X

[Martijn Verburg]

Hi Erik,

Thanks for the quick response! I ran:

make dist-clean
bash configure
make clean images

Slightly different message this time, no error for missing javac.Main, but
a warning on missing interim_langtools.jar (could be unrelated to the real
issue).  Will also try Alan's suggestion next.



Compiling 5 files for BUILD_GENMODULESLIST
Compiling 8 files for BUILD_TOOLS_LANGTOOLS
Compiling 3 files for java.transaction
warning: [path] bad path element "/Users/karianna/Documents/workspace/
AdoptOpenJDK_projects/jdk9/build/macosx-x86_64-normal-server-release/
buildtools/interim_langtools.jar": no such file or directory
error: warnings found and -Werror specified
1 error
1 warning
make[3]: *** [/Users/karianna/Documents/workspace/AdoptOpenJDK
_projects/jdk9/build/macosx-x86_64-normal-server-release/jdk/modules/java.transaction/_the.java.transaction_batch]
Error 1
make[2]: *** [java.transaction-java] Error 2
make[2]: *** Waiting for unfinished jobs
warning: [options] bootstrap class path not set in conjunction with -source
1.6
...

Cheers,
Martijn

On 6 February 2015 at 11:42, Erik Joelsson  wrote:

> This looks like a mismatch between the modules make finds and the
> dependencies calculated between them. Make sure all your repos are up to
> date and try dist-clean and rerun configure.
>
> /Erik
>
>
> On 2015-02-06 12:32, Martijn Verburg wrote:
>
>> Hi all,
>>
>> Apologies if this has already been reported before!
>>
>> Build from HEAD (jdk9) today I get the following error running make clean
>> images:
>>
>> make clean images
>> Cleaning hotspot build artifacts ... done
>> Cleaning jdk build artifacts ... done
>> Cleaning bootcycle-build build artifacts ... done
>> Cleaning test build artifacts ... done
>> Cleaning buildtools build artifacts ... done
>> Cleaning support build artifacts ... done
>> Cleaning images build artifacts ... done
>> Cleaning make-support build artifacts ... done
>> Cleaned all build artifacts.
>> Building OpenJDK for target 'clean images' in configuration
>> 'macosx-x86_64-normal-server-release'
>>
>> Compiling 5 files for BUILD_GENMODULESLIST
>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS
>> Compiling 3 files for java.transaction
>> Error: Could not find or load main class com.sun.tools.javac.Main
>> make[3]: ***
>> [/Users/karianna/Documents/workspace/AdoptOpenJDK_
>> projects/jdk9/build/macosx-x86_64-normal-server-release/
>> jdk/modules/java.transaction/_the.java.transaction_batch]
>> Error 1
>> make[2]: *** [java.transaction-java] Error 2
>> make[2]: *** Waiting for unfinished jobs
>>
>> 
>>
>> I have the following configuration and have also tried using JDK 9 b44 as
>> the boot JDK :
>>
>> 
>> The existing configuration has been successfully updated in
>> /Users/karianna/Documents/workspace/AdoptOpenJDK_
>> projects/jdk9/build/macosx-x86_64-normal-server-release
>> using configure arguments
>> '--with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk1.
>> 8.0_31.jdk/Contents/Home/'.
>>
>> Configuration summary:
>> * Debug level:release
>> * HS debug level: product
>> * JDK variant:normal
>> * JVM variants:   server
>> * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
>>
>> Tools summary:
>> * Boot JDK:   java version "1.8.0_31" Java(TM) SE Runtime Environment
>> (build 1.8.0_31-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07,
>> mixed mode)  (at
>> /Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home)
>> * Toolchain:  clang (clang/LLVM)
>> * C Compiler: Version Apple LLVM version 6.0 (clang-600.0.56) (based
>> on
>> LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at
>> /usr/bin/clang)
>> * C++ Compiler:   Version Apple LLVM version 6.0 (clang-600.0.56) (based
>> on
>> LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at
>> /usr/bin/clang++)
>>
>> Build performance summary:
>> * Cores to use:   4
>> * Memory limit:   16384 MB
>>
>> Cheers,
>> Martijn
>>
>
>

Build error with javac Main not being found when building java.transaction module on Mac OS X

[Martijn Verburg]

Hi all,

Apologies if this has already been reported before!

Build from HEAD (jdk9) today I get the following error running make clean
images:

make clean images
Cleaning hotspot build artifacts ... done
Cleaning jdk build artifacts ... done
Cleaning bootcycle-build build artifacts ... done
Cleaning test build artifacts ... done
Cleaning buildtools build artifacts ... done
Cleaning support build artifacts ... done
Cleaning images build artifacts ... done
Cleaning make-support build artifacts ... done
Cleaned all build artifacts.
Building OpenJDK for target 'clean images' in configuration
'macosx-x86_64-normal-server-release'

Compiling 5 files for BUILD_GENMODULESLIST
Compiling 8 files for BUILD_TOOLS_LANGTOOLS
Compiling 3 files for java.transaction
Error: Could not find or load main class com.sun.tools.javac.Main
make[3]: ***
[/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/build/macosx-x86_64-normal-server-release/jdk/modules/java.transaction/_the.java.transaction_batch]
Error 1
make[2]: *** [java.transaction-java] Error 2
make[2]: *** Waiting for unfinished jobs



I have the following configuration and have also tried using JDK 9 b44 as
the boot JDK :


The existing configuration has been successfully updated in
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/build/macosx-x86_64-normal-server-release
using configure arguments
'--with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home/'.

Configuration summary:
* Debug level:release
* HS debug level: product
* JDK variant:normal
* JVM variants:   server
* OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64

Tools summary:
* Boot JDK:   java version "1.8.0_31" Java(TM) SE Runtime Environment
(build 1.8.0_31-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07,
mixed mode)  (at
/Library/Java/JavaVirtualMachines/jdk1.8.0_31.jdk/Contents/Home)
* Toolchain:  clang (clang/LLVM)
* C Compiler: Version Apple LLVM version 6.0 (clang-600.0.56) (based on
LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at
/usr/bin/clang)
* C++ Compiler:   Version Apple LLVM version 6.0 (clang-600.0.56) (based on
LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at
/usr/bin/clang++)

Build performance summary:
* Cores to use:   4
* Memory limit:   16384 MB

Cheers,
Martijn

Re: README-builds.html update

[Martijn Verburg]

Hi Magnus,

Thanks, in that case I'll submit a patch and see what people think, if it's
too big a change then I can always redo in pieces.  I'm personally OK with
HTML, pretty used to making it play nice, but have noting against Markdown
either.

Cheers,
Martijn

On 3 February 2015 at 13:50, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> On 2015-02-01 11:16, Martijn Verburg wrote:
>
>> Hi all,
>>
>> I'm sitting at FOSDEM and was reminded that we hadn't yet made the effort
>> to integrate the "How to build OpenJDK" material we've built up over on
>> adoptopendk.java.net (the incubator site for Adoption Group activities)
>> as
>> well as tidying up some typos and HTML compatibility warnings in the doc.
>>
>> Updating a reasonably large document will mean a diff of:
>>
>> * Whitespace changes
>> * HTML formatting changes
>> * Actual content changes
>>
>> Would people prefer a patch for each type of change? Or are they happy for
>> what will likely be a reasonably large diff, (which basically means
>> eyeballing the end result).
>>
>
> With a suitable diff tool, hiding/showing whitespace changes is no big
> deal, so since it is only a single file I don't see the need for a separate
> patch for that.
>
> If the formatting changes are much higher in number than actual content
> change, it might make sense to separate those. But just a few formatting
> changes among real content change is no problem.
>
> 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 to get it right. Does it sound like a good
> idea?
>
> /Magnus
>

README-builds.html update

[Martijn Verburg]

Hi all,

I'm sitting at FOSDEM and was reminded that we hadn't yet made the effort
to integrate the "How to build OpenJDK" material we've built up over on
adoptopendk.java.net (the incubator site for Adoption Group activities) as
well as tidying up some typos and HTML compatibility warnings in the doc.

Updating a reasonably large document will mean a diff of:

* Whitespace changes
* HTML formatting changes
* Actual content changes

Would people prefer a patch for each type of change? Or are they happy for
what will likely be a reasonably large diff, (which basically means
eyeballing the end result).

Cheers,
Martijn

Re: Official and community supported build platforms for JDK 8 and 9

[Martijn Verburg]

Thanks Magnus, appreciate it!

Cheers,
Martijn

On 2 December 2014 at 15:42, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> On 2014-12-02 14:43, Martijn Verburg wrote:
>
>> That's a no for now then - in that case - do folks just want us firing any
>> updates we are aware of to this mailing list?
>>
> Yes, please do.
>
> I am aware that I have a backlog of already mailed additions. I'll try to
> address them as soon as time permits. But a mail here is not wasted, even
> if I can't process it right away.
>
> I will also update the wiki page to state that mailing updates to this
> list is the suggested procedure. (I was not aware when creating the page
> that edit rights were limited to the build group.)
>
> /Magnus
>
>
>> Cheers,
>> Martijn
>>
>> On 1 December 2014 at 19:02, Iris Clark  wrote:
>>
>>  Hi, Martijn.
>>>
>>>  Likewise - is it possible to get edit access?
>>>>
>>> https://wiki.openjdk.java.net/display/Build/Supported+build+platforms
>>>
>>> That wikispace is owned by the Build Group, so all Members of that Group
>>> as listed in the Census [0] should be able to edit the page.
>>>
>>> Thanks,
>>> iris
>>>
>>> [0] http://openjdk.java.net/census#build
>>>
>>> -Original Message-
>>> From: Martijn Verburg [mailto:martijnverb...@gmail.com]
>>> Sent: Monday, December 01, 2014 7:24 AM
>>> To: Patrick Reinhart
>>> Cc: jdk8-dev; build-dev; jdk9-...@openjdk.java.net
>>> Subject: Re: Official and community supported build platforms for JDK 8
>>> and 9
>>>
>>> Likewise - is it possible to get edit access?
>>>
>>> Cheers,
>>> Martijn
>>>
>>>
>>>
>

Re: Official and community supported build platforms for JDK 8 and 9

[Martijn Verburg]

That's a no for now then - in that case - do folks just want us firing any
updates we are aware of to this mailing list?

Cheers,
Martijn

On 1 December 2014 at 19:02, Iris Clark  wrote:

> Hi, Martijn.
>
> > Likewise - is it possible to get edit access?
>
> https://wiki.openjdk.java.net/display/Build/Supported+build+platforms
>
> That wikispace is owned by the Build Group, so all Members of that Group
> as listed in the Census [0] should be able to edit the page.
>
> Thanks,
> iris
>
> [0] http://openjdk.java.net/census#build
>
> -Original Message-
> From: Martijn Verburg [mailto:martijnverb...@gmail.com]
> Sent: Monday, December 01, 2014 7:24 AM
> To: Patrick Reinhart
> Cc: jdk8-dev; build-dev; jdk9-...@openjdk.java.net
> Subject: Re: Official and community supported build platforms for JDK 8
> and 9
>
> Likewise - is it possible to get edit access?
>
> Cheers,
> Martijn
>
>

Re: Official and community supported build platforms for JDK 8 and 9

[Martijn Verburg]

Likewise - is it possible to get edit access?

Cheers,
Martijn

On 21 November 2014 at 20:46, Patrick Reinhart  wrote:

> Hi Magnus,
>
> > A recurring theme in the build-dev list is confusion on which platforms
> it is possible to build OpenJDK. Unfortunately, information about this has
> not been easy to gather. It has also not been clear what kind of build
> issues the Build Team will respond to and with what kind of urgency.
> >
> > To help address this, I’ve created a publicly available wiki page:
> https://wiki.openjdk.java.net/display/Build/Supported+build+platforms
>
> Nice work, that belongs on my shortcut list from now on.
>
> > Support for building on different platforms come in two varieties:
> official support and community support.
> >
> > Oracle defines a number of official build platforms, with carefully
> specified versions of operating systems, compilers and other build tools.
> If you report a failure to build on any of these platforms, the report will
> be processed with high priority from the build team in Oracle. Under normal
> circumstances, a build on any of these platforms will always succeed.
> >
> > In addition to the official build platforms, OpenJDK can normally be
> built on many more platforms. For these platforms, there is no guarantee
> that the build will succeed. The Oracle build team can help to solve some
> problems encountered, but only on a best-effort basis. In addition to the
> Oracle build team, the OpenJDK community at large is welcome to help with
> making OpenJDK compile on these platforms.
> >
> > The official and community supported build platforms are listed on the
> wiki page. Note that build support is different for different versions of
> the JDK. We welcome updates from the community to the list of community
> supported platforms. If you have succeeded (or not!) in building OpenJDK on
> a platform that is substantially different from the ones already listed,
> please document your experience in the list.
>
> I’m able to fluently build JDK 8u and JDK 9 on Fedora 21 x64
>
> > The list of community supported platforms on the wiki is currently much
> shorter than the number of platforms I expect OpenJDK to build on. Once
> again, please help us by filling in the wiki!
> >
> > /Magnus
>
> I would like to help improve also documentations for the community…
>
> Patrick

Re: Can not get codes by get_source.sh at Japanese environment.

[Martijn Verburg]

Hi Yuji,

Martijn here (we met at Hackergarden).  The OpeJDK mailing lists don't
accept attachments, are you able to copy the content of the patch (diff)
and post in the body of the message?

Cheers,
Martijn

On 1 October 2014 16:59, Yuji Kubota  wrote:

> Hi all,
> I wrote this report and patch at Hackergarten in JavaOne2014.
>
> When I try to get source codes of jdk8 in Japanese environment,
> get_source.sh can not parse the "hg -version" correctly.
> So I can not get the source codes, because the result of "hg -version"
> has japanese charcthers.
>
> Mercurial use *.po files for i18n, so I set required LANGUAGE before
> call hg commands.
> Please review attached patch! :)
>
> And thank hackergarten for many advices!
> ---
> KUBOTA Yuji
>

Re: Build failures on OS X 10.9.3

[Martijn Verburg]

Hi all,

FYI - I have a similar problem on Mac OS X 10.9.5 with the latest XCode 6 &
XQuartz 2.7.7.

Cheers,
Martijn

On 29 September 2014 04:16, Bernhard Urban  wrote:

> On Thu, Sep 25, 2014 at 1:15 AM, David DeHaven 
> wrote:
>
> >
> > >>> I suspect it'll be easier to just install gcc on your mac. The last
> > time I
> > >>> checked openjdk 8 didn't compile correctly with clang, so you might
> > also
> > >>> have to patch the source code as well as the autoconf scripts.
> > >> So Apple are now shipping a compiler by default, but it's clang, which
> > >> they've aliased to gcc, despite the fact that the binaries differ?
> > >>
> > >> So all the standard hacks from earlier OS versions where you test for
> > >> the presence of certain binaries to see whether devtools are installed
> > >> are now bust?
> > >>
> > >> Well, isn't that ... lovely?
> > >>
> > >> I'd be intruigued to know whether OpenJDK 9 will build with Clang, as
> > >> the autoconf seems happy with the behaviour of "gcc". I might install
> > >> the TrueType headers and see how far that gets.
> > > OpenJDK 9 is supposed to compile properly with clang on macosx.
> > Configure will auto-select clang if your Xcode version is >= N, for some
> > number of N (I suspect 5, but I'm not sure).
> >
> > Correct, Xcode >= 5 will select clang as the compiler.
> >
> > Does Freetype detection use pkg-config? I've never had an issue building
> > OpenJDK with MacPorts' Freetype installed.
> >
> > -DrD-
> >
>
> it looks like the configure script of OpenJDK 8 doesn't detect newer
> versions of freetype.  I had problems with xquartz 2.7.6 (that contains
> freetype 2.5.3), but xquartz 2.7.5 (containing freetype 2.5.0.1) it worked
> for me.
>
> From a quick look into the config.log it looks like that the directory
> organization of the header files changed, and the OpenJDK8 configure script
> is not aware of it.
>
> -Bernhard
>

Suggested changes for Build Group Page (add jdk9 and build-infra links)

[Martijn Verburg]

Hi all,

Was just looking at http://openjdk.java.net/groups/build/ and noticed that
there's no links for:

1.) jdk9 build docs -
http://hg.openjdk.java.net/jdk9/build/raw-file/tip/README-builds.html ?
2.) The build-infra-dev mailing list - (Is build-dev effectively
dead/dormant now?)

I think there were also some personnel reshuffling.

Cheers,
Martijn

Proposal to update build documentation

[Martijn Verburg]

Hi all,

The Adoption Group is about to embark on it's migration of all of its
documentation on building OpenJDK (adoptopenjdk.java.net contains a bunch
of pages). We found your group page at
http://openjdk.java.net/groups/build/and wiki at
https://wiki.openjdk.java.net/display/Build/Main and figured our
documentation should really fall under your gropup's banner (we can
reference it from the Adoption Group for new comers).

So our proposal is to:

1.) Compare the docs that we have vs what's contained in the various
README-builds.html files
2.) Send in patches to README-builds.html where appropriate
3.) Only document temporary workarounds / known issues etc in the Build
group's wiki

And the one I was more uncertain about:

* Document uncommon build scenarios Build group's wiki, e.g. What certain
unusual flags mean and so forth.

Does this sound reasonable?  I'm happy to walk through the existing
documentation set that we have with someone so you have a clear idea on
what we're proposing to bring across.

Cheers,
Martijn

Re: How to add options to the javac build in the JDK 8 repo?

[Martijn Verburg]

Wouldn't be an open source project without a hall of shame ;-).  For us
casual contributors the longer list is actually helpful as it gives us
places to go and focus, the problems.txt test exclusions also fit in this
category.

Cheers,
Martijn


On 6 September 2013 08:18, Magnus Ihse Bursie  wrote:

> On 2013-09-05 19:53, Joe Darcy wrote:
>
>> Once the "foo" category of warnings are resolved, I think it is a bit
>> clearer to add "foo," to the list of enabled lint warnings rather than to
>> remove "-foo,".
>>
>> However, I'm less concerned with how the various Xlint checks are enabled
>> compared to getting them enabled.
>>
>
> And I think a long list of disabled warnings look like a "hall of shame",
> which explicitely states what we currently suck at. :-) But whatever. If
> you think this is clearer, I won't argue. As you say, the important thing
> is to fix the code and enable the checks.
>
> /Magnus
>

Re: PING: [PATCH] Enable debug info on all libraries for OpenJDK builds

[Martijn Verburg]

Hi all,

We're looking to help alleviate these sorts of issues with the Betterrev
project.  Basically patches will get build against common platforms/forests
and results sent back to the submitter and the appropriate OpenJDK mailing
list.

We still have some way to go, but early work is looking promising. If
anyone has spare cycles and a passion for build and CI, please drop me a
note!

Cheers,
Martijn


On 11 April 2013 03:59, David Holmes  wrote:

> Andrew,
>
> My sincerest apologies. As long as pushes are to jdk8/build then there is
> indeed scope for deferring broad testing until after the push - any
> failures will only affect users of the jdk8/build and a fix will likely
> swiftly occur. In any case that is for the build folk to concern themselves
> with.
>
> Having been burnt by some recent build issues in other repos I overlooked
> the key factor as to which repo is involved.
>
> Again my apologies.
>
> David
>
>
> On 11/04/2013 12:30 PM, David Holmes wrote:
>
>> Hi Andrew,
>>
>> We live/work in an imperfect world. The shortcomings you outline below
>> are well known and steps are being taken to address at least some of
>> them. That has taken time and will continue to take time - there is
>> nothing I can do about that - sorry. I too would love to see an
>> automatic submission system (like JPRT) that is accessible to all so
>> that I don't have to ever worry about build failures getting through.
>>
>> In the meantime I don't think my request to work with others to ensure
>> broader test coverage of build changes is unreasonable.
>>
>> I can't force anyone's cooperation I can only request it.
>>
>> Thanks,
>> David
>>
>> On 10/04/2013 11:35 PM, Andrew Hughes wrote:
>>
>>> - Original Message -
>>>
 On 9/04/2013 11:06 AM, Martin Buchholz wrote:

> On Mon, Apr 8, 2013 at 5:51 PM, David Holmes  > wrote:
>
>  On 9/04/2013 2:59 AM, Andrew Hughes wrote:
>
>  Well, if I push it, it will be, no?
>
>  Testing comes before pushing - thank you.
>

>>> And I have built and tested it.  You are trying to impose additional
>>> requirements
>>> for building on platforms we don't use.  This simply does not scale.
>>> You can't
>>> expect every OpenJDK committer to build on four operating systems and
>>> however
>>> many architectures (potentially any in existence, given the presence
>>> of Zero).
>>>
>>> If I'm a little unforgiving here, it's because I don't see the same
>>> thought being
>>> applied in the other direction.  This is not a patch to add a new
>>> feature, but
>>> to fix a build regression introduced by Oracle engineers (and one of
>>> many we've
>>> found).  I wouldn't even have to submit this if debugging had not been
>>> completely
>>> broken in our builds with little clear explanation as to why.
>>>
>>>
>
> This issue keeps coming up.
>
> Non-Oracle committers have no access to the Oracle automated testing
> submission system, so I suggest giving developers some slack when
> submitting (as I did when I was TL integrator). Or provide some other
> simple mechanism for handing off risky patches to the integration
> pipeline.  Or provide some easy way to roll back breaking changes.
>

>>> +1.
>>>
>>>
 If you are submitting a build patch that affects multiple platforms and
 you can not test on all the platforms yourself then you should work with
 someone who can assist in ensuring sufficient testing is carried out. I
 don't think that is at all unreasonable.

>>>
>>> The problem here is not the concept in general, but that both "someone"
>>> and "sufficient testing" are defined relative to Oracle.  Could I work
>>> with someone at Red Hat, Google or IBM to carry out "sufficient testing"?
>>> It seems doubtful to me, and that's without even considering
>>> contributions
>>> from those not working for a company.
>>>
>>> As far as I can see, "sufficient testing", from an Oracle perspective,
>>> would include
>>> testing on e.g. Solaris/SPARC, which is mainly of relevance to them, but
>>> not testing on Linux/SPARC (which Debian & Fedora build) or AIX/PPC
>>> (which
>>> IBM are working on).
>>>
>>> I agree build testing is important, and no-one wants to find the build
>>> broken
>>> (I've hit it enough times as the result of work from Oracle
>>> engineers), but such
>>> a restriction can't be imposed unless resources are available to
>>> support it.
>>> Pushing a patch and having automated build systems test it on all the
>>> various
>>> setups is a lot more scalable than waiting for someone else to apply
>>> and build it
>>> locally.  It's not like anyone's going to release binaries if OpenJDK
>>> is not buildable,
>>> is it?
>>>
>>> This issue is important not for people like me who have to work on
>>> OpenJDK anyway, no
>>> matter how much pain and aggravation it is, but in terms of the
>>> "onboarding" of new
>>> developers.  These sort o

Re: New build system problems

[Martijn Verburg]

Hey All,

As an aside to this - we're looking to build a distributed build farm that
will enable folks to test changes on at least the common platforms.  If you
want to help out (especially if you have Build/Jenkins/CI/Git/Mercurial
expertise) then please drop me a note off-list.

Cheers,
Martijn


On 6 March 2013 01:00, David Holmes  wrote:

> On 6/03/2013 10:52 AM, Martin Buchholz wrote:
>
>> 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
>> difference is the notion of "right". I maintain that for a change to
>> the build instructions of a given platform, then a test build on
>> that platform is the absolute minimum upfront testing that must be
>> done.
>>
>>
>> The responsibility is on the submitter to be "responsible".  But there's
>> a limit to the certainty of correctness you can expect from the
>> submitter.  The integration process (including gatekeepers) needs to
>> help out as well.
>> If:
>> - erroneous commits only cause lost work for the submitter and the
>> gatekeeper
>> - erroneous commits can be trivially rolled back
>> - testing is highly automated
>> then we can have a more productive and pleasant developer experience for
>> everyone.
>>
>
> None of these premises hold with the current system. You can lament or
> debate that all you like but the facts remain. So in the current system it
> is not acceptable, in my opinion, to push a change that includes build
> instructions for platform X without a build of platform X having been
> tested. So if a submitter can't do that test themselves then they need to
> collaborate with someone who can.
>
> David
>
>
>

Re: Does anyone have an Xcode project to build Hotspot?

[Martijn Verburg]

Closest thing we have is an Eclipse project I'm afraid.
Cheers,
Martijn


On 8 February 2013 17:48, Gerard Ziemski  wrote:
> hi guys,
>
> I hope this is the right place to ask this question, if not please suggest
> where else I could ask it.
>
> Does anyone here have an Xcode project to build Hotspot?
>
> For reference, I have filed https://jbs.oracle.com/bugs/browse/JDK-8007737
> to track this issue.
>
>
> cheers

Re: problem building OpenJDK on Windows 7 in langtools

[Martijn Verburg]

I'm on my phone so can't check this specific case but we do have slightly
more up to date instructions on the adoptopenjdk.java.net wiki for windows
builds, so perhaps you can try there.

Cheers,
Martijn

PS: Yes these instructions are coming back to OpenJDK working on that with
Dalibor soon

On Monday, 4 February 2013, Randy Nielsen wrote:

> I'm trying to build 64 bit java 7 on 64 bit Windows 7 with Cygwin, using
> instructions from
> http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html
>
> I built environment variables in Windows then simply typed "make".  I get
> pass the sanity make sanity but choke fairly early in the langtools make.
> Full console output is at the end of the post.  Here are the failure lines:
>
>
> -def-pcompile:
> [javac] Compiling 2 source files to
> C:\OpenJDK\jdk7-source\openjdk\build\windows-amd64\langtools\build\toolclasses
>
> BUILD FAILED
> C:\OpenJDK\jdk7-source\openjdk\langtools\make\build.xml:860: Error running
> \cygdrive\c\OpenJDK\jdk-6u37\bin\javac compiler
>
> Total time: 0 seconds
> make[2]: *** [build] Error 1
> make[2]: Leaving directory
> `/cygdrive/c/OpenJDK/jdk7-source/openjdk/langtools/make'
> make[1]: *** [langtools-build] Error 2
> make[1]: Leaving directory `/cygdrive/c/OpenJDK/jdk7-source/openjdk'
> make: *** [build_product_image] Error 2
>
>
> I'm puzzled because the failure message appears to show that the build is
> trying to run javac with "\" separators instead of "/":
> \cygdrive\c\OpenJDK\jdk-6u37\bin\javac
>
> Invoking /cygdrive/c/OpenJDK/jdk-6u37/bin/javac works, producing the usual
> usage lines.
>
> On the surface the problem is \ vs. / but how can that be since
> ALT_BOOTDIR=/cygdrive/c/OpenJDK/jdk-6u37?  So I could dig deeper I assumed
> that
> the problem was something else but can find no log file showing the
> parameters that javac was called with.
>
> Can anyone help?
>
> Thanks,
>
> Randy
>
> HERE IS THE FULL CYGWIN CONSOLE OUTPUT:
>
> Administrator@WIN-R7HSHTAIIHC ~
> $ cd /cygdrive/c/OpenJDK/jdk7-source/openjdk
>
> Administrator@WIN-R7HSHTAIIHC /cygdrive/c/OpenJDK/jdk7-source/openjdk
> $ make
> cygwin warning:
>   MS-DOS style path detected: C:/PROGRA~2/MI4ADD~1
>   Preferred POSIX equivalent is: /cygdrive/c/PROGRA~2/MI4ADD~1
>   CYGWIN environment variable option "nodosfilewarning" turns off this
> warning.
>   Consult the user's guide for more details about POSIX paths:
> http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
> ( cd  ./jdk/make && \
>   make sanity HOTSPOT_IMPORT_CHECK=false
> JDK_TOPDIR=C:/OpenJDK/JDK7-S~1/openjdk/jdk
> JDK_MAKE_SHARED_DIR=C:/OpenJDK/JDK7-S~1/openjdk/jdk/make/common/shared
> EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7
> MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00
> FULL_VERSION=1.7.0-internal-administrator_2013_02_03_23_27-b00
> PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7
> JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0
> PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0
> ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0
> ANT_HOME="/cygdrive/c/OpenJDK/apache-ant-1.8.4"
> ALT_OUTPUTDIR=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64
> ALT_LANGTOOLS_DIST=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/langtools/dist
> ALT_CORBA_DIST=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/corba/dist
> ALT_JAXP_DIST=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/jaxp/dist
> ALT_JAXWS_DIST=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/jaxws/dist
> ALT_HOTSPOT_IMPORT_PATH=C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import
> BUILD_HOTSPOT=true ; )
> make[1]: Entering directory
> `/cygdrive/c/OpenJDK/jdk7-source/openjdk/jdk/make'
> make[1]: Leaving directory
> `/cygdrive/c/OpenJDK/jdk7-source/openjdk/jdk/make'
>
> Build Machine Information:
>build machine = WIN-R7HSHTAIIHC
>
> Build Directory Structure:
>CWD = /cygdrive/c/OpenJDK/jdk7-source/openjdk
>TOPDIR = .
>LANGTOOLS_TOPDIR = ./langtools
>JAXP_TOPDIR = ./jaxp
>JAXWS_TOPDIR = ./jaxws
>CORBA_TOPDIR = ./corba
>HOTSPOT_TOPDIR = ./hotspot
>JDK_TOPDIR = ./jdk
>
> Build Directives:
>BUILD_LANGTOOLS = true
>BUILD_JAXP = true
>BUILD_JAXWS = true
>BUILD_CORBA = true
>BUILD_HOTSPOT = true
>BUILD_JDK= true
>DEBUG_CLASSFILES =
>DEBUG_BINARIES =
>
> Hotspot Settings:
>   HOTSPOT_BUILD_JOBS  =
>   HOTSPOT_OUTPUTDIR   =
> C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/outputdir
>   HOTSPOT_EXPORT_PATH =
> C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64/hotspot/import
>
>
>
>
> Bootstrap Settings:
>   BOOTDIR = /cygdrive/c/OpenJDK/jdk-6u37
> ALT_BOOTDIR = /cygdrive/c/OpenJDK/jdk-6u37
>   BOOT_VER = 1.6.0 [requires at least 1.6]
>   OUTPUTDIR = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64
> ALT_OUTPUTDIR = C:/OpenJDK/jdk7-source/openjdk/build/windows-amd64
>   ABS_OUTPUTDIR = C:/OpenJDK/jdk7-source/openjdk/build/w

Re: Jdk8 Build Failures in Solaris

[Martijn Verburg]

Hi Dan,

I can't help with the first two, but the 3rd item you can simply run:

bash ../autoconf/configure

Assuming bash is installed etc

Cheers,
Martijn

On 20 November 2012 06:48, Dan Xu  wrote:

> Hi,
>
> Today I tried to build jdk8 in Solaris, but I got several different errors.
>
> 1) The first error message I got is "make: Fatal error in reader:
> Makefile, line 30: Unexpected end of line seen".
> I tried to change my shell from C shell to Bash. And it seems that I
> solved it in one of my Solaris environment. But it still exists in another
> Solaris machine.
>
> 2) Build failed with the error "CC not found". But actually, "make sanity"
> command passed.
>
> /bin/sh: CC: not found
> WARNING: You are using CC version and should be using version 5.10.
> Set ENFORCE_COMPILER_REV= to avoid this warning.
> WARNING: You are using cc version and should be using version 5.10.
> Set ENFORCE_CC_COMPILER_REV= to avoid this warning.
> make[6]: Entering directory `/home/danxu/Java/jdk8tl/**
> build/solaris-sparc/hotspot/**outputdir/solaris_sparc_**compiler2/product'
> Compiling /home/danxu/Java/jdk8tl/**hotspot/src/share/vm/adlc/**
> adlparse.cpp
> rm -f ../generated/adfiles/adlparse.**o
> CC -DSOLARIS -DSPARC_WORKS -DSPARC 
> -I/home/danxu/Java/jdk8tl/**hotspot/src/share/vm/prims
> -I/home/danxu/Java/jdk8tl/**hotspot/src/share/vm
> -I/home/danxu/Java/jdk8tl/**hotspot/src/share/vm/**precompiled
> -I/home/danxu/Java/jdk8tl/**hotspot/src/cpu/sparc/vm
> -I/home/danxu/Java/jdk8tl/**hotspot/src/os_cpu/solaris_**sparc/vm
> -I/home/danxu/Java/jdk8tl/**hotspot/src/os/solaris/vm
> -I/home/danxu/Java/jdk8tl/**hotspot/src/os/posix/vm
> -I/home/danxu/Java/jdk8tl/**hotspot/src/share/vm/adlc -I../generated
> -DASSERT -DTARGET_OS_FAMILY_solaris -DTARGET_ARCH_sparc
> -DTARGET_ARCH_MODEL_sparc -DTARGET_OS_ARCH_solaris_sparc
> -DTARGET_OS_ARCH_MODEL_**solaris_sparc -DTARGET_COMPILER_sparcWorks
> -DCOMPILER2 -DCOMPILER1 -DDONT_USE_PRECOMPILED_HEADER -D_REENTRANT
> -library=Cstd -g -xwe -g -c -o ../generated/adfiles/adlparse.**o
> /home/danxu/Java/jdk8tl/**hotspot/src/share/vm/adlc/**adlparse.cpp
> make[6]: CC: Command not found
> make[6]: *** [../generated/adfiles/**adlparse.o] Error 127
>
> 3) I also tried to run the new build.But I got the following error message
> after "sh ../autoconf/configure" command.
> This script needs bash to run.
> It is recommended to use the configure script in the source tree root
> instead.
>
> Can anyone help my build
>
>

Re: Building OpenJDK projects and JTReg in Eclipse

[Martijn Verburg]

Hi all,

CCing in build-infra and Jon on behalf of code-tools who I think will
be interested. In particular we're using build-infra now for the
AdoptOpenJDK build instructions.

Next step is to verify this early work and automate it with some
Vagrant/Puppet magic.

Cheers,
Martijn

On 18 September 2012 22:53, Mani Sarkar  wrote:
> Hi,
>
> I have recently posted a couple of blogs on How to Build OpenJDK projects
> and JTReg in Eclipse and have received good feedback on the content. But I
> would still like it to be reviewed by groups that work in this area
> regularly to give expert opinion and advise on it.
>
> Please have a look at the posts at and let me know if any of these are
> incorrect and should be approached differently:
> http://neomatrix369.wordpress.com/
>
> They were written the Adopt OpenJDK wikipage in mind so you will also find
> them here:
>
> http://java.net/projects/adoptopenjdk/pages/AdoptOpenJDKBuildInstructions#Install_IDE_Support
>
> http://java.net/projects/adoptopenjdk/pages/InstallJtreg#How_to_build_JTReg_in_Eclipse_(for_Ubuntu_12.04_LTS)
>
> Your feedback will help enrich these sets of information. If you think I
> should pass on this email to other groups that work on other sub-sets of
> the OpenJDK projects please do let me know (their emails as well).
>
> Thanks.
> Mani

Re: webrev failure?

[Martijn Verburg]

Yep, had that done already, I'll link to your blog post for the Adopt
OpenJDK build - Thanks! Martijn

On 3 September 2012 12:18, Dalibor Topic  wrote:
> On 8/12/12 1:39 PM, Martijn Verburg wrote:
>> Hi David,
>>
>> Aha! :-).  Any ideas on how far I need to downgrade the version of hg?
>> (I'm 2.3 at the moment).
>
> 2.2.3 works fine for me. See http://robilad.livejournal.com/125607.html
> for how to do it on MacPorts, assuming you've had it installed from
> MacPorts and working before.
>
> cheers,
> dalibor topic
>
> --
> Oracle <http://www.oracle.com>
> Dalibor Topic | Principal Product Manager
> Phone: +494089091214  | Mobile: +491737185961 
> 
> Oracle Java Platform Group
>
> ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg
>
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 München
> Registergericht: Amtsgericht München, HRA 95603
> Geschäftsführer: Jürgen Kunz
>
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
>
> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
> developing practices and products that help protect the environment

Re: webrev failure?

[Martijn Verburg]

Hi Mark,

> On Sun, Aug 12, 2012 at 12:39:57PM +0100, Martijn Verburg wrote:
>> Aha! :-).  Any ideas on how far I need to downgrade the version of hg?
>> (I'm 2.3 at the moment).
>
> I am at 2.2.3. The hgforest extension as maintained at
> http://icedtea.classpath.org/hg/hgforest
> (which is a merge of various hgforest forks)
> works with that. It is also the version that is installed on
> the icedtea server itself to host forests.
>
> If there are patches needed for 2.3 we can incorporate those too.

I gave the version hosted at http://icedtea.classpath.org/hg/hgforest
a go and got the same error when using:

ksh ./make/scripts/webrev.ksh -f

but

ksh ./make/scripts/webrev.ksh -N

came up with a sensible answer for the multiple repo case.  So perhaps
some patching is required, but that's were my knowledge sadly ends
:-(.

Thanks everyone for your help with this!

Cheers,
Martijn

Re: webrev failure?

[Martijn Verburg]

Hi Chris,

> Martin,
>
> Unless you have changes that span multiple repositories, then it can be
> quite straight forward to run webrev ( without '-f ) on just the individual
> repository that you are changing. It will run with simply 'hg out'.

That did seem to work, thanks.

> If you have changes in multiple repo's then you have other choices:
>  1) run webrev on each individually, and include all the links in the
> review mail
>  2) create a 'file.list' ( a file containing your changed files, one
> file name per line ), and pass it as the final arg to webrev
>  3) Run with a really really old hg ( I use 0.9.5 ) and an installed
> forest extension. Now, 'webrev -f' should work just fine ;-)

We could go with 1) or 2) - I'll work that into our process.

Cheers,
Martijn

> On 11/08/12 17:04, Martijn Verburg wrote:
>>
>> Hi all,
>>
>> Apologies if these are the wrong mailing lists, but I'm assuming that
>> the webrev tool falls under this domain somewhat.
>>
>> In order to get patches into the OpenJDK as cleanly as possible, we're
>> looking to utilise webrev (since it's the std and all).
>>
>> Running "ksh ./make/scripts/webrev.ksh -f" over the latest jdk8/tl
>> source (no patches, but a full build was completed using build-infra)
>> and I got a host of errors:
>>
>> 
>>
>> SCM detected: mercurial
>> hg: unknown command 'foutgoing'
>> abort: cannot follow file not in parent revision: "Mercurial"
>> abort: cannot follow file not in parent revision: "basic"
>> abort: cannot follow file not in parent revision: "add"
>> abort: cannot follow file not in parent revision: "annotate"
>> ..
>> ..
>>
>> 
>>
>> A separate, yet related set of errors are at
>> http://pastebin.com/q0tF1A4m for sake of brevity in this mail.
>>
>> I assume I'm running this tool incorrectly, I expected a result of
>> something like "You've changed nothing, nothing to se here move along
>> please" :-)
>>
>> Cheers,
>> Martijn
>>
>

Re: webrev failure?

[Martijn Verburg]

Hi David,

Aha! :-).  Any ideas on how far I need to downgrade the version of hg?
(I'm 2.3 at the moment).

Cheers,
Martijn

On 12 August 2012 12:29, David Holmes  wrote:
> I had thought that webrev only tried to operate on a forest if you asked it
> to - and that that requires the forest extension.
>
> That said the forest extension is not working with recent mercurial
> versions. :(
>
> David
>
>
> On 12/08/2012 2:04 AM, Martijn Verburg wrote:
>>
>> Hi all,
>>
>> Apologies if these are the wrong mailing lists, but I'm assuming that
>> the webrev tool falls under this domain somewhat.
>>
>> In order to get patches into the OpenJDK as cleanly as possible, we're
>> looking to utilise webrev (since it's the std and all).
>>
>> Running "ksh ./make/scripts/webrev.ksh -f" over the latest jdk8/tl
>> source (no patches, but a full build was completed using build-infra)
>> and I got a host of errors:
>>
>> 
>>
>> SCM detected: mercurial
>> hg: unknown command 'foutgoing'
>> abort: cannot follow file not in parent revision: "Mercurial"
>> abort: cannot follow file not in parent revision: "basic"
>> abort: cannot follow file not in parent revision: "add"
>> abort: cannot follow file not in parent revision: "annotate"
>> ..
>> ..
>>
>> 
>>
>> A separate, yet related set of errors are at
>> http://pastebin.com/q0tF1A4m for sake of brevity in this mail.
>>
>> I assume I'm running this tool incorrectly, I expected a result of
>> something like "You've changed nothing, nothing to se here move along
>> please" :-)
>>
>> Cheers,
>> Martijn

Re: webrev failure?

[Martijn Verburg]

Hi Dmitry,

It reports Mercurial Distributed SCM (version 2.3)

Cheers,
Martijn

On 12 August 2012 12:14, Dmitry Samersoff  wrote:
> Martijn,
>
> What version of HG do you use?
>
> hg --version
>
>
> Can't help much with mac os, but the problem is somewhere in
> python/hg/forest ...
>
> -Dmitry
>
> On 2012-08-12 15:09, Martijn Verburg wrote:
>> Hi Dmitry,
>>
>> I put your version of forest.py into my /Users/karianna/.hgext/
>> directory and I've altered my .hgrc file is as follows:
>>
>> ui.username=karianna
>> [extensions]
>> forest=/Users/karianna/.hgext/forest.py
>> [format]
>> usefncache=no
>>
>> Unfortunately I still get the same error. I am running on Mac OS X
>> (10.7.2) but I don't think that should make a difference...
>>
>> Cheers,
>> Martijn
>>
>>> Martijn,
>>>
>>> First step - you need to make
>>> hg st
>>> in your workspace working without extra warning
>>>
>>> It looks like something still wrong with your forest extension.
>>>
>>> I attached working one and below is two relevant lines from
>>> my ~/.hgrc
>>>
>>> [extensions]
>>> forest=/home/dms/.hgext/forest.py
>>>
>>> [format]
>>> usefncache=no
>>>
>>> -Dmitry
>>>
>>>
>>> On 2012-08-12 14:16, Martijn Verburg wrote:
>>>> Hi Dmitry,
>>>>
>>>> Thanks for the hints! After following the forest extension install
>>>> instructions at
>>>> http://hg.openjdk.java.net/jdk7u/jdk7u4/raw-file/tip/README-builds.html#hg
>>>> and running "ksh ./make/scripts/webrev.ksh -N" I get:
>>>>
>>>> *** failed to import extension forest from forest_extension/forest.py:
>>>> No module named repo
>>>>SCM detected: mercurial
>>>> *** failed to import extension forest from forest_extension/forest.py:
>>>> No module named repo
>>>> *** failed to import extension forest from forest_extension/forest.py:
>>>> No module named repo
>>>> *** failed to import extension forest from forest_extension/forest.py:
>>>> No module named repo
>>>>
>>>>  No outgoing, perhaps you haven't commited.
>>>> *** failed to import extension forest from forest_extension/forest.py:
>>>> No module named repo
>>>> *** failed to import extension forest from forest_extension/forest.py:
>>>> No module named repo
>>>> *** failed to import extension forest from forest_extension/forest.py:
>>>> No module named repo
>>>>   Workspace: /Users/karianna/Documents/workspace/jdk8_tl
>>>>   Output to: /Users/karianna/Documents/workspace/jdk8_tl/webrev
>>>>Output Files:
>>>>   common/autoconf/configure
>>>>patch cdiffs udiffs sdiffs frames old new
>>>>   get_source.sh
>>>>    patch cdiffs udiffs sdiffs frames old new
>>>>  index.html: Done.
>>>> Output to: /Users/karianna/Documents/workspace/jdk8_tl/webrev
>>>>
>>>> So I'm a bit unsure about the "*** failed" messages but the "No
>>>> outgoing, perhaps you haven't commited." makes complete sense.
>>>>
>>>> Do I need to alter forest.py in order to get the list of modules correct?
>>>>
>>>> Cheers,
>>>> Martijn
>>>>
>>>>
>>>> On 11 August 2012 19:52, Dmitry Samersoff  
>>>> wrote:
>>>>> Martin,
>>>>>
>>>>> 1. Make sure you have a forest extension
>>>>> 2. Try webrev -N to create webrev against your current workspace rather
>>>>>than against remote repository
>>>>>
>>>>> -Dmitry
>>>>>
>>>>> On 2012-08-11 20:04, Martijn Verburg wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Apologies if these are the wrong mailing lists, but I'm assuming that
>>>>>> the webrev tool falls under this domain somewhat.
>>>>>>
>>>>>> In order to get patches into the OpenJDK as cleanly as possible, we're
>>>>>> looking to utilise webrev (since it's the std and all).
>>>>>>
>>>>>> Running "ksh ./make/scripts/webrev.ksh -f" over the latest jdk8/tl
>>>>>> source (no patches, but a full build was completed using build-infra)
>>>>>> and I got a host of errors:
>>>>>>
>>>>>> 
>>>>>>
>>>>>>SCM detected: mercurial
>>>>>> hg: unknown command 'foutgoing'
>>>>>> abort: cannot follow file not in parent revision: "Mercurial"
>>>>>> abort: cannot follow file not in parent revision: "basic"
>>>>>> abort: cannot follow file not in parent revision: "add"
>>>>>> abort: cannot follow file not in parent revision: "annotate"
>>>>>> ..
>>>>>> ..
>>>>>>
>>>>>> 
>>>>>>
>>>>>> A separate, yet related set of errors are at
>>>>>> http://pastebin.com/q0tF1A4m for sake of brevity in this mail.
>>>>>>
>>>>>> I assume I'm running this tool incorrectly, I expected a result of
>>>>>> something like "You've changed nothing, nothing to se here move along
>>>>>> please" :-)
>>>>>>
>>>>>> Cheers,
>>>>>> Martijn
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Dmitry Samersoff
>>>>> Java Hotspot development team, SPB04
>>>>> * There will come soft rains ...
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Dmitry Samersoff
>>> Java Hotspot development team, SPB04
>>> * There will come soft rains ...
>>>
>>>
>
>
> --
> Dmitry Samersoff
> Java Hotspot development team, SPB04
> * There will come soft rains ...
>
>

Re: webrev failure?

[Martijn Verburg]

Hi Dmitry,

I put your version of forest.py into my /Users/karianna/.hgext/
directory and I've altered my .hgrc file is as follows:

ui.username=karianna
[extensions]
forest=/Users/karianna/.hgext/forest.py
[format]
usefncache=no

Unfortunately I still get the same error. I am running on Mac OS X
(10.7.2) but I don't think that should make a difference...

Cheers,
Martijn

> Martijn,
>
> First step - you need to make
> hg st
> in your workspace working without extra warning
>
> It looks like something still wrong with your forest extension.
>
> I attached working one and below is two relevant lines from
> my ~/.hgrc
>
> [extensions]
> forest=/home/dms/.hgext/forest.py
>
> [format]
> usefncache=no
>
> -Dmitry
>
>
> On 2012-08-12 14:16, Martijn Verburg wrote:
>> Hi Dmitry,
>>
>> Thanks for the hints! After following the forest extension install
>> instructions at
>> http://hg.openjdk.java.net/jdk7u/jdk7u4/raw-file/tip/README-builds.html#hg
>> and running "ksh ./make/scripts/webrev.ksh -N" I get:
>>
>> *** failed to import extension forest from forest_extension/forest.py:
>> No module named repo
>>SCM detected: mercurial
>> *** failed to import extension forest from forest_extension/forest.py:
>> No module named repo
>> *** failed to import extension forest from forest_extension/forest.py:
>> No module named repo
>> *** failed to import extension forest from forest_extension/forest.py:
>> No module named repo
>>
>>  No outgoing, perhaps you haven't commited.
>> *** failed to import extension forest from forest_extension/forest.py:
>> No module named repo
>> *** failed to import extension forest from forest_extension/forest.py:
>> No module named repo
>> *** failed to import extension forest from forest_extension/forest.py:
>> No module named repo
>>   Workspace: /Users/karianna/Documents/workspace/jdk8_tl
>>   Output to: /Users/karianna/Documents/workspace/jdk8_tl/webrev
>>Output Files:
>>   common/autoconf/configure
>>patch cdiffs udiffs sdiffs frames old new
>>   get_source.sh
>>patch cdiffs udiffs sdiffs frames old new
>>  index.html: Done.
>> Output to: /Users/karianna/Documents/workspace/jdk8_tl/webrev
>>
>> So I'm a bit unsure about the "*** failed" messages but the "No
>> outgoing, perhaps you haven't commited." makes complete sense.
>>
>> Do I need to alter forest.py in order to get the list of modules correct?
>>
>> Cheers,
>> Martijn
>>
>>
>> On 11 August 2012 19:52, Dmitry Samersoff  
>> wrote:
>>> Martin,
>>>
>>> 1. Make sure you have a forest extension
>>> 2. Try webrev -N to create webrev against your current workspace rather
>>>than against remote repository
>>>
>>> -Dmitry
>>>
>>> On 2012-08-11 20:04, Martijn Verburg wrote:
>>>> Hi all,
>>>>
>>>> Apologies if these are the wrong mailing lists, but I'm assuming that
>>>> the webrev tool falls under this domain somewhat.
>>>>
>>>> In order to get patches into the OpenJDK as cleanly as possible, we're
>>>> looking to utilise webrev (since it's the std and all).
>>>>
>>>> Running "ksh ./make/scripts/webrev.ksh -f" over the latest jdk8/tl
>>>> source (no patches, but a full build was completed using build-infra)
>>>> and I got a host of errors:
>>>>
>>>> 
>>>>
>>>>SCM detected: mercurial
>>>> hg: unknown command 'foutgoing'
>>>> abort: cannot follow file not in parent revision: "Mercurial"
>>>> abort: cannot follow file not in parent revision: "basic"
>>>> abort: cannot follow file not in parent revision: "add"
>>>> abort: cannot follow file not in parent revision: "annotate"
>>>> ..
>>>> ..
>>>>
>>>> 
>>>>
>>>> A separate, yet related set of errors are at
>>>> http://pastebin.com/q0tF1A4m for sake of brevity in this mail.
>>>>
>>>> I assume I'm running this tool incorrectly, I expected a result of
>>>> something like "You've changed nothing, nothing to se here move along
>>>> please" :-)
>>>>
>>>> Cheers,
>>>> Martijn
>>>>
>>>
>>>
>>> --
>>> Dmitry Samersoff
>>> Java Hotspot development team, SPB04
>>> * There will come soft rains ...
>>>
>>>
>
>
> --
> Dmitry Samersoff
> Java Hotspot development team, SPB04
> * There will come soft rains ...
>
>

Re: webrev failure?

[Martijn Verburg]

Hi Dmitry,

Thanks for the hints! After following the forest extension install
instructions at
http://hg.openjdk.java.net/jdk7u/jdk7u4/raw-file/tip/README-builds.html#hg
and running "ksh ./make/scripts/webrev.ksh -N" I get:

*** failed to import extension forest from forest_extension/forest.py:
No module named repo
   SCM detected: mercurial
*** failed to import extension forest from forest_extension/forest.py:
No module named repo
*** failed to import extension forest from forest_extension/forest.py:
No module named repo
*** failed to import extension forest from forest_extension/forest.py:
No module named repo

 No outgoing, perhaps you haven't commited.
*** failed to import extension forest from forest_extension/forest.py:
No module named repo
*** failed to import extension forest from forest_extension/forest.py:
No module named repo
*** failed to import extension forest from forest_extension/forest.py:
No module named repo
  Workspace: /Users/karianna/Documents/workspace/jdk8_tl
  Output to: /Users/karianna/Documents/workspace/jdk8_tl/webrev
   Output Files:
common/autoconf/configure
 patch cdiffs udiffs sdiffs frames old new
get_source.sh
 patch cdiffs udiffs sdiffs frames old new
 index.html: Done.
Output to: /Users/karianna/Documents/workspace/jdk8_tl/webrev

So I'm a bit unsure about the "*** failed" messages but the "No
outgoing, perhaps you haven't commited." makes complete sense.

Do I need to alter forest.py in order to get the list of modules correct?

Cheers,
Martijn


On 11 August 2012 19:52, Dmitry Samersoff  wrote:
> Martin,
>
> 1. Make sure you have a forest extension
> 2. Try webrev -N to create webrev against your current workspace rather
>than against remote repository
>
> -Dmitry
>
> On 2012-08-11 20:04, Martijn Verburg wrote:
>> Hi all,
>>
>> Apologies if these are the wrong mailing lists, but I'm assuming that
>> the webrev tool falls under this domain somewhat.
>>
>> In order to get patches into the OpenJDK as cleanly as possible, we're
>> looking to utilise webrev (since it's the std and all).
>>
>> Running "ksh ./make/scripts/webrev.ksh -f" over the latest jdk8/tl
>> source (no patches, but a full build was completed using build-infra)
>> and I got a host of errors:
>>
>> 
>>
>>SCM detected: mercurial
>> hg: unknown command 'foutgoing'
>> abort: cannot follow file not in parent revision: "Mercurial"
>> abort: cannot follow file not in parent revision: "basic"
>> abort: cannot follow file not in parent revision: "add"
>> abort: cannot follow file not in parent revision: "annotate"
>> ..
>> ..
>>
>> 
>>
>> A separate, yet related set of errors are at
>> http://pastebin.com/q0tF1A4m for sake of brevity in this mail.
>>
>> I assume I'm running this tool incorrectly, I expected a result of
>> something like "You've changed nothing, nothing to se here move along
>> please" :-)
>>
>> Cheers,
>> Martijn
>>
>
>
> --
> Dmitry Samersoff
> Java Hotspot development team, SPB04
> * There will come soft rains ...
>
>

webrev failure?

[Martijn Verburg]

Hi all,

Apologies if these are the wrong mailing lists, but I'm assuming that
the webrev tool falls under this domain somewhat.

In order to get patches into the OpenJDK as cleanly as possible, we're
looking to utilise webrev (since it's the std and all).

Running "ksh ./make/scripts/webrev.ksh -f" over the latest jdk8/tl
source (no patches, but a full build was completed using build-infra)
and I got a host of errors:



   SCM detected: mercurial
hg: unknown command 'foutgoing'
abort: cannot follow file not in parent revision: "Mercurial"
abort: cannot follow file not in parent revision: "basic"
abort: cannot follow file not in parent revision: "add"
abort: cannot follow file not in parent revision: "annotate"
..
..



A separate, yet related set of errors are at
http://pastebin.com/q0tF1A4m for sake of brevity in this mail.

I assume I'm running this tool incorrectly, I expected a result of
something like "You've changed nothing, nothing to se here move along
please" :-)

Cheers,
Martijn

Re: jdk8 makefile changes

[Martijn Verburg]

Hi all,

Forgot to send this in:

Ran on 10.7.2 OS X with latest Oracle JDK 7 binary as the
bootstrapper.  All ran fine, ../autoconf/configure did not have
execute permissions though, so had to chmod u+x it. Not sure if that's
a manual step you want people to take or not.

A couple of errors which didn't seem to stop anything was:

Generating source file: ComboBoxArrowButtonPainter.java
[Error] encoded value was less than 0: encode(-8.326673E-17, 5.0, 11.0, 16.0)

Generating source file: TabbedPaneTabAreaPainter.java
[Error] Encountered Infinity: encode(-0.00877193, 0.0, 7.0, 7.0)

There's a bunch of minor warnings as well, but a quick eyeball seemed
to indicate they were warnings under the new and older style builds,
we'll try to pick them off as part of the Adopt OpenJDK VM build.

Maxed out my 4 cores nicely, sounds like my MBP is about to take off
for Mars :-).

Cheers,
Martijn

On 9 July 2012 23:12, 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-build
>  sh ./get_source.sh
>  cd common/makefiles
>  ../autoconf/configure
>  make images
>
> Let us know what works, what doesn't.
>
> Many of us will be concentrating on binary comparisons over the next few days 
> to insure that we are building
> everything we did before, and the same content.
>
> -kto
>
> On Jul 3, 2012, at 11:38 AM, Kelly O'Hair wrote:
>
>>
>> Heads up...
>>
>> We expect to do a sync up of the jdk8/build forest with the latest in the 
>> build-infra forest in the next few days.
>>
>> As the new build-infra project starts getting more solid and we contemplate 
>> when we can switch
>> the default to building with the new build-infra Makefiles (we don't know 
>> exactly when yet).
>>
>> IMPORTANT NOTICE 
>> It will be important that *anyone* making *any* changes to the jdk8 
>> Makefiles keep the build-dev
>> or build-infra mailing lists informed.
>> For a period of time we need to maintain two separate build mechanisms, and 
>> we want to make sure
>> that both build the same thing.
>> The hotspot repository is the one exception where we don't have two sets of 
>> makefiles, but we still
>> would like to know when anyone is changing the makefiles or anything to do 
>> with the build process.
>>  *
>>
>> We will soon be running both builds and doing comparisons of the resulting 
>> j2sdk-image files from
>> both to insure we match. So if we detect differences we will be tracking 
>> down how those differences
>> happened (that's a hint that we will be watching :^).
>>
>> More information on the new build-infra Makefiles can be found at:
>>   http://openjdk.java.net/projects/build-infra/
>>
>> User Guide is at:
>>  http://openjdk.java.net/projects/build-infra/guide.html
>>
>> Some preliminary timings for building the product image (effectively, 
>> build/j2sdk-image/):
>>   OLD NEW 
>> build-infra times  (All estimates, similar VMs/Zones)
>> linux_i586(21m 59s)   (08m 13s)
>> linux_x64 (13m 34s)   (07m 04s)
>> solaris_i586  (26m 14s)   (11m 31s)
>> solaris_sparc (54m 02s)   (28m 21s)
>> windows_i586  (55m 49s)   (32m 22s)  (old used 
>> MKS, build-infra only uses CYGWIN)
>> windows_x64   (36m 36s)   (23m 50s)  "   
>>  " "
>>
>> Notes:
>>  * Machines with more processors will reduce the build time for build-infra 
>> builds, less so with the old Makefiles.
>>  * Always use local disk or /tmp (all above timings use /tmp, always local 
>> disk)
>>  * Above uses VMs for Windows and Linux, raw hardware would be faster
>>  * Use of ccache can sometimes speed things up, but can also skew the 
>> timings,
>>  in the above measurements OLD used ccache, NEW did not.
>>
>> -kto
>

Re: Build error on jdk8/tl project - Thread.o:(.data.rel+0xbc): undefined reference to JVM_SetNativeThreadName

[Martijn Verburg]

Hi all,

Well what do poor Weijun and Sean get for posting useful instructions
back in March?  They get me not reading them carefully enough! Partial
build now works as expected.

Thanks for your patience guys, I really need to RTM more closely in future!

Cheers,
Martijn

On 15 May 2012 15:33, Weijun Wang  wrote:
> This looks like the bug I mentioned. You should move the
> jdk8_tl/build/linux-amd64 directory to somewhere else.
>
> -Weijun
>
>
> On 05/15/2012 09:11 PM, Martijn Verburg wrote:
>>
>> Hi all,
>>
>>
>> Cheers,
>> Martijn
>>
>>> 
>>>
>>>> 
>>>>
>>>> The 2nd option would be the most up to date I guess but seems a bit
>>>> chicken and egg..
>>>
>>>
>>> I normally use the latest jdk8 binary, but as I said above, sometimes it
>>> still fails. In this case, do a full build and save the j2sdk-image
>>> directory somewhere as later ALT_IMPORT_JDK_PATH. There is no chicken and
>>> egg problem here, you use the full build output as IMPORT of a jdk-only
>>> build, and full build does not need an IMPORT at all, and either a full
>>> build or a jdk-only build depends on a previous veriosn of JDK as
>>> BOOTDIR.
>>>
>>> Please note there is a bug in our build script that if you already have
>>> tl/build/{platform} existing, a jdk/make build might fail (at some point
>>> in
>>> smartcard or security, random). Please rename (or move) the
>>> tl/build/{platform} directory before starting a jdk-only build.
>>
>>
>> I've been continuing the work to execute a full build followed by a
>> partial build. However, I think I'm still blocked by an> obvious missing env VAR>  issue.
>>
>> Full Build:
>> 
>> I set the following env vars
>>
>> export LANG=C
>> export ALT_BOOTDIR=/usr/lib/jvm/java-7-openjdk-amd64
>>
>> I execute a full build of the cloned code base from
>> http://hg.openjdk.java.net/jdk8/tl (after get_sources.sh is run) and
>> that all works fine
>>
>> Partial Build:
>> 
>>
>> # Create a backup of the full build (as per Weijun's recommendation)
>> cp -R /home/openjdk/projects/jdk8_tl/build/linux-amd64
>> /home/openjdk/projects/jdk8_tl/build/linux-amd64_backup
>>
>> # Set the ALT_JDK_IMPORT_PATH to point to the j2sk-image backup of the
>> full build
>> export
>> ALT_JDK_IMPORT_PATH=/home/openjdk/projects/jdk8_tl/build/linux-amd64_backup/j2sdk-image
>>
>> # Run the warnings build
>> make JAVAC_MAX_WARNINGS=true JAVAC_WARNINGS_FATAL=
>> OTHER_JAVACFLAGS="-Xmaxwarns 1"&>  build.log
>>
>> It builds up to a point, but then has the problem where it's looking
>> for due to directory structure issues (it's looking too far back up
>> the directory tree basically).
>>
>> 
>>
>> /bin/mkdir -p
>> ../../../../build/linux-amd64/tmp/sun/sun.security.ec/unsigned
>> rm -f
>> ../../../../build/linux-amd64/tmp/sun/sun.security.ec/unsigned/sunec.jar
>> /usr/lib/jvm/java-7-openjdk-amd64/bin/jar cf
>> ../../../../build/linux-amd64/tmp/sun/sun.security.ec/unsigned/sunec.jar
>>  -C ../../../../build/linux-amd64/tmp/sun/sun.security.ec/classes
>> sun/security/ec \
>>             -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions
>> -J-XX:-LogVMOutput -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m
>> -J-XX:MaxPermSize=160m
>>
>> ../../../../build/linux-amd64/tmp/sun/sun.security.ec/classes/sun/security/ec
>> : no such file or directory
>> make[3]: ***
>> [../../../../build/linux-amd64/tmp/sun/sun.security.ec/unsigned/sunec.jar]
>> Error 1
>> make[3]: Leaving directory
>> `/home/openjdk/projects/jdk8_tl/jdk/make/sun/security/ec'
>> make[2]: *** [all] Error 1
>> make[2]: Leaving directory
>> `/home/openjdk/projects/jdk8_tl/jdk/make/sun/security'
>> make[1]: *** [all] Error 1
>> make[1]: Leaving directory `/home/openjdk/projects/jdk8_tl/jdk/make/sun'
>> make: *** [all] Error 1
>>
>> --
>>
>> Apart from ALT_JDK_IMPORT_PATH are there any other env vars I need to
>> set in order to have a partial build run (using the full build as a
>> base)?
>>
>> Cheers,
>> Martijn

Re: Build error on jdk8/tl project - Thread.o:(.data.rel+0xbc): undefined reference to JVM_SetNativeThreadName

[Martijn Verburg]

Hi all,


Cheers,
Martijn

> 
>
>> 
>>
>> The 2nd option would be the most up to date I guess but seems a bit
>> chicken and egg..
>
> I normally use the latest jdk8 binary, but as I said above, sometimes it
> still fails. In this case, do a full build and save the j2sdk-image
> directory somewhere as later ALT_IMPORT_JDK_PATH. There is no chicken and
> egg problem here, you use the full build output as IMPORT of a jdk-only
> build, and full build does not need an IMPORT at all, and either a full
> build or a jdk-only build depends on a previous veriosn of JDK as BOOTDIR.
>
> Please note there is a bug in our build script that if you already have
> tl/build/{platform} existing, a jdk/make build might fail (at some point in
> smartcard or security, random). Please rename (or move) the
> tl/build/{platform} directory before starting a jdk-only build.

I've been continuing the work to execute a full build followed by a
partial build. However, I think I'm still blocked by an  issue.

Full Build:

I set the following env vars

export LANG=C
export ALT_BOOTDIR=/usr/lib/jvm/java-7-openjdk-amd64

I execute a full build of the cloned code base from
http://hg.openjdk.java.net/jdk8/tl (after get_sources.sh is run) and
that all works fine

Partial Build:


# Create a backup of the full build (as per Weijun's recommendation)
cp -R /home/openjdk/projects/jdk8_tl/build/linux-amd64
/home/openjdk/projects/jdk8_tl/build/linux-amd64_backup

# Set the ALT_JDK_IMPORT_PATH to point to the j2sk-image backup of the
full build
export 
ALT_JDK_IMPORT_PATH=/home/openjdk/projects/jdk8_tl/build/linux-amd64_backup/j2sdk-image

# Run the warnings build
make JAVAC_MAX_WARNINGS=true JAVAC_WARNINGS_FATAL=
OTHER_JAVACFLAGS="-Xmaxwarns 1" &> build.log

It builds up to a point, but then has the problem where it's looking
for due to directory structure issues (it's looking too far back up
the directory tree basically).



/bin/mkdir -p ../../../../build/linux-amd64/tmp/sun/sun.security.ec/unsigned
rm -f ../../../../build/linux-amd64/tmp/sun/sun.security.ec/unsigned/sunec.jar
/usr/lib/jvm/java-7-openjdk-amd64/bin/jar cf
../../../../build/linux-amd64/tmp/sun/sun.security.ec/unsigned/sunec.jar
 -C ../../../../build/linux-amd64/tmp/sun/sun.security.ec/classes
sun/security/ec \
-J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions
-J-XX:-LogVMOutput -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m
-J-XX:MaxPermSize=160m
../../../../build/linux-amd64/tmp/sun/sun.security.ec/classes/sun/security/ec
: no such file or directory
make[3]: *** 
[../../../../build/linux-amd64/tmp/sun/sun.security.ec/unsigned/sunec.jar]
Error 1
make[3]: Leaving directory
`/home/openjdk/projects/jdk8_tl/jdk/make/sun/security/ec'
make[2]: *** [all] Error 1
make[2]: Leaving directory
`/home/openjdk/projects/jdk8_tl/jdk/make/sun/security'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/openjdk/projects/jdk8_tl/jdk/make/sun'
make: *** [all] Error 1

--

Apart from ALT_JDK_IMPORT_PATH are there any other env vars I need to
set in order to have a partial build run (using the full build as a
base)?

Cheers,
Martijn

Re: Is the use case of full OpenJDK followed by the jdk sub tree possible?

[Martijn Verburg]

Ignore this, I found an old thread with some advice that I'd forgotten to
follow  - M

On 21 April 2012 15:27, Martijn Verburg  wrote:

> Hi all,
>
> For the javac bug warnings day I'm trying to set-up a VM which contains a
> full clone of http://hg.openjdk.java.net/jdk8/tl (into
> the ~/jdk8_tl directory). I'm then building the full OpenJDK with:
>
> LANG=C
> ALT_BOOTDIR=/opt/java/1.7.0_03 (an installation of Oracle's binary)
>
> The full build below works just fine:
>
> cd ~/jdk8_tl
> make sanity
> make clean
> make all
>
> I'm then looking to build the jdk sub tree after that with compiler
> warnings switched on. I'm hoping to pick up the latest hotspot etc that was
> just built.  So I execute the following:
>
> cd ~/jdk8_tl/jdk/make
> make clean
> make JAVAC_MAX_WARNINGS=true JAVAC_WARNINGS_FATAL=
> OTHER_JAVACFLAGS="-Xmaxwarns 1" &> build.log
>
> However this subtree build errors out as it can't find various paths/files
> to build/reference.  I started 'educated guessing' what env vars to set
> (such as ALT_HOTSPOT_SERVER_PATH, ALT_HOTSPOT_CLIENT_PATH
> & ALT_HOTSPOT_IMPORT_PATH). However, I'm concerned I'm going down the wrong
> path, as I'm adding more and more env vars, complicating the set-up
> considerably.
>
> Is the set of env vars you would typically set for a full build different
> to a subtree (jdk) build?  Is there a set that will work for both, in
> particular the partial build after the full build?
>
> Cheers,
> Martijn
>

Re: Incorrect bootstrap jdk in documentation

[Martijn Verburg]

Hi John,

I'm not sure going forwards if the documentation is supposed to cover all
OpenJDK forests (in terms of version numbers, that is, OpenJDK 7 and
OpenJDK 8) or whether the documentation will diverge depending on what
forest you're in. I've got a few doc patches I'm holding off on until we
know which way this is going to go.

I've CC'd in Cecilia and Iris, (Ben and I had a meeting with Cecilia and
Tomas about this last week) to see if they can shed some light, as I know
they're intending to update the developer docs shortly.

Cheers,
Martijn

On 17 April 2012 15:03, John Oliver  wrote:

> I was building jdk8 and noticed that your documentation generally states
> that you need a jdk 1.6.0 as a bootstrap, in the following files:
>
> http://hg.openjdk.java.net/**jdk8/build/raw-file/tip/**README-builds.html
> http://hg.openjdk.java.net/**jdk8/build/raw-file/tip/README
>
> When I tried to build using 1.6.0 I received the following:
>
> ERROR:Your  BOOTDIR  environment variable doesnot  point
>   to a validJDK  for  bootstrapping this build.
>   A  JDK  8   build must be bootstrapped using
>   JDK  1.7.0  fcs (or  later).
>   Apparently, your bootstrapJDK  is version1.6.0
>   Please  update yourALT_BOOTDIR  settingand  start your build again.
>
>
>
> When I retried using 1.7.0 as a bootstrap it was fine. I presume those
> files need to be updated to reflect that you now need at least 1.7.0.
>
> Thanks
>
> John
>
>
> --
> John Oliver
>
> InsightfulLogic
> http://www.insightfullogic.com
>
>

Is the use case of full OpenJDK followed by the jdk sub tree possible?

[Martijn Verburg]

Hi all,

For the javac bug warnings day I'm trying to set-up a VM which contains a
full clone of http://hg.openjdk.java.net/jdk8/tl (into
the ~/jdk8_tl directory). I'm then building the full OpenJDK with:

LANG=C
ALT_BOOTDIR=/opt/java/1.7.0_03 (an installation of Oracle's binary)

The full build below works just fine:

cd ~/jdk8_tl
make sanity
make clean
make all

I'm then looking to build the jdk sub tree after that with compiler
warnings switched on. I'm hoping to pick up the latest hotspot etc that was
just built.  So I execute the following:

cd ~/jdk8_tl/jdk/make
make clean
make JAVAC_MAX_WARNINGS=true JAVAC_WARNINGS_FATAL=
OTHER_JAVACFLAGS="-Xmaxwarns 1" &> build.log

However this subtree build errors out as it can't find various paths/files
to build/reference.  I started 'educated guessing' what env vars to set
(such as ALT_HOTSPOT_SERVER_PATH, ALT_HOTSPOT_CLIENT_PATH
& ALT_HOTSPOT_IMPORT_PATH). However, I'm concerned I'm going down the wrong
path, as I'm adding more and more env vars, complicating the set-up
considerably.

Is the set of env vars you would typically set for a full build different
to a subtree (jdk) build?  Is there a set that will work for both, in
particular the partial build after the full build?

Cheers,
Martijn

Re: First build-infra push to jdk8 -- try out the new build system!

[Martijn Verburg]

Hi Henri,

I believe so yes, Fredrik does have a Mac after all ;-)

Cheers,
Martijn

On 21 April 2012 12:34, Henri Gomez  wrote:

> New build system has been tested allready on OSX ?
>
> Le 21 avr. 2012 à 09:10, Fredrik Öhrström  a écrit :
>
> > For the new build you have to explicitly choose release,fastdebug or
> slowdebug.
> > (--with-debug-level=release,fastdebug or slowdebug)
> > So you do not need to turn off fastdebug, it defaults to release.
> >
> > As for the demos and samples. They compile so much faster that there is
> no
> > point in turning them off. 10 seconds on my workstation, and during
> > the incremental
> > they take no detectable time at all.
> >
> > You probably want to do: --with-jvm-variants=server
> > when building on a 32bit machine since the default is client,server
> > (client,server,kernel on 32bit windows) And building extra libjvms does
> take
> > a significant amount of time.
> >
> > //Fredrik
> >
> > 2012/4/21 Brian Goetz :
> >> Is there a list of "features" that can be turned on and off?  With the
> old
> >> build, I customize it with environment variables like
> SKIP_FASTDEBUG_BUILD,
> >> NO_DOCS, NO_SAMPLES, and NO_DEMOS, which shaves lots of time off the
> build.
> >>  Are there equivalent configure flags for these?
> >>
> >>
> >> On 4/12/2012 5:47 AM, Magnus Ihse Bursie wrote:
> >>>
> >>> The build-infra project [1] has been working for a while with creating
> a
> >>> new build system. The goals of the project include, but are not limited
> >>> to, improved build performance and improved ease of use.
> >>>
> >>> The first part of this project has now been pushed to the jdk8 master
> >>> forest. This means that the new build system is available for you to
> try
> >>> out! The old build system is still there, and if you want to continue
> to
> >>> use it, you will notice no difference (for now...).
> >>>
> >>> But if you are interested in trying the new build system, we welcome
> you
> >>> to experiment with it! The basic operation is:
> >>> cd common/makefiles
> >>> ../autoconf/configure
> >>> make
> >>>
> >>> More information is available in the new build README [2]. If you want
> >>> to try the new build system, please read it first.
> >>>
> >>> Please note that the new build system is not yet complete. We do not
> yet
> >>> have full platform support, nor are all parts of the old build
> converted
> >>> (but then we fall back on the old build system), and there are likely
> to
> >>> be bugs. Most of all, we need to have exposure on a wide range of
> >>> different build systems, since the reality is always so much messier
> >>> than you'd want to believe. :-) Please help us to resolve such issues
> >>> early by trying the new build system!
> >>>
> >>> Any questions or discussions on the new build system should be sent to
> >>> build-dev@openjdk.java.net.
> >>>
> >>> /Magnus
> >>>
> >>> [1] http://openjdk.java.net/projects/build-infra/index.html
> >>> [2] http://openjdk.java.net/projects/build-infra/guide.html
> >>>
> >>
>

Re: Gawk missing from make sanity check?

[Martijn Verburg]

Hi all,

I'll also add that g++ and the various X11 extension libraries are also not
looked for by make sanity (as far as I can tell).  Again, simple enough to
fix/find, but just in case this was expected to be picked up.

Cheers,
Martijn

On 16 April 2012 10:08, Martijn Verburg  wrote:

> Hi all,
>
> I've been building various VM's in preparation for our next OpenJDK hack
> day (as well as testing out build-infra).  My VM is an Lubuntu 11.10
> (32-bit).
>
> I noticed that when:
>
> make sanity
>
> passes,
>
> make clean
>
> still fails due to gawk not being available.  This is a simple fix but I
> thought that perhaps this was missing from the make sanity check?
>
> Cheers,
> Martijn
>

Gawk missing from make sanity check?

[Martijn Verburg]

Hi all,

I've been building various VM's in preparation for our next OpenJDK hack
day (as well as testing out build-infra).  My VM is an Lubuntu 11.10
(32-bit).

I noticed that when:

make sanity

passes,

make clean

still fails due to gawk not being available.  This is a simple fix but I
thought that perhaps this was missing from the make sanity check?

Cheers,
Martijn

Re: 'One-off' directory error when running jtreg

[Martijn Verburg]

Hi all,

That did trick, thanks all.  Will try the build-infra build next.

Cheers,
Martijn

On 9 April 2012 21:01, Kelly O'Hair  wrote:

> Set PRODUCT_HOME manually.
> The Makefile can only guess where the build might be, and although we
> could add in a second guess, that
> could be a problem too.  Setting PRODUCT_HOME on the make command line
> will guarantee what it uses.
>
> -kto
>
> On Apr 9, 2012, at 12:28 PM, Martijn Verburg wrote:
>
> Hi all,
>
> I'm building the full tl project (which builds fine) and am then running
> the jtreg tests for the jdk util package (from $OPENJDK_SOURCE/jdk/test)
> with:
>
> make jdk_util > test.log
>
> I seem to be getting a one-off error with the directory structure that
> it's looking for with regards the java executable that's been built, e.g.
>
> ACTION: build -- Error. Cannot get VM for test: java.io.IOException:
> Cannot run program
> "/home/openjdk/sources/jdk8_tl/jdk/test/../build/linux-i586/bin/java" (in
> directory
> "/home/openjdk/sources/jdk8_tl/jdk/build/linux-i586/testoutput/jdk_util/JTwork/scratch"):
> error=2, No such file or directory
> REASON: Named class compiled on demand
> TIME:   0.021 seconds
> messages:
> command: build ToString
> reason: Named class compiled on demand
> elapsed time (seconds): 0.021
>
> This makes kind of sense since the java binary is actually at:
>
> /home/openjdk/sources/jdk8_tl/jdk/test/../../build/linux-i586/bin/java
>
> as opposed to:
>
> /home/openjdk/sources/jdk8_tl/jdk/test/../build/linux-i586/bin/java
>
> Should I be setting the $PRODUCT_HOME manually or have I done something
> wrong? :-)
>
> Cheers,
> Martijn
>
>
>

'One-off' directory error when running jtreg

[Martijn Verburg]

Hi all,

I'm building the full tl project (which builds fine) and am then running
the jtreg tests for the jdk util package (from $OPENJDK_SOURCE/jdk/test)
with:

make jdk_util > test.log

I seem to be getting a one-off error with the directory structure that it's
looking for with regards the java executable that's been built, e.g.

ACTION: build -- Error. Cannot get VM for test: java.io.IOException: Cannot
run program
"/home/openjdk/sources/jdk8_tl/jdk/test/../build/linux-i586/bin/java" (in
directory
"/home/openjdk/sources/jdk8_tl/jdk/build/linux-i586/testoutput/jdk_util/JTwork/scratch"):
error=2, No such file or directory
REASON: Named class compiled on demand
TIME:   0.021 seconds
messages:
command: build ToString
reason: Named class compiled on demand
elapsed time (seconds): 0.021

This makes kind of sense since the java binary is actually at:

/home/openjdk/sources/jdk8_tl/jdk/test/../../build/linux-i586/bin/java

as opposed to:

/home/openjdk/sources/jdk8_tl/jdk/test/../build/linux-i586/bin/java

Should I be setting the $PRODUCT_HOME manually or have I done something
wrong? :-)

Cheers,
Martijn

Re: Where does 'make sanity' look for the ANT version?

[Martijn Verburg]

Hi Sergey,

>> I corrected a permissions problem on the tools.jar file and make
>> sanity ran smoothly after that. Now having fun trying to find
>> the exact Ubnutu package that contains the X11 headers the build
>> needs, but that's a different story :-)
>
> Hi, Martijn.
> This should works
> sudo apt-get install libxrender-dev build-essential gawk libasound2-dev
> libfreetype6-dev libcups2-dev libxt-dev libx11-dev libxtst-dev

Ah, thanks for the full list, it confirms what I had and actually allows me to
remove a couple of extra packages I didn't need.  This is really great as I'm
rally close to having a simple list of instructions that OpenJDK hackday
folk can follow easily (as well as turning this into a Vagrant script
or similar).

The build now runs fun, next up is running the jtreg suite :-). This will be
another week+ as I'm off to Crete to spend a week with Heinz getting
my brain twisted over concurrency :-)

Thanks everyone for their support and patience so far!

Cheers,
Martijn

Re: Where does 'make sanity' look for the ANT version?

[Martijn Verburg]

Hi Stuart,

Thanks for looking into that for me, I'll keep a note of the location
of Sanity.gmk going
forwards.  I have managed to resolve the issue, it was a curious case where my
1.8.2 ANT install couldn't find $ALT_BOOTDIR//lib/tools.jar and
therefore 'failed', the
build then defaulted back to an ant under the langtools folder.

I corrected a permissions problem on the tools.jar file and make
sanity ran smoothly
after that. Now having fun trying to find the exact Ubnutu package
that contains the
X11 headers the build needs, but that's a different story :-)

Cheers,
Martijn

On 28 March 2012 02:22, Stuart Marks  wrote:


> Hi Martijn!
>
> One of my colleagues ran into this the other day. I don't know all the
> details and the solution but I have a clue that might help you move forward.
>
> In make/common/shared/Sanity.gmk there are the lines,
>
>> _ANT_VER:=$(shell $(ANT) -version 2>&1 )
>> ANT_VER:=$(call GetVersion,"$(_ANT_VER)")
>
>
> The GetVersion function (defined in Defs.gmk) extracts the version number
> from the shell output using a regexp. Unfortunately there seem to be
> circumstances -- not sure exactly what they are though -- when the shell
> output includes a *java* version number, either in the output or in a path.
> Clearly you're using Java 7 -- that is, JDK 1.7.0 -- and the GetVersion
> regexp is happily picking this up thinking it's the ant version number.
>
> One path forward would be to investigate why "shell $(ANT) -version" is
> returning some unexpected output and is possibly not even running ant at
> all.
>
> I'll forward this to my colleague to see whether he has anything to add.
>
> s'marks
>
>
>
> On 3/26/12 3:55 AM, Martijn Verburg wrote:
>>
>> Hi all,
>>
>> So I'm building new VMs to try the various OpenJDK builds and have run
>> across a pretty consistent problem using Lubuntu 11.10 (32-bit) with
>> the detection of ANT.
>>
>> I have ANT 1.8.2 installed (Ant 1.7 is clearly removed) but 'make
>> sanity' insists that the ANT version I have is 1.7.0.
>>
>> * My DEVTOOLS_PATH is pointing at /usr/bin which has the correct version
>> of ANT
>> * When I set ANT_HOME (export ANT_HOME=/usr/share/ant) before running
>> 'make sanity' it doesn't appear to take hold (the output from make
>> sanity shows ANT_HOME to be blank)
>>
>> I'm not sure where else it might be reading this from, does anyone
>> where I should go spelunking to see where it makes this check?
>>
>> Cheers,
>> Martijn

Where does 'make sanity' look for the ANT version?

[Martijn Verburg]

Hi all,

So I'm building new VMs to try the various OpenJDK builds and have run
across a pretty consistent problem using Lubuntu 11.10 (32-bit) with
the detection of ANT.

I have ANT 1.8.2 installed (Ant 1.7 is clearly removed) but 'make
sanity' insists that the ANT version I have is 1.7.0.

* My DEVTOOLS_PATH is pointing at /usr/bin which has the correct version of ANT
* When I set ANT_HOME (export ANT_HOME=/usr/share/ant) before running
'make sanity' it doesn't appear to take hold (the output from make
sanity shows ANT_HOME to be blank)

I'm not sure where else it might be reading this from, does anyone
where I should go spelunking to see where it makes this check?

Cheers,
Martijn

Re: Build error on jdk8/tl project - Thread.o:(.data.rel+0xbc): undefined reference to JVM_SetNativeThreadName

[Martijn Verburg]

> On 25 March 2012 13:11, Alan Bateman  wrote:
>> On 25/03/2012 13:01, Martijn Verburg wrote:
>>>
>>> Hi Sean/Alan/Max,
>>>
>>> Sean - Your solution did the trick, and I'll probably use this for now as
>>> it means a smaller VM for the members to work with
>>> Alan/Max - I did get the full build going, but then my VM ran out of
>>> space.
>>
>> I see Seán suggestion is to use a 7u4 build as the import JDK but since you
>> are building jdk8 (jdk8/tl/jdk is jdk8) then your import JDK has to be jdk8
>> too, otherwise you'll end up combining 7u4 and 8 bits in the build so there
>> is no guarantee that you'll get consistent bits. In general partial builds
>> are fragile and one needs to take great care to ensure that the import JDK
>> matches exact the repositories that you are building.
>
> Hi Alan,
>
> Understood, I'll try with a purely 8 approach.
>
> Cheers,
> Martijn

Hi Alan/all,

Apologies for top posting before, I'll try to follow along properly now.

I've started from scratch and wanted to make sure I have my
environment variables correct for building the jdk8/tl project. I've
currently got my two JDK related environment variables set up as
follows:

export ALT_BOOTDIR=/home/openjdk/opt/jdk1.7.0_04
export ALT_JDK_IMPORT_PATH=/home/openjdk/opt/jdk1.7.0_04

Alan, I think you were suggesting that these ALT_BOOTDIR &
ALT_JDK_IMPORT_PATH should to point to a jdk8 install of some sort.
So my question in return is:

Q:  Should I install an openjdk-8 binary to reference, or should I
reference back to something that I've built from source?

The 2nd option would be the most up to date I guess but seems a bit
chicken and egg..

As an aside I'm writing this all up to add to Cecelia's documentation
efforts.  The README-build.html is really helpful, but is a little
outdated in that it seems to be talking about building openjdk6

Cheers,
Martijn

Re: Build error on jdk8/tl project - Thread.o:(.data.rel+0xbc): undefined reference to JVM_SetNativeThreadName

[Martijn Verburg]

Hi Alan,

Understood, I'll try with a purely 8 approach.

Cheers,
Martijn

On 25 March 2012 13:11, Alan Bateman  wrote:
> On 25/03/2012 13:01, Martijn Verburg wrote:
>>
>> Hi Sean/Alan/Max,
>>
>> Sean - Your solution did the trick, and I'll probably use this for now as
>> it means a smaller VM for the members to work with
>> Alan/Max - I did get the full build going, but then my VM ran out of
>> space.
>
> I see Seán suggestion is to use a 7u4 build as the import JDK but since you
> are building jdk8 (jdk8/tl/jdk is jdk8) then your import JDK has to be jdk8
> too, otherwise you'll end up combining 7u4 and 8 bits in the build so there
> is no guarantee that you'll get consistent bits. In general partial builds
> are fragile and one needs to take great care to ensure that the import JDK
> matches exact the repositories that you are building.
>
> -Alan.

Re: Build error on jdk8/tl project - Thread.o:(.data.rel+0xbc): undefined reference to JVM_SetNativeThreadName

[Martijn Verburg]

Hi Sean/Alan/Max,

Sean - Your solution did the trick, and I'll probably use this for now as
it means a smaller VM for the members to work with
Alan/Max - I did get the full build going, but then my VM ran out of space.

So I'm now going to go away and build a smaller VM for enthusiasts to fix
warnings etc in the tl/jdk project and a larger VM for the braver souls who
want to build and explore the whole thing.

Thanks for the help folks!

Cheers,
Martijn

On 23 March 2012 10:11, Seán Coffey  wrote:

> **
> Martijn,
>
> I ran into same issue a few weeks back. If you're only interested in
> building the jdk repo, you can update your ALT_HOTSPOT_IMPORT_PATH variable
> to point to a recent 7u4 build.
>
> e.g export ALT_HOTSPOT_IMPORT_PATH=/export/home/jdk1.7.0_04
>
> recent binaries at : http://jdk7.java.net/download.html
>
> HTH,
> Sean.
>
>
> On 23/03/2012 09:46, Martijn Verburg wrote:
>
> Hi Alan/Max,
>
>  You're both right, I've actually been working from
> http://hg.openjdk.java.net/jdk8/tl/jdk as opposed to
> http://hg.openjdk.java.net/jdk8/tl - thanks for catching that with the
> limited info I posted.
>
>  Will start from scratch from http://hg.openjdk.java.net/jdk8/tl and see
> where the yellow brick road takes me :-)
>
>  Cheers,
>  Martijn
>
> On 23 March 2012 06:16, Weijun Wang  wrote:
>
>> A partial build is you go inside tl/jdk/make/ and run make there, it only
>> builds the tl/jdk part, and the output goes to tl/jdk/build/linux-i586. A
>> full build is you go inside tl/ and run make there, it builds all repos,
>> and output goes to tl/build/linux-i586.
>>
>> I suspect you're doing a partial build because these 2 options appear in
>> the error:
>>
>>-I../../../build/linux-i586/tmp/java/java.lang/java/CClassHeaders
>>-I../../../src/solaris/javavm/export
>>
>> This means "src" and "build" are at the same directory levels. Therefore
>> the "build" is inside tl/jdk.
>>
>> -Max
>>
>>
>> On 03/23/2012 01:51 AM, Martijn Verburg wrote:
>>
>>>  Hi Andrew/Alan,
>>>
>>> Thanks for responding! I suspect you are right, I'm only building the tl
>>> project, which i guess is a partial build? I saw the patch that Andrew
>>> mentioned but hadn't put 2 and 2 together that I'd need to build the
>>> hotspot part separately first.
>>>
>>> I'll try that next, my next post will likely be a q about building the
>>> hotspot part or providing the extra info Andrew requested.
>>>
>>> Cheers,
>>> Martijn
>>>
>>>
>>>
>>>
>>> On Thursday, 22 March 2012, Alan Bateman >>   <mailto:alan.bate...@oracle.com>> wrote:
>>>  > On 22/03/2012 15:19, Martijn Verburg wrote:
>>>  >>
>>>  >> Hi all,
>>>  >>
>>>  >> I'm back from holiday and am building the latest
>>> (http://hg.openjdk.java.net/jdk8/tl/jdk) project for our 3rd Java User
>>> Group OpenJDK hack day. I've run across an error that I haven't been
>>> able to resolve.
>>>  >>
>>>  >> ..
>>>  >> ..
>>>  >>
>>>
>>> ../../../build/linux-i586/tmp/java/java.lang/java/obj/Thread.o:(.data.rel+0xbc):
>>> undefined reference to `JVM_SetNativeThreadName'
>>>  >> collect2: ld returned 1 exit status
>>>  >> make[2]: *** [../../../build/linux-i586/lib/i386/libjava.so] Error 1
>>>  >> make[2]: Leaving directory `/home/openjdk/sources/jdk/make/java/java'
>>>  >> make[1]: *** [all] Error 1
>>>  >> make[1]: Leaving directory `/home/openjdk/sources/jdk/make/java'
>>>  >> make: *** [all] Error 1
>>>  >>
>>>  >> I've posted a more verbose version of the error at
>>> http://pastebin.com/9exQpFkq
>>>  >>
>>>  >> I got a bit lost in the C++ spelunking, so Ben Evans gave me a hand
>>> and we think we've tracked it down to the fact that the reference to
>>> JVM_SetNativeThreadName is not in java_lang_Thread.h (a generated
>>> header).  Looking at java_lang_Thread.h, the reference that is the
>>> closest is Java_SetNativeThreadName, which we think has been incorrectly
>>> generated.
>>>  >>
>>>  >> I'll confess I haven't caught up with the last couple of months
>>> archives, so I'm not sure if I missed a javah issue or something else
>>> obvious.
>>>  >>
>>>  >> Cheers,
>>>  >> Martijn
>>>  >
>>>  > Martijn - is this a partial build by any chance? I can imagine the
>>> above failure if doing a partial build and the import JDK is not in sync.
>>>  >
>>>  > -Alan
>>>  >
>>>  >
>>>  >
>>>
>>
>

Re: Build error on jdk8/tl project - Thread.o:(.data.rel+0xbc): undefined reference to JVM_SetNativeThreadName

[Martijn Verburg]

Hi Alan/Max,

You're both right, I've actually been working from
http://hg.openjdk.java.net/jdk8/tl/jdk as opposed to
http://hg.openjdk.java.net/jdk8/tl - thanks for catching that with the
limited info I posted.

Will start from scratch from http://hg.openjdk.java.net/jdk8/tl and see
where the yellow brick road takes me :-)

Cheers,
Martijn

On 23 March 2012 06:16, Weijun Wang  wrote:

> A partial build is you go inside tl/jdk/make/ and run make there, it only
> builds the tl/jdk part, and the output goes to tl/jdk/build/linux-i586. A
> full build is you go inside tl/ and run make there, it builds all repos,
> and output goes to tl/build/linux-i586.
>
> I suspect you're doing a partial build because these 2 options appear in
> the error:
>
>-I../../../build/linux-i586/**tmp/java/java.lang/java/**CClassHeaders
>-I../../../src/solaris/javavm/**export
>
> This means "src" and "build" are at the same directory levels. Therefore
> the "build" is inside tl/jdk.
>
> -Max
>
>
> On 03/23/2012 01:51 AM, Martijn Verburg wrote:
>
>> Hi Andrew/Alan,
>>
>> Thanks for responding! I suspect you are right, I'm only building the tl
>> project, which i guess is a partial build? I saw the patch that Andrew
>> mentioned but hadn't put 2 and 2 together that I'd need to build the
>> hotspot part separately first.
>>
>> I'll try that next, my next post will likely be a q about building the
>> hotspot part or providing the extra info Andrew requested.
>>
>> Cheers,
>> Martijn
>>
>>
>>
>>
>> On Thursday, 22 March 2012, Alan Bateman > <mailto:Alan.Bateman@oracle.**com >> wrote:
>>  > On 22/03/2012 15:19, Martijn Verburg wrote:
>>  >>
>>  >> Hi all,
>>  >>
>>  >> I'm back from holiday and am building the latest
>> (http://hg.openjdk.java.net/**jdk8/tl/jdk<http://hg.openjdk.java.net/jdk8/tl/jdk>)
>> project for our 3rd Java User
>> Group OpenJDK hack day. I've run across an error that I haven't been
>> able to resolve.
>>  >>
>>  >> ..
>>  >> ..
>>  >>
>> ../../../build/linux-i586/tmp/**java/java.lang/java/obj/**
>> Thread.o:(.data.rel+0xbc):
>> undefined reference to `JVM_SetNativeThreadName'
>>  >> collect2: ld returned 1 exit status
>>  >> make[2]: *** [../../../build/linux-i586/**lib/i386/libjava.so] Error
>> 1
>>  >> make[2]: Leaving directory `/home/openjdk/sources/jdk/**
>> make/java/java'
>>  >> make[1]: *** [all] Error 1
>>  >> make[1]: Leaving directory `/home/openjdk/sources/jdk/**make/java'
>>  >> make: *** [all] Error 1
>>  >>
>>  >> I've posted a more verbose version of the error at
>> http://pastebin.com/9exQpFkq
>>  >>
>>  >> I got a bit lost in the C++ spelunking, so Ben Evans gave me a hand
>> and we think we've tracked it down to the fact that the reference to
>> JVM_SetNativeThreadName is not in java_lang_Thread.h (a generated
>> header).  Looking at java_lang_Thread.h, the reference that is the
>> closest is Java_SetNativeThreadName, which we think has been incorrectly
>> generated.
>>  >>
>>  >> I'll confess I haven't caught up with the last couple of months
>> archives, so I'm not sure if I missed a javah issue or something else
>> obvious.
>>  >>
>>  >> Cheers,
>>  >> Martijn
>>  >
>>  > Martijn - is this a partial build by any chance? I can imagine the
>> above failure if doing a partial build and the import JDK is not in sync.
>>  >
>>  > -Alan
>>  >
>>  >
>>  >
>>
>

Re: Build error on jdk8/tl project - Thread.o:(.data.rel+0xbc): undefined reference to JVM_SetNativeThreadName

[Martijn Verburg]

Hi Andrew/Alan,

Thanks for responding! I suspect you are right, I'm only building the tl
project, which i guess is a partial build? I saw the patch that Andrew
mentioned but hadn't put 2 and 2 together that I'd need to build the
hotspot part separately first.

I'll try that next, my next post will likely be a q about building the
hotspot part or providing the extra info Andrew requested.

Cheers,
Martijn




On Thursday, 22 March 2012, Alan Bateman  wrote:
> On 22/03/2012 15:19, Martijn Verburg wrote:
>>
>> Hi all,
>>
>> I'm back from holiday and am building the latest (
http://hg.openjdk.java.net/jdk8/tl/jdk) project for our 3rd Java User Group
OpenJDK hack day. I've run across an error that I haven't been able to
resolve.
>>
>> ..
>> ..
>>
../../../build/linux-i586/tmp/java/java.lang/java/obj/Thread.o:(.data.rel+0xbc):
undefined reference to `JVM_SetNativeThreadName'
>> collect2: ld returned 1 exit status
>> make[2]: *** [../../../build/linux-i586/lib/i386/libjava.so] Error 1
>> make[2]: Leaving directory `/home/openjdk/sources/jdk/make/java/java'
>> make[1]: *** [all] Error 1
>> make[1]: Leaving directory `/home/openjdk/sources/jdk/make/java'
>> make: *** [all] Error 1
>>
>> I've posted a more verbose version of the error at
http://pastebin.com/9exQpFkq
>>
>> I got a bit lost in the C++ spelunking, so Ben Evans gave me a hand and
we think we've tracked it down to the fact that the reference to
JVM_SetNativeThreadName is not in java_lang_Thread.h (a generated header).
 Looking at java_lang_Thread.h, the reference that is the closest is
Java_SetNativeThreadName, which we think has been incorrectly generated.
>>
>> I'll confess I haven't caught up with the last couple of months
archives, so I'm not sure if I missed a javah issue or something else
obvious.
>>
>> Cheers,
>> Martijn
>
> Martijn - is this a partial build by any chance? I can imagine the above
failure if doing a partial build and the import JDK is not in sync.
>
> -Alan
>
>
>

Build error on jdk8/tl project - Thread.o:(.data.rel+0xbc): undefined reference to JVM_SetNativeThreadName

[Martijn Verburg]

Hi all,

I'm back from holiday and am building the latest (
http://hg.openjdk.java.net/jdk8/tl/jdk) project for our 3rd Java User Group
OpenJDK hack day. I've run across an error that I haven't been able to
resolve.

..
..
../../../build/linux-i586/tmp/java/java.lang/java/obj/Thread.o:(.data.rel+0xbc):
undefined reference to `JVM_SetNativeThreadName'
collect2: ld returned 1 exit status
make[2]: *** [../../../build/linux-i586/lib/i386/libjava.so] Error 1
make[2]: Leaving directory `/home/openjdk/sources/jdk/make/java/java'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/openjdk/sources/jdk/make/java'
make: *** [all] Error 1

I've posted a more verbose version of the error at
http://pastebin.com/9exQpFkq

I got a bit lost in the C++ spelunking, so Ben Evans gave me a hand and we
think we've tracked it down to the fact that the reference to
JVM_SetNativeThreadName is not in java_lang_Thread.h (a generated header).
Looking at java_lang_Thread.h, the reference that is the closest is
Java_SetNativeThreadName, which we think has been incorrectly generated.

I'll confess I haven't caught up with the last couple of months archives,
so I'm not sure if I missed a javah issue or something else obvious.

Cheers,
Martijn