Integrated: 8253375: OSX build fails with Xcode 12.0 (12A7209)

[Paul Hohensee]

On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee  wrote:

> Please review this small patch to enable the OSX build using Xcode 12.0.
> 
> Thanks,
> Paul

This pull request has now been integrated.

Changeset: f80a6066
Author:Paul Hohensee 
URL:   https://git.openjdk.java.net/jdk/commit/f80a6066
Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8253375: OSX build fails with Xcode 12.0 (12A7209)

Replace double array with short array in 
AdapterHandlerLibrary::create_native_wrapper, add parens around ?: in
CSystemColors:getColor

Reviewed-by: prr, kbarrett, lucy

-

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

Re: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209) [v2]

[Paul Hohensee]

> Please review this small patch to enable the OSX build using Xcode 12.0.
> 
> Thanks,
> Paul

Paul Hohensee has updated the pull request with a new target base due to a 
merge or a rebase. The incremental webrev
excludes the unrelated changes brought in by the merge/rebase. The pull request 
contains three additional commits since
the last revision:

 - 8253375: Reverted CSystemColors.m patch, replaced sharedRuntime.cpp patch
 - Merge branch 'master' into JDK-8253375
 - JDK-8253375

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/348/files
  - new: https://git.openjdk.java.net/jdk/pull/348/files/5db5edc2..cb08da07

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=348&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=348&range=00-01

  Stats: 27610 lines in 391 files changed: 4691 ins; 21610 del; 1309 mod
  Patch: https://git.openjdk.java.net/jdk/pull/348.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/348/head:pull/348

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

RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209)

[Paul Hohensee]

Please review this small patch to enable the OSX build using Xcode 12.0.

Thanks,
Paul

-

Commit messages:
 - JDK-8253375

Changes: https://git.openjdk.java.net/jdk/pull/348/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=348&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253375
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/348.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/348/head:pull/348

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

Re: Request for review: hotspot/jprt.properties [S]

[Paul Hohensee]

Looks good.

Paul

On 2/2/12 6:56 PM, Keith McGuigan wrote:

Hello,

Here's a webrev for changing the default JPRT release value for 
hotspot to jdk8.  It can still be overridden by the -release jdk7 
during JPRT submission.  I also removed references to pre-7 releases 
and other unused value (jdk7b107, jdk7temp).


The targets and parameters for jdk7 & jdk8 are identical for now, but 
it's probably good to keep the distinction in the file so we can 
update jdk8 targets independently as development continues.


http://cr.openjdk.java.net/~kamg/7069991/webrev.00/

Thanks for any reviews.

--
- Keith

Re: Review for 7141244: build-infra merge: Include $(SPEC) in makefiles and make variables overridable

[Paul Hohensee]

Thanks for the explanation.  As long as I can still do builds from
make/, I'm happy.

Paul

On 2/7/12 7:42 PM, David Holmes wrote:

On 8/02/2012 2:55 AM, Paul Hohensee wrote:
Can you make this work when building from the make/ 
directories?

E.g., you could add the $(SPEC) include to make/solaris/Makefile, etc.


I'm not sure that makes sense. The SPEC file only exists for the new 
build and in the new build you run configure for each platform, so if 
you configured for solaris then that is the only build you can do 
there. You can't decide to do a linux build instead - you need to 
re-run configure.


I'll take a look at this ASAP but am somewhat swamped right now.

David


Thanks,

Paul

On 2/7/12 11:30 AM, Erik Joelsson wrote:

http://cr.openjdk.java.net/~erikj/7141244/webrev.00/
<http://cr.openjdk.java.net/%7Eerikj/7141244/webrev.00/>
178 lines changed: 115 ins; 7 del; 56 mod; 4625 unchg

7141244: build-infra merge: Include $(SPEC) in makefiles and make
variables overridable

The build-infra project is starting to move into jdk8. For the hotspot
build to stay compatible with the changes, key hotspot makefiles need
to add an optional include statement:


-include $(SPEC)

In the new build system, the spec file is generated by configure and
contains the configuration for the build. Only a handfull of files
need to add this line.

In addition to including the spec file, some variables need to be
changed to only be set conditionally so that a value from the spec
file takes precedence. These are: CC, CXX, CPP, AS, MCS, STRIP, NM,
NAWK (and for windows RC and MT). The hotspot makefiles should check
each variable if it's already set or if it has a gnumake default value.

These changes have been verified to work for hotspot-rt. Jdk7u will be
verified as well before pushing.

/Erik

Re: Review for 7141244: build-infra merge: Include $(SPEC) in makefiles and make variables overridable

[Paul Hohensee]

Can you make this work when building from the make/ directories?
E.g., you could add the $(SPEC) include to make/solaris/Makefile, etc.

Thanks,

Paul

On 2/7/12 11:30 AM, Erik Joelsson wrote:
http://cr.openjdk.java.net/~erikj/7141244/webrev.00/ 


178 lines changed: 115 ins; 7 del; 56 mod; 4625 unchg

7141244: build-infra merge: Include $(SPEC) in makefiles and make 
variables overridable


The build-infra project is starting to move into jdk8. For the hotspot 
build to stay compatible with the changes, key hotspot makefiles need 
to add an optional include statement:



-include $(SPEC)

In the new build system, the spec file is generated by configure and 
contains the configuration for the build. Only a handfull of files 
need to add this line.


In addition to including the spec file, some variables need to be 
changed to only be set conditionally so that a value from the spec 
file takes precedence. These are: CC, CXX, CPP, AS, MCS, STRIP, NM, 
NAWK (and for windows RC and MT). The hotspot makefiles should check 
each variable if it's already set or if it has a gnumake default value.


These changes have been verified to work for hotspot-rt. Jdk7u will be 
verified as well before pushing.


/Erik

Re: Request for review: hotspot/jprt.properties [S]

[Paul Hohensee]

Correct.  Sustaining owns the pre-7 releases.

Paul

On 2/3/12 6:55 AM, Keith McGuigan wrote:



On 2/2/2012 9:01 PM, David Holmes wrote:

On 3/02/2012 9:56 AM, Keith McGuigan wrote:

Here's a webrev for changing the default JPRT release value for hotspot
to jdk8. It can still be overridden by the -release jdk7 during JPRT
submission. I also removed references to pre-7 releases and other 
unused

value (jdk7b107, jdk7temp).


Are we sure there is no reason to leave any pre-7 release info here?


As far as I know, hsx will be used only for jdk7 & jdk8 releases, 
anything pre-7 has it's own separate hotspot repository (or it will, 
if needed).


--
- Keith

Re: Patch to fix build breakage with GCC 4.7

[Paul Hohensee]

On, and it's not supported by Oracle, of course.  One of the Linux
distro companies might be interested though.

On 2/1/12 7:12 AM, Paul Hohensee wrote:

linux-sparc used to build and run fine (I did the port way back when),
so it should be relatively easy to resurrect.  The original port was on
a T1.

Paul

On 1/31/12 10:23 AM, Deepak Bhole wrote:

* David Holmes  [2012-01-30 21:50]:

On 31/01/2012 12:36 PM, Deepak Bhole wrote:

* David Holmes   [2012-01-30 19:57]:

While gcc compilation on sparc is rare I'm not sure that simply
deleting the sparc-only option unconditionally is the right thing to
do.


I thought about that too. But I was unable to find info on OpenJDK +
SPARC + Linux. Is that combination even supported? The README doesn't
list it:
http://hg.openjdk.java.net/jdk6/jdk6/raw-file/tip/README-builds.html#MBE 


Linux-sparc is not one of Oracle's supported OpenJDK platforms.
However AFAIK there are people in the community building OpenJDK on
Linux-sparc using the Zero interpreter. I don't know if this would
affect them but it still seems to me that we should be careful not
to break other people's builds.


Ah fair enough. If it is supported, the patch definitely needs to be
fixed. I will re-post.

Thanks for taking a look!

Deepak


David
-


The option seemed more like a relic from Solaris + SPARC config rather
than a requirement for Linux + SPARC.




Cheers,
Deepak


David

On 31/01/2012 1:20 AM, Deepak Bhole wrote:

Hi,

JDK builds currently fail with GCC 4.7 due to its stricter option
checking.

GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. 
Certain
files in JDK supply the -mimpure-text option to GCC. This option 
is only
valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during 
build

on Linux (I suppose .

This patch removes the option:
http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00

1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html
2: 
http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html


If OK for push, please feel free to do so (I don't have commit 
access).


Cheers,
Deepak

Re: Patch to fix build breakage with GCC 4.7

[Paul Hohensee]

linux-sparc used to build and run fine (I did the port way back when),
so it should be relatively easy to resurrect.  The original port was on
a T1.

Paul

On 1/31/12 10:23 AM, Deepak Bhole wrote:

* David Holmes  [2012-01-30 21:50]:

On 31/01/2012 12:36 PM, Deepak Bhole wrote:

* David Holmes   [2012-01-30 19:57]:

While gcc compilation on sparc is rare I'm not sure that simply
deleting the sparc-only option unconditionally is the right thing to
do.


I thought about that too. But I was unable to find info on OpenJDK +
SPARC + Linux. Is that combination even supported? The README doesn't
list it:
http://hg.openjdk.java.net/jdk6/jdk6/raw-file/tip/README-builds.html#MBE

Linux-sparc is not one of Oracle's supported OpenJDK platforms.
However AFAIK there are people in the community building OpenJDK on
Linux-sparc using the Zero interpreter. I don't know if this would
affect them but it still seems to me that we should be careful not
to break other people's builds.


Ah fair enough. If it is supported, the patch definitely needs to be
fixed. I will re-post.

Thanks for taking a look!

Deepak


David
-


The option seemed more like a relic from Solaris + SPARC config rather
than a requirement for Linux + SPARC.




Cheers,
Deepak


David

On 31/01/2012 1:20 AM, Deepak Bhole wrote:

Hi,

JDK builds currently fail with GCC 4.7 due to its stricter option
checking.

GCC 4.6 and prior ignored invalid options -- GCC 4.7 does not. Certain
files in JDK supply the -mimpure-text option to GCC. This option is only
valid on SPARC[1,2]. As a result, GCC 4.7 throws an error during build
on Linux (I suppose .

This patch removes the option:
http://cr.openjdk.java.net/~dbhole/GCC-4.7-JDK8.00

1: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/SPARC-Options.html
2: http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/i386-and-x86_002d64-Options.html

If OK for push, please feel free to do so (I don't have commit access).

Cheers,
Deepak

Re: RFR: 7133124 Remove redundant packages from JAR command line

[Paul Hohensee]

Apparently yes.  Thanks,

paul

On 1/26/12 9:14 AM, Paul Hohensee wrote:

Will this fix the jdk7u-dev build problem?

Thanks,

paul

On 1/26/12 4:44 AM, Rickard Bäckman wrote:

Hi,

We have a problem with some versions of jar reporting errors when 
trying to run jar cf  com/test com/test/foo


This fix removes the redundant subdirectories from the command.

Webrev is here:
http://cr.openjdk.java.net/~rbackman/7133124/webrev/

Thanks
/Rickard

Re: RFR: 7133124 Remove redundant packages from JAR command line

[Paul Hohensee]

Will this fix the jdk7u-dev build problem?

Thanks,

paul

On 1/26/12 4:44 AM, Rickard Bäckman wrote:

Hi,

We have a problem with some versions of jar reporting errors when 
trying to run jar cf  com/test com/test/foo


This fix removes the redundant subdirectories from the command.

Webrev is here:
http://cr.openjdk.java.net/~rbackman/7133124/webrev/

Thanks
/Rickard

Re: Help me to build openjdk on my machine

[Paul Hohensee]

Sent to the list only, so cc'ing Max and John.

Paul

On 7/10/11 2:44 PM, Paul Hohensee wrote:

Hi Max and John,

Afaik, there's no support for PPC in openjdk.  Oracle has a private 
port, however,
for which the build framework exists in the open, which is why you can 
get a little

way in the build process.

zero is a psuedo-platform which should build and run on any machine 
because it
includes a platform-independent interpreter.  It should build and run 
on PPC.


Paul

On 7/10/11 11:41 AM, John Yeary wrote:

Hello Max,

I have not been able to get it to compile either and at this point no 
one has responded to my post about PPC. I am not sure if it will 
compile for our platform any more.


Does anyone have a successful recent build?

John

On Sun, Jul 10, 2011 at 6:11 AM, Max Pole <mailto:max_p...@gmx.de>> wrote:


Hi,

I hope it's the right mailing list for my question...

I'm trying to build opendjdk7 (bsd-port) in my PowerPC Mac. I
downloaded a right bootstrap VM and got platform-independent code
(corba, jaxp, jaxws etc) successfully compiled.

Unfortunately I cannot compile hotspot VM because of the
following error:

g++-4.0 -D_ALLBSD_SOURCE -D_GNU_SOURCE -DCC_INTERP -DZERO -DPPC
-DZERO_LIBARCH=\"ppc\" -DPRODUCT -I.
-I/Users/maxim/bsd-port/hotspot/src/share/vm/prims
-I/Users/maxim/bsd-port/hotspot/src/share/vm
-I/Users/maxim/bsd-port/hotspot/src/cpu/zero/vm
-I/Users/maxim/bsd-port/hotspot/src/os_cpu/bsd_zero/vm
-I/Users/maxim/bsd-port/hotspot/src/os/bsd/vm
-I/Users/maxim/bsd-port/hotspot/src/os/posix/vm -I../generated
-DHOTSPOT_RELEASE_VERSION="\"21.0-b17\""
-DHOTSPOT_BUILD_TARGET="\"product\""
-DHOTSPOT_BUILD_USER="\"maxim\"" -DHOTSPOT_LIB_ARCH=\"ppc\"
-DJRE_RELEASE_VERSION="\"1.7.0-internal-maxim_2011_07_09_02_30-b00\""
-DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_bsd
-DTARGET_ARCH_zero -DTARGET_ARCH_MODEL_zero
-DTARGET_OS_ARCH_bsd_zero -DTARGET_OS_ARCH_MODEL_bsd_zero
-DTARGET_COMPILER_gcc -I/usr/include/ffi -fPIC -fno-rtti
-fno-exceptions -pthread -fcheck-new -m32 -pipe -O3
-fno-strict-aliasing -I/usr/local/include -Werror -Wpointer-arith
-Wconversion -Wsign-compare-D_XOPE!
 N_SOURCE -D_DARWIN_C_SOURCE -c -MMD -MP -MF
../generated/dependencies/precompiled.hpp.gch.d -x c++-header
/Users/maxim/bsd-port/hotspot/src/share/vm/precompiled.hpp -o
precompiled.hpp.gch
In file included from
/Users/maxim/bsd-port/hotspot/src/share/vm/ci/ciMethod.hpp:33,
from
/Users/maxim/bsd-port/hotspot/src/share/vm/code/debugInfoRec.hpp:30,
from
/Users/maxim/bsd-port/hotspot/src/share/vm/ci/ciEnv.hpp:31,
from
/Users/maxim/bsd-port/hotspot/src/share/vm/ci/ciUtilities.hpp:28,
from
/Users/maxim/bsd-port/hotspot/src/share/vm/ci/ciNullObject.hpp:30,
from
/Users/maxim/bsd-port/hotspot/src/share/vm/ci/ciConstant.hpp:29,
from
/Users/maxim/bsd-port/hotspot/src/share/vm/precompiled.hpp:36:
/Users/maxim/bsd-port/hotspot/src/share/vm/prims/methodHandles.hpp:727:35:
error: methodHandles_zero.hpp: No such file or directory
make[6]: *** [precompiled.hpp.gch] Error 1
make[5]: *** [the_vm] Error 2
make[4]: *** [productzero] Error 2
make[3]: *** [generic_buildzero] Error 2
make[2]: *** [productzero] Error 2
make[1]: *** [hotspot-build] Error 2
make: *** [build_product_image] Error 2

-

The missing source is there but the complation script seems to be
unable to locate it.
Moreover, I found out that the platform-specific code (PPC in my
case) is NOT there! The directory

/Users/maxim/bsd-port/hotspot/src/cpu

doesn't contain any PPC-related code but only those for sparc,
x86 and zero. I have no idea what the latter means though...

My Question: Is PPC arch deprecated meanwhile? If not, what's the
reason to strip it out from the distribution?

Is there any possibility to obtain the PPC code for that VM?

Any help would be highly appreciated. I'm about to contribute to
a open-source project related on Java 1.6 but I cannot run that
software because Apple discontinued PPC macs, their support and
Java development for PPC. So openjdk is my only way to proceed...

Info on system I use:

Processor: PowerPC G5 2.1 GHz
System: Mac OS X 10.5.8

Best regards
Maxim Poliakovski
--
NEU: FreePhone - kostenlos mobil telefonieren!
Jetzt informieren: http://www.gmx.net/de/go/freephone




--
John Yeary
--
http://javaevangelist.blogspot.com
http://www.johnyeary.com
*@jyeary*

"Far better it is to dare mighty things, 

Re: Help me to build openjdk on my machine

[Paul Hohensee]

Hi Max and John,

Afaik, there's no support for PPC in openjdk.  Oracle has a private 
port, however,
for which the build framework exists in the open, which is why you can 
get a little

way in the build process.

zero is a psuedo-platform which should build and run on any machine 
because it
includes a platform-independent interpreter.  It should build and run on 
PPC.


Paul

On 7/10/11 11:41 AM, John Yeary wrote:

Hello Max,

I have not been able to get it to compile either and at this point no 
one has responded to my post about PPC. I am not sure if it will 
compile for our platform any more.


Does anyone have a successful recent build?

John

On Sun, Jul 10, 2011 at 6:11 AM, Max Pole > wrote:


Hi,

I hope it's the right mailing list for my question...

I'm trying to build opendjdk7 (bsd-port) in my PowerPC Mac. I
downloaded a right bootstrap VM and got platform-independent code
(corba, jaxp, jaxws etc) successfully compiled.

Unfortunately I cannot compile hotspot VM because of the following
error:

g++-4.0 -D_ALLBSD_SOURCE -D_GNU_SOURCE -DCC_INTERP -DZERO -DPPC
-DZERO_LIBARCH=\"ppc\" -DPRODUCT -I.
-I/Users/maxim/bsd-port/hotspot/src/share/vm/prims
-I/Users/maxim/bsd-port/hotspot/src/share/vm
-I/Users/maxim/bsd-port/hotspot/src/cpu/zero/vm
-I/Users/maxim/bsd-port/hotspot/src/os_cpu/bsd_zero/vm
-I/Users/maxim/bsd-port/hotspot/src/os/bsd/vm
-I/Users/maxim/bsd-port/hotspot/src/os/posix/vm -I../generated
-DHOTSPOT_RELEASE_VERSION="\"21.0-b17\""
-DHOTSPOT_BUILD_TARGET="\"product\""
-DHOTSPOT_BUILD_USER="\"maxim\"" -DHOTSPOT_LIB_ARCH=\"ppc\"
-DJRE_RELEASE_VERSION="\"1.7.0-internal-maxim_2011_07_09_02_30-b00\""
-DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_bsd
-DTARGET_ARCH_zero -DTARGET_ARCH_MODEL_zero
-DTARGET_OS_ARCH_bsd_zero -DTARGET_OS_ARCH_MODEL_bsd_zero
-DTARGET_COMPILER_gcc -I/usr/include/ffi -fPIC -fno-rtti
-fno-exceptions -pthread -fcheck-new -m32 -pipe -O3
-fno-strict-aliasing -I/usr/local/include -Werror -Wpointer-arith
-Wconversion -Wsign-compare-D_XOPE!
 N_SOURCE -D_DARWIN_C_SOURCE -c -MMD -MP -MF
../generated/dependencies/precompiled.hpp.gch.d -x c++-header
/Users/maxim/bsd-port/hotspot/src/share/vm/precompiled.hpp -o
precompiled.hpp.gch
In file included from
/Users/maxim/bsd-port/hotspot/src/share/vm/ci/ciMethod.hpp:33,
from
/Users/maxim/bsd-port/hotspot/src/share/vm/code/debugInfoRec.hpp:30,
from
/Users/maxim/bsd-port/hotspot/src/share/vm/ci/ciEnv.hpp:31,
from
/Users/maxim/bsd-port/hotspot/src/share/vm/ci/ciUtilities.hpp:28,
from
/Users/maxim/bsd-port/hotspot/src/share/vm/ci/ciNullObject.hpp:30,
from
/Users/maxim/bsd-port/hotspot/src/share/vm/ci/ciConstant.hpp:29,
from
/Users/maxim/bsd-port/hotspot/src/share/vm/precompiled.hpp:36:
/Users/maxim/bsd-port/hotspot/src/share/vm/prims/methodHandles.hpp:727:35:
error: methodHandles_zero.hpp: No such file or directory
make[6]: *** [precompiled.hpp.gch] Error 1
make[5]: *** [the_vm] Error 2
make[4]: *** [productzero] Error 2
make[3]: *** [generic_buildzero] Error 2
make[2]: *** [productzero] Error 2
make[1]: *** [hotspot-build] Error 2
make: *** [build_product_image] Error 2

-

The missing source is there but the complation script seems to be
unable to locate it.
Moreover, I found out that the platform-specific code (PPC in my
case) is NOT there! The directory

/Users/maxim/bsd-port/hotspot/src/cpu

doesn't contain any PPC-related code but only those for sparc, x86
and zero. I have no idea what the latter means though...

My Question: Is PPC arch deprecated meanwhile? If not, what's the
reason to strip it out from the distribution?

Is there any possibility to obtain the PPC code for that VM?

Any help would be highly appreciated. I'm about to contribute to a
open-source project related on Java 1.6 but I cannot run that
software because Apple discontinued PPC macs, their support and
Java development for PPC. So openjdk is my only way to proceed...

Info on system I use:

Processor: PowerPC G5 2.1 GHz
System: Mac OS X 10.5.8

Best regards
Maxim Poliakovski
--
NEU: FreePhone - kostenlos mobil telefonieren!
Jetzt informieren: http://www.gmx.net/de/go/freephone




--
John Yeary
--
http://javaevangelist.blogspot.com
http://www.johnyeary.com
*@jyeary*

"Far better it is to dare mighty things, to win glorious triumphs, 
even though checkered by failure, than to take rank with those poor 
spirits who neither enjoy much nor suffer much, because they live in 
the gray twilight that knows not victory nor defeat."

-- Theodore Roosevelt

Re: JDK8 Preliminary Repository Layout

[Paul Hohensee]

We could rename 'closed' to be 'oracle'.  You could then have the oracle 
build

be the common code plus the 'oracle' repo.  Add an 'icedtea' repo and you
could have the icedtea build be the common code plus the 'icedtea' 
repo.  Etc.,

for other versions/vendors.

Paul

On 3/9/11 7:48 PM, Dr Andrew John Hughes wrote:

On 18:32 Tue 08 Mar , Kelly O'Hair wrote:

First, if we talk about the mercurial forests, it has nothing to do with the 
Mercurial Forest Extension.
What we really have is a set of nested repositories, sometimes called our 
"forest" of repositories.

This email is just about the actual layout of the repositories for jdk8.

The initial thinking at this time is that the openjdk8 open forest will look 
very much like openjdk7:

openjdk8/
 corba/
 jaxp/
 jaxws/
 jdk/
 hotspot/
 langtools/

7 repositories total. Cloned from the openjdk7 repos so we will have all the 
openjdk7 history in the openjdk8 repositories.

Just for discussion sake, not that you can see what is behind the closed 
curtains, we are considering changing
the closed overlay a little, from the current jdk7 (bold is a closed repo):

   jdk7/
 corba/
 deploy/
 jaxp/
 jaxws/
 jdk/
   src/closed/
   test/closed
   make/closed/
 hotspot/
   src/closed/
   test/closed
 install/
 langtools/
 pubs/

To something a little simplier like:

   jdk8/
 corba/
 deploy/
 jaxp/
 jaxws/
 jdk/
   closed/{src,test,make}
 hotspot/
   closed/{src,test,make}
 install/
 langtools/
 pubs/

The existence of these closed repos should not be a surprise, and it should 
have no impact on the openjdk itself.
We are just trying to consolidate and have fewer repositories. Just thought it 
might be of interest.


Not surprised.  Also don't really care where you put them as I don't seem to 
have them either way ;-)

What I would ask is do the projects get this as well?  Specifially, I'd like an 
icedtea/jdk8 at the same time please.


But back to the openjdk8 forest.

Other ideas were considered:
   * Folding jaxp/jaxws into the root or jdk8/jdk repo

Sounds good.  jdk8/jdk would make more sense as jaxws depends on some classes 
that are in the jdk
tree (com.sun.net.httpserver) and we could then get rid of the Ant junk.  It 
would be good to have
the code there too so we can once again track changes.  The recent security 
issue was a nightmare
due to the unavailability of the source code.


   * Separating out the jdk demos from the jdk repo to a separate "demos" 
repository

Makes sense.  Having an option to disable them would be a good first step.


   * Separating out the client (awt/swing/etc) code from the jdk repo into a 
separate repo

Why would we want to do this?  IME, there are lots of interdependencies with 
the other code and
this would make the build a nightmare.


   * Updating the corba sources changing it to an ant build

Please, no!  These Ant builds are already a nightmare and an order of magniture 
harder to debug than
the Makefiles.  Why you want to require a build system that requires an entire 
JDK setup (possibly
bringing another into the mix beyond the bootstrap JDK) is beyond me.

What would make much more sense is to just add corba into the jdk tree.  It 
actually requires sun.tools
classes to compile rmic anyway so it would make much more sense there.

Hey, I'd just make it all one repository as they all interdepend on each other, 
but the HotSpot folks
probably wouldn't like that... ;-)   Moving the HotSpot servicability agent 
into the JDK, where the
interfaces it uses lives, might be a good idea though.  I'm currently working 
on a patch which fixes
up a mismatch between the HotSpot SA implementation and the interfaces in the 
JDK which has existed
for who knows how long (it's certainly in OpenJDK6)...


None of this seemed urgent to do out of the gate, or delay getting a 
preliminary jdk8 layout defined.


No, I agree with that.  Splitting off OpenJDK8 already seems overdue.


I know there is some interest in pulling the actual jaxp/jaxws sources back 
into their repos, that will
be discussed separately, we have multiple issues with that, but I am well aware 
of the pains that the
source drop zip files have created.


The problem is less technical and more social; there is no obvious way to 
interact with the JAXP and JAXWS
side of things.  We just get these zips of code with no idea of what changes 
are in there or why.

Basically, they shouldn't work either like they do now or did before, but like 
everything else in OpenJDK
with visible commits.  Hey, maybe we could even have some mailing list 
discussion if we're very lucky...


As always, we would like to get comments, or additional ideas.

Separate topics:
   * Forest Extension and it's replacement

Do we really need one?  Current status quo (get_source.sh) works fine.


   * Mercurial server update to 1.8 or newer

I guess this is related to the 

Re: Glitch in Hotspot i486.make

[Paul Hohensee]

Hard to say.  Could be subtle bugs lurking.

Paul

David Holmes - Sun Microsystems wrote:

FYI, I just opened CR 6767659

*Synopsis*: Conversion from i486 to x86 missed some entries in i486.make

=== *Description* 


In make/solaris/makefiles/i486.make we have:

# _lwp_create_interpose must have a frame
OPT_CFLAGS/os_solaris_i486.o = -xO1
# force C++ interpreter to be full optimization
OPT_CFLAGS/interpret.o = -fast -O4
else

ifeq ("${Platform_compiler}", "gcc")
# gcc
# _lwp_create_interpose must have a frame
OPT_CFLAGS/os_solaris_i486.o = -fno-omit-frame-pointer

but os_solaris_i486 is now os_solaris_x86



I guess those flag modifications are either redundant (covered 
elsewhere) or simply not needed ?


David Holmes
Senior Java Technologist
Java SE Real-Time & Embedded Group
--

Re: RFC: architecture define probably masks variable names in header files

[Paul Hohensee]

Actually, I recall that one of the things we've always wanted to
do is get rid of HPI.  Never seems to be important enough.

Paul

Kelly O'Hair wrote:

If it's not used, I say OFF WITH IT"S HEAD!  ;^)

-kto


Alan Bateman wrote:

Kelly O'Hair wrote:
I very much suspect that this -D$(ARCH) could be removed with no 
consequences.

The difficult part would be verifying it.

C macros are a very powerful tool, but some of the global names we 
have chosen


over the years have come back to haunt us. :^( 
src/solaris/hpi/native_threads is one place that seems to depend on 
$(ARCH) being defined. That code is part of the HPI "Thread" 
interface. As I recall, HotSpot doesn't use the HPI's "Thread" or 
"Memory" interfaces and so this code probably hasn't been used since 
the transition to HotSpot back in 1.3.


-Alan.

Re: how to build 32-bit openjdk7 on x86_64

[Paul Hohensee]

Actually, you can build 32-bit linux hotspot standalone on a 64-bit 
system, but
you can't build a 32-bit linux jdk (that happens to include a hotspot 
build) on

a 64-bit system.

To build a 32-bit linux hotspot standalone, go to the build/linux
directory in the hotspot workspace, set ALT_BOOTDIR to a 32-bit boot 
jdk, put

$ALT_BOOTDIR/bin on your PATH and issue 'make product', or whatever
flavor of build you want.  To build a 64-bit linux hotspot, set ALT_BOOTDIR
to a 64-bit boot jdk, etc., and issue 'make LP64=1 product', etc.

Paul

Stephen Bohne wrote:

Ben Cheng wrote:

Hi Folks,

I am trying to build 32-bit openjdk7 from source under control/make, 
but I seem to have endless troubles picking up the right ARCH option. 
The source code is from the b23 snapshot.


I started with

make ARCH_DATA_MODEL=32 ALT_BOOTDIR=/usr/lib/jvm/java-6-sun 
ANT_HOME= FINDBUGS_HOME=


It quickly failed with the following error:

[ gcc command neglected]
...
-ljvm  -L/usr/lib/jvm/java-6-sun/jre/lib/amd64 -ljava 
-L/usr/lib/jvm/java-6-sun/jre/lib/amd64/server -ljvm -lc

/usr/bin/ld: cannot find -ljvm

because there is no amd64 under /usr/lib/jvm/java-6-sun/jre/lib but 
only i386, and without specifying ARCH the makefile relies on "uname 
-m" to guess the ARCH, and it chooses amd64 when seeing x86_64.


So I tried to add ARCH=i386 in the command line. The build goes past 
the previous stage, but sees a different in building 
corba/make/javax/xa:


/bin/sh: line 5: Check_ALT_JDK_IMPORT_PATH/bin/javac: No such file or 
directory


This problem is slightly off topic, as it seems to require adding 
ALT_JDK_IMPORT_PATH to the command-line even my intention is to do a 
complete build. Although I still don't know why it is necessary, 
adding ALT_JDK_IMPORT_PATH=$ALT_BOOTDIR gets me past corba, but the 
builds stalls at hotspot:



make[6]: *** No rule to make target 
`openjdk/v1_7/hotspot/src/cpu/i386/vm/x86_32.ad', needed by 
`../generated/adfiles/linux_x86_32.ad'.  Stop.


Apparenly hotspot doesn't like ARCH=i386 but prefers ARCH=x86, and I 
found a place to hack in hotspot/build/linux/Makefile, where I 
override ARCH=$(SRCARCH) in the following context:


$(TARGETS_C2):  $(SUBDIRS_C2)
cd $(OSNAME)_$(BUILDARCH)_compiler2/$@ && $(MAKE) $(MFLAGS) 
ARCH=$(SRCARCH)


Then, the next error shows up in exporting jvmti.html, where I need 
to add the following rule in hotspot/build/linux/makefiles

/defs.make if I define ARCH as i386:

ifeq ($(ARCH), i386)
  ARCH_DATA_MODEL  = 32
  PLATFORM = linux-i586
  VM_PLATFORM  = linux_i486
  HS_ARCH  = x86
endif

There is a similar patch for i586 so I suspect people tried to build 
hotspot with ARCH=i686 and ran into similar errors.


Well, this is not the end of errors, as the next one shows up in 
jdk/make/java/jli, where it fails to locate ergo_i386.c because only 
the following two variants are available:


jdk/src/solaris/bin/ergo_i586.c
jdk/src/solaris/bin/ergo_sparc.c

In summary, my questions can be condensed into two:

1) Is control/make the right place to build everything from source. 
If so, why is ALT_JDK_IMPORT_PATH needed in the make command line?
2) What is the ARCH value applicable to all modules if the goal is to 
build 32-bit package on x86_64 platform?


I don't think (2) is supported, at least for the HotSpot workspace.  
You have to build 32-bit on a 32-bit platform.  Yes, the build could 
be more flexible here.  Patches are welcome. :)


Don't know the answer to (1), sorry.

Steve


Thanks,
-Ben

webrev accessibility

[Paul Hohensee]

I'm not sure this is the right list to ask this question, but here it is.

When we at Sun put out requests for code reviews, we include a URL for
what we call a 'webrev', which provides several different kinds of
view of the change, including simple diffs, a patch file and different
forms of annotated html.  We're going to make the script that generates
a webrev (also called 'webrev') generally available.

My question is, where can we store webrevs so they're accessible to
the community, and what's the process for putting them there?

Paul