Re: Can not build jdk10 under Solaris 11

[Gary Adams]

With jdk10 repos you should be using solstudio 12.4.
The changes were added to jdk11 repos to begin support
for solstudio 12.6, but there are some additional patches
needed in solstudio 12.6 to be able to build openjdk.
Hopefully those issues will be resolved for the next jdk release.

On 9/5/18, 11:26 AM, Andrew Watkins wrote:

Hello,

I am sure I am doing something wrong, but having build problems with 
OpenJDK under Solaris.


Error:
# gmake
Building target 'default (exploded-image)' in configuration 
'solaris-x86_64-normal-server-release'

Creating support/modules_libs/java.base/libjsig.so from 1 file(s)
Compiling 8 files for BUILD_TOOLS_LANGTOOLS
Creating hotspot/variant-server/tools/adlc/adlc from 13 file(s)
Compiling 2 files for BUILD_JVMTI_TOOLS
"/var/tmp/jdk10/hotspot/src/share/vm/adlc/arena.cpp", line 60: Error, 
placementdelmatch: Placement operator new refers to non-placement 
operator delete.
"/var/tmp/jdk10/hotspot/src/share/vm/adlc/arena.cpp", line 67: Error, 
placementdelmatch: Placement operator new refers to non-placement 
operator delete.
"/var/tmp/jdk10/hotspot/src/share/vm/adlc/arena.cpp", line 97: Error, 
placementdelmatch: Placement operator new refers to non-placement 
operator delete.

3 Error(s) detected.
gmake[3]: *** 
[/var/tmp/jdk10/build/solaris-x86_64-normal-server-release/hotspot/variant-server/tools/adlc/objs/arena.o] 
Error 2

gmake[3]: *** Waiting for unfinished jobs




I can see that there is a bug 8199782 with fixes 
http://hg.openjdk.java.net/jdk/jdk/rev/fa26e7c6efb7, but these fixes 
are not in my version? Am I missing a step to get the right jdk10 
software?


I tried manually altering the code and got further but no point 
discussing that until I know I am pulling the right code down from 
openjdk.


Full steps:

# export 
PATH=/opt/developerstudio/bin:/usr/bin:/usr/sbin:/usr/gnu/bin:/usr/sfw/bin

# hg clone http://hg.openjdk.java.net/jdk10/jdk10
# cd jdk10
# bash get_source.sh
# Repositories:  corba jaxp jaxws langtools jdk hotspot nashorn
 jaxp:   hg clone 
http://hg.openjdk.java.net/jdk10/jdk10/jaxp jaxp
corba:   hg clone 
http://hg.openjdk.java.net/jdk10/jdk10/corba corba

 jaxp:   requesting all changes
corba:   requesting all changes
corba:   adding changesets
 jaxp:   adding changesets
corba:   adding manifests
 jaxp:   adding manifests
corba:   adding file changes
corba:   added 925 changesets with 5504 changes to 
2597 files

corba:   updating to branch default
corba:   1201 files updated, 0 files merged, 0 files 
removed, 0 files unresolved
jaxws:   hg clone 
http://hg.openjdk.java.net/jdk10/jdk10/jaxws jaxws

jaxws:   requesting all changes
jaxws:   adding changesets
jaxws:   adding manifests
 jaxp:   adding file changes
 jaxp:   added 1217 changesets with 15333 changes to 
8488 files

 jaxp:   updating to branch default
 jaxp:   3343 files updated, 0 files merged, 0 files 
removed, 0 files unresolved
langtools:   hg clone 
http://hg.openjdk.java.net/jdk10/jdk10/langtools langtools

langtools:   requesting all changes
langtools:   adding changesets
jaxws:   adding file changes
jaxws:   added 850 changesets with 21898 changes to 
10824 files

jaxws:   updating to branch default
jaxws:   3757 files updated, 0 files merged, 0 files 
removed, 0 files unresolved
  jdk:   hg clone 
http://hg.openjdk.java.net/jdk10/jdk10/jdk jdk

  jdk:   requesting all changes
langtools:   adding manifests
  jdk:   adding changesets
   langtools:   adding file changes
langtools:   added 4297 changesets with 38693 changes to 
11923 files

langtools:   updating to branch default
langtools:   8702 files updated, 0 files merged, 0 files 
removed, 0 files unresolved
  hotspot:   hg clone 
http://hg.openjdk.java.net/jdk10/jdk10/hotspot hotspot

  hotspot:   requesting all changes
  hotspot:   adding changesets
  hotspot:   adding manifests
  jdk:   adding manifests
  hotspot:   adding file changes
  hotspot:   added 13550 changesets with 85505 changes to 
16280 files

  hotspot:   updating to branch default
  hotspot:   9230 files updated, 0 files merged, 0 files 
removed, 0 files unresolved
  nashorn:   hg clone 
http://hg.openjdk.java.net/jdk10/jdk10/nashorn nashorn

  nashorn:   requesting all changes
  nashorn:   adding changesets
  nashorn:   adding manifests
  nashorn:   adding file 

Re: RFR: 8201360: Zero fails to build on linux-sparc after 8201236

[Gary Adams]

Is any update needed for EXTRA_OBJECT_FILES?

On 4/10/18, 2:32 PM, Erik Joelsson wrote:

Looks good.

/Erik


On 2018-04-10 11:22, John Paul Adrian Glaubitz wrote:

Hi!

Please review this minor change which fixes the Zero build on 
linux-sparc

which got broken after "JDK-8201236 Straighten out dtrace build logic".

The change affects the Zero build on linux-sparc only since SPARC has 
its

own implementation of memset_with_concurrent_readers() in memset_with_\
concurrent_readers_sparc.cpp which needs to be added to $(EXTRA_FILES)
by adding $(BUILD_LIBJVM_EXTRA_FILES) to $(EXTRA_FILES).

Thanks,
Adrian


[1] http://cr.openjdk.java.net/~glaubitz/8201360/webrev.00/

RFR: JDK-8199782: Fix compilation warnings detected by Solaris Developer Studio 12.6

[Gary Adams]

Getting the sources ready for the next Solaris developer studio toolchain.

  Issue: https://bugs.openjdk.java.net/browse/JDK-8199782
  Webrev: http://cr.openjdk.java.net/~gadams/8199782/webrev.00/

This update conditionally disables some new error checks, if the
new toolchain is used.

Re: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()

[Gary Adams]

One more to fix to cover the remaining test failures I was seeing.

Previously, using inet_addr, there was a single -1 return that needed to 
be checked.
Now that we're using inet_pton, there is a -1 and a 0 error return to be 
considered.


My preference would be to leave the dbgSysInetAddr name unchanged and 
have the low level
check for inet_pton errors to simply return the -1 that was previously 
checked.


This specific issue is about the deprecation of library functions on 
windows. I'd recommend not
upgrading the other platforms at this time until a complete update is 
done for ipv6 support.


I'll post a new webrev when I've retested using the updated inet_pton 
error checking.


...

Hi Gary,


>/  Here's a revised webrev
/>/
/>/ http://cr.openjdk.java.net/~gadams/8080990/webrev.01/index.html  

/>/
/>/  Still testing ...
/>/
/>/  Using shutdown() fixed problems reported by the
/>/  java/nio/channelSocketChannel tests.
/
The fix looks good. I would think we should rename dbgsysInetAddr to dbgsysPToN 
and use inet_pton also for the Unix/Linux platforms. It would be the better 
choice there as well, though we still only support IPv4 in libdt_socket.

>/
/>/  I also noticed prior use of getaddrinfo for "localhost" was not calling
/>/  freeaddrinfo.
/
Thanks for spotting/fixing that.

Best regards
Christoph

Re: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()

[Gary Adams]

Here's a revised webrev

  http://cr.openjdk.java.net/~gadams/8080990/webrev.01/index.html

Still testing ...

Using shutdown() fixed problems reported by the 
java/nio/channelSocketChannel tests.


I also noticed prior use of getaddrinfo for "localhost" was not calling 
freeaddrinfo.


...

On 2/1/18, 6:16 AM, gary.ad...@oracle.com wrote:

First pass over the code I disabled the compilation flag and then
did quick substitution for the easier functions. I commented out the
WSASendDisconnect calls so I could see what tests would fail if
the function was just removed. I have a replacement now that uses
"shutdown(fd,SD_SEND)", but I still have a few more test failures to
investigate.

I updated the error message text for "getaddrinfo".

I'll post a revised webrev after the 4 jshell errors are corrected.


On 2/1/18 3:11 AM, Langer, Christoph wrote:

Hi Gary,

I was having a look at your changes.

I'm wondering what the reason is behind uncommenting 
WSASendDisconnect in Java_sun_nio_ch_SocketDispatcher_preClose0 of 
file SocketDispatcher.c? And in dbgsysSocketClose?


In socketTransport.c, line:
 331 setLastError(0, "gethostbyname: unknown host");
you should change the description text of the error to getaddrinfo 
instead of gethostbyname.


Best regards
Christoph



-Original Message-
From: build-dev [mailto:build-dev-boun...@openjdk.java.net] On Behalf 
Of Gary Adams

Sent: Donnerstag, 25. Januar 2018 19:47
To: OpenJDK Serviceability <serviceability-...@openjdk.java.net>; 
OpenJDK Build <build-dev@openjdk.java.net>; OpenJDK Networking 
<net-...@openjdk.java.net>
Subject: RFR: JDK-8080990: libdt_socket/socket_md.c(202) : warning 
C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()


Here's a first pass attempt to remove the 
-D_WINSOCK_DEPRECATED_NO_WARNINGS

build flag and update the winsock deprecated functions.

Issue: https://bugs.openjdk.java.net/browse/JDK-8080990
Webrev: http://cr.openjdk.java.net/~gadams/8080990/

These are the initial deprecated functions updated:
 gethostbyname -> getaddrinfo
 inet_addr -> inet_pton
 inet_ntoa -> inet_ntop

I'm not sure how to replace the existing WSASendDisconnect calls.
It's not clear that it actually provides a graceful disconnect.

Re: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()

[Gary Adams]

On 2/1/18, 6:59 AM, Langer, Christoph wrote:

But WSASendDisconnect isn't deprecated, right? So you wanted to get rid of it? 
I still don't see the reason...

vs2013 include/um/winsock2.h has WSASendDisconnect deprecated.

.../src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c(230) : 
error C2220: warning treated as error - no 'object' file generated
.../src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c(230) : 
warning C4996: 'WSASendDisconnect': Use WSASend() instead or define 
_WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated API warnings

RFR: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()

[Gary Adams]

Here's a first pass attempt to remove the -D_WINSOCK_DEPRECATED_NO_WARNINGS
build flag and update the winsock deprecated functions.

  Issue: https://bugs.openjdk.java.net/browse/JDK-8080990
  Webrev: http://cr.openjdk.java.net/~gadams/8080990/

These are the initial deprecated functions updated:
   gethostbyname -> getaddrinfo
   inet_addr -> inet_pton
   inet_ntoa -> inet_ntop

I'm not sure how to replace the existing WSASendDisconnect calls.
It's not clear that it actually provides a graceful disconnect.

Re: CompileJavaModule.gmk overrides values from a custom extension gmk

[Gary Adams]

Is the expectation that all of the := will be changed to += for these 
variables?


 468 jdk.internal.vm.ci_ADD_JAVAC_FLAGS := -parameters -Xlint:-exports 
-XDstringConcat=inline

Do the closed makefiles also need to be updated?

On 8/30/17, 10:36 AM, Erik Joelsson wrote:

Hello Jason,

I took the liberty of creating an issue for this: 
https://bugs.openjdk.java.net/browse/JDK-8186983


The mailing list server removes attachments. This makes it difficult 
for new people to send in their patches until they have an openjdk 
user so they can upload to cr.openjdk.java.net. Since you addressed 
the mail directly to me as well, I received the attachment and have 
created a webrev from it here:


http://cr.openjdk.java.net/~erikj/8186983/webrev.01/

I think the patch looks good now, but will leave it here until 
tomorrow to give other reviewers a chance to look at.


/Erik


On 2017-08-30 16:20, Jason Yong wrote:

Hi Eric,

I've removed the SETUP changes as requested...



On a side note, I noticed that the attachment got stripped out in the 
post

to the mailing list. Should I actually be copying and pasting the entire
diff in the message? Its a couple of hundred lines... or is somewhere to
put the attachment?


Regards,

Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom





From:   Erik Joelsson 
To: Jason Yong 
Cc: build-dev@openjdk.java.net
Date:   30/08/2017 14:43
Subject:Re: CompileJavaModule.gmk overrides values from a custom
extension gmk



Hello,

Changing the assignment on COPY, CLEAN and FLAGS variables makes sense,
but please revert the SETUP variables as those are not lists but single
value types.

Otherwise this looks good to me.

/Erik


On 2017-08-30 15:37, Jason Yong wrote:

Hi Eric,

With regards to the OCA I believe IBM has signed a contributors

agreement

which should cover me for that.


So here's the mercurial export of the CompileJavaModule.java with my
changes in




Regards,


Jason Yong

CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom





From:   Erik Joelsson 
To: Jason Yong 
Cc: build-dev@openjdk.java.net
Date:   30/08/2017 13:47
Subject:Re: CompileJavaModule.gmk overrides values from a 
custom

extension gmk



If you have signed the OCA, you can post your proposed change here 
and I

or someone else will sponsor it once we agree that it looks good.
/Erik

On 2017-08-30 14:27, Jason Yong wrote:
Thanks Eric,

Is the next step is to get a sponsor for the change or should I post my
proposed change first?

Jason

Regards,

Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtimes Technology
IBM Hybrid Cloud


Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:


Hursley Park
Hursley, SO212JN
United Kingdom






From:Erik Joelsson 
To:Jason Yong ,

build-dev@openjdk.java.net

Date:29/08/2017 12:55
Subject:Re: CompileJavaModule.gmk overrides values from a 
custom

extension gmk



Hello Jason,

Your suggestion makes sense. The only reason these variables have :=
today is that we (at Oracle) haven't had a need for appending to those
particular variables (yet).

/Erik


On 2017-08-29 11:31, Jason Yong wrote:

Hello,

I've had an issue where I've had a custom extension to

CompileJavaModules.gmk with the variable java.base_COPY set to files

that

I wanted to be copied across but its value was overwritten by
CompileJavaModules.gmk.
I would like to propose changes that would allow a custom 
extensions to
update variables listed in CompileJavaModules.gmk. This issue is 
similar

to bug JDK-8064372 (

https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8064372=DwICaQ=jf_iaSHvJObTbx-siA1ZOg=_pd0JudnAMtzyOP3NkOCP7ozDRbZ9ukki8lLmogKLJI=qG_YEjgXnzBfNvN5ztSbjIVP3nZ5SaZCibl7SHJjTfc=2mMmeC6jKTJu1OgK0Lssib1LKQvOFX3BwzIcJAebSeU= 




) but affects all the other variables such as:

java.activation_SETUP
java.base_ADD_JAVAC_FLAGS
java.base_COPY
java.base_CLEAN
etc

The fix is also similar, changing := to += allowing the custom

extension

to append to the variable if already set and create it if its not.

I would appreciate any feedback and help on what the next steps would

be.

Thanks

Jason


Jason Yong
CEng MEng MIET
Software Engineer, IBM Runtime Technologies
IBM Hybrid Cloud
Phone: 44-1962-815256
E-mail: yon...@uk.ibm.com
Find me on:  and within IBM on:
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with

number

741598.

Registered office: PO Box 41, North Harbour, 

RFR: JDK-8165946: buildjdk logic is incomplete when separate sysroots needed

[Gary Adams]

When the buildjdk logic was added to the jdk9 build system, it did not 
completely
cover the use cases required in the mobile/dev builds. We have been 
working around
this issue using a prebuilt macosx buildjdk with the --with-build-jdk 
autoconf option.
This is an awkward workaround, because the buildjdk had to be new enough 
to match the
requirements of the repos being built. e.g. jdk9 b132 included some 
newer command line

option in the jmod and jlink command build step.

This fix is a more permanent solution adding a --with-build-sysroot 
option to allow
an explicit reference to the sysroot to use on the build system. A 
similar call already exists

when --with-devkit and --with-build-devkit are used.

   JIRA: https://bugs.openjdk.java.net/browse/JDK-8165946
   Webrev: http://cr.openjdk.java.net/~gadams/8165946/wevrev.00/

This is an interim fix in the mobile/dev repos. Many of the platform 
specific checks will need to

be addressed before they can be targeted for the mainstream repos.

Here's an example of how this would be used for an ios-arm64 build :


export 
IOS_SDK_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk
export 
MACOSX_SDK_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk

...
configure \
...
--with-sys-root=${IOS_SDK_PATH} \
--with-build-sysroot=${MACOSX_SDK_PATH}

Re: RFR: 8151630 and 8151631 ios build failures after b106 merge

[Gary Adams]

A minor problem arises when we eliminate the last cmd from the ios build.
When making images the support/modules_cmds-stripped is passed to the
jimage tool, but the directory is not created if no cmds were processed.

This will be a moot issue once the jigsaw integration is complete. In 
the interim,

here is a workaround I'd like to add that gets past the problem.

diff --git a/make/Images.gmk b/make/Images.gmk
--- a/make/Images.gmk
+++ b/make/Images.gmk
@@ -121,6 +121,7 @@
 $(call DependOnVariable, JDK_MODULES_LIST)
 $(ECHO) Creating jdk jimage
 $(RM) -r $(JDK_IMAGE_DIR) $(JDK_SORTED_MODULES)
+$(call MakeDir, $(MODULES_CMDS))
 $(JIMAGE_TOOL) --mods $(JDK_MODULES_LIST) --output $(JDK_IMAGE_DIR) \
 $(MODULES_XML) > $(JDK_SORTED_MODULES)
 $(TOUCH) $@
@@ -129,6 +130,7 @@
 $(call DependOnVariable, JRE_MODULES_LIST)
 $(ECHO) Creating jre jimage
 $(RM) -r $(JRE_IMAGE_DIR) $(JRE_SORTED_MODULES)
+$(call MakeDir, $(MODULES_CMDS))
 $(JIMAGE_TOOL) --mods $(JRE_MODULES_LIST) --output $(JRE_IMAGE_DIR) \
 $(MODULES_XML) > $(JRE_SORTED_MODULES)
 $(TOUCH) $@

On 03/10/16 12:12, Erik Joelsson wrote:

Looks ok for now.

/Erik

On 2016-03-10 17:43, Gary Adams wrote:

Here are two quick fixes for ios build issues after the b106 merge

A quick workaround for the ios build issue with upack executable is 
to noop
the launcher makefile, similar to what has been done for other 
launcher makefiles.
A longer term solution will be added later with a proper configure 
flag to disable

building command line launchers.

The ios-arm64 (aka aarch64 zero vm) needs template files for 
UnixConstants
and SocketOptionRegistry. It was using the ios-arm templates. Rather 
than

complicate the makefiles the ios-arm files have been cloned.

  Webrev: http://cr.openjdk.java.net/~gadams/8151631/webrev.00/
   JIRA:
https://bugs.openjdk.java.net/browse/JDK-8151630?filter=-1
https://bugs.openjdk.java.net/browse/JDK-8151631?filter=-1

RFR: 8151630 and 8151631 ios build failures after b106 merge

[Gary Adams]

Here are two quick fixes for ios build issues after the b106 merge

A quick workaround for the ios build issue with upack executable is to noop
the launcher makefile, similar to what has been done for other launcher 
makefiles.
A longer term solution will be added later with a proper configure flag 
to disable

building command line launchers.

The ios-arm64 (aka aarch64 zero vm) needs template files for UnixConstants
and SocketOptionRegistry. It was using the ios-arm templates. Rather than
complicate the makefiles the ios-arm files have been cloned.

  Webrev: http://cr.openjdk.java.net/~gadams/8151631/webrev.00/
   JIRA:
   https://bugs.openjdk.java.net/browse/JDK-8151630?filter=-1
   https://bugs.openjdk.java.net/browse/JDK-8151631?filter=-1

RFR: JDK-8151402: Allow template files from closed and open repos

[Gary Adams]

Here is the proposed update to the GensrcMisc.gmk makefile.

If a closed repos makefile is present, let it provide an alternate 
closed location for
the template files. If it does not exist attempt to use the template 
from the open repos

location.

This change will allow the template files to be located in closed or 
open repos as needed

by the target cross compilation platform.


diff --git a/make/gensrc/GensrcMisc.gmk b/make/gensrc/GensrcMisc.gmk
--- a/make/gensrc/GensrcMisc.gmk
+++ b/make/gensrc/GensrcMisc.gmk
@@ -22,6 +22,7 @@
 # or visit www.oracle.com if you need additional information or have any
 # questions.
 #
+$(eval $(call IncludeCustomExtension, jdk, gensrc/GensrcMisc.gmk))

 
##
 # Install the launcher name, release version string, full version
@@ -58,7 +59,9 @@
 OUTPUT_DIR := $(GENSRC_SOR_BIN), \
 PROGRAM := genSocketOptionRegistry))

-SOR_PREGEN_FILE := 
$(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/classes/sun/nio/ch/SocketOptionRegistry-$(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU_ARCH).java.template

+ifeq ($(wildcard $(SOR_PREGEN_FILE)), )
+  SOR_PREGEN_FILE := 
$(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/classes/sun/nio/ch/SocketOptionRegistry-$(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU_ARCH).java.template

+endif

 ifeq ($(wildcard $(SOR_PREGEN_FILE)), )
$(SUPPORT_OUTPUTDIR)/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java: 
$(BUILD_GENSRC_SOR_EXE)

@@ -94,7 +97,9 @@
   OUTPUT_DIR := $(GENSRC_UC_BIN), \
   PROGRAM := genUnixConstants))

-  UC_PREGEN_FILE := 
$(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/classes/sun/nio/fs/UnixConstants-$(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU_ARCH).java.template

+  ifeq ($(wildcard $(UC_PREGEN_FILE)), )
+UC_PREGEN_FILE := 
$(JDK_TOPDIR)/src/java.base/$(OPENJDK_TARGET_OS)/classes/sun/nio/fs/UnixConstants-$(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU_ARCH).java.template

+  endif

   ifeq ($(wildcard $(UC_PREGEN_FILE)), )
$(SUPPORT_OUTPUTDIR)/gensrc/java.base/sun/nio/fs/UnixConstants.java: 
$(BUILD_GENSRC_UC_EXE)

Re: RFR: JDK-8150257 Remove softfloat lib support

[Gary Adams]

As far as I know the only build that uses the sflt libs is the legacy armv5 
linux systems.

http://closedjdk.us.oracle.com/ejdk9/dev/closed/file/a2055fab159f/bin/build-embedded.csh#l331
...
  # ARMv5t, non-thumb, soft-float emulation, soft-float ABI
  case linux-arm-sflt:
set JVM_VARIANT = "--with-jvm-variants=client,minimal1"
set DEVKIT = --with-devkit=$TOOLKIT_ROOT/gcc/linux/arm/arm-linaro-4.7
set X11KIT = 
--with-x=$TOOLKIT_ROOT/gcc/linux/arm/arm-linaro-4.7/arm-linux-gnueabi/libc/usr/X11R6
set SFLT_LIB_PATH = --with-sflt-lib-path=$TOOLKIT_ROOT/gcc/linux/arm/ext
set CROSS_COMPILE_ARCH = --openjdk-target=arm-linux-gnueabi
set ABI_PROFILE = --with-abi-profile=arm-sflt
breaksw



On 02/21/16 18:23, David Holmes wrote:

Hi Magnus,

On 20/02/2016 2:09 AM, Magnus Ihse Bursie wrote:

We have some quite ugly hacks in place to support injecting the
softfloat lib on certain platforms. This is not needed anymore and
should be removed.


Is this no longer relevant to the iOS-arm build in mobile-dev? They 
will need to add this back if they still need it, but perhaps in a 
cleaner way.


Otherwise removal looks good.

Thanks,
David


Bug: https://bugs.openjdk.java.net/browse/JDK-8150257
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8150257-remove-softfloat-lib-support/webrev.01 




/Magnus

RFR: 8148361: Need to disable the thread local storage compiler option for ios

[Gary Adams]

When the sync with jdk9 b102 was pulled into mobile/dev repos a new
feature for thread local storage was over looked. Most modern compilers
include support for thread local declaration, but this feature is 
intentionally

not supported by Apple's clang compiler.

This change declares USE_LIBRARY_BASED_TLS_ONLY along with other
TARGET_OS_IPHONE declarations in the hotspot globalDefinitions_gcc.hpp file.

  Issue: https://bugs.openjdk.java.net/browse/JDK-8148361
  Webrev: http://cr.openjdk.java.net/~gadams/8148361/webrev.00/

Re: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds.

[Gary Adams]

On 01/12/16 02:30, David Holmes wrote:

Hi Gary,

I mainly looked at the hotspot files, but not everything in detail. 
Some issues will change when this sync's up with mainline again.


Overall a lot of things making me cringe.

Cheers,
David

---

hotspot/make/Makefile

Isn't a JIT-less VM a ZERO build? Otherwise if we really want CORE 
then we should make CORE work.


I'll leave the zero versus core vm question to Bob.
If I recall correctly neither was being maintained
and tested on a regular basis, and the zero only required
minimal updates to get up and running on ios platform.



---

hotspot/make/bsd/makefiles/dtrace.make

Please make sure the comments are updated to reflect the code eg:

  27 # We build libjvm_dtrace/libjvm_db/dtrace for COMPILER1 and 
COMPILER2

  28 # but not for CORE configuration.
  29
  30 ifneq ("${TYPE}", "CORE")
  31 ifneq ("${TYPE}", "MINIMAL1")
  32 ifneq ($(OPENJDK_TARGET_OS), ios)

line 28 needs updating. I'd also like to see indentation of 
conditional code if possible.

We held off on indentation changes, since the hotspot makefiles
had not been updated for the new build guidelines.



 329 else # IPHONE  build

There is no "if" that references IPHONE build - is this really the iOS 
part?


---

hotspot/make/bsd/makefiles/minimal1.make
hotspot/make/linux/makefiles/minimal1.make

This seems to be a new definition of the minimal VM which now includes 
JVM TI ?? Not sure the minimal VM should mean different things on 
different platforms. Also unclear if you can really enable JVM TI with 
all the other "minimal" components disabled - it was never 
intended/allowed-for an arbitrary subset of INCLUDE_XXX flags to be 
turned on/off.

I'll leave this for Bob to address.
We initially were supporting minimal and client vm for ios,
but found our users only needing the jvmti features from
the client vm.


---

hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp
hotspot/src/cpu/x86/vm/c1_Runtime1_x86.cpp
etc

Without more context the change of casts from intptr_t to int32_t, or 
added cast of int32_t seem wrong - they should be 64-bit on a 64-bit 
platform. If this is all actually 32-bit only code then a lot of other 
changes can/should be made regarding the LP64 macros. Regardless if 
the type of NULL_WORD is causing a problem then its type should be 
fixed, not added casts everywhere it is used.


I'll leave this to Bertrand to address.

I'll leave the remaining android impl questions to Bob.
Our android developer is no longer with us, so we will have
some work to do before these initial code changes are
acceptable for mainstream integration.


---

hotspot/src/os/linux/vm/jvm_linux.cpp

Shouldn't this:

+ #ifdef __ANDROID__
+// Android 'h' files don't have a  define for SIGCLD
+// I therefore took the following define & comment from Linux's
+// /usr/include/bits/signum.h
+ #define  SIGCLD  SIGCHLD /* Same as SIGCHLD (System V).  */
+ #endif
"CLD",SIGCLD, /* Same as SIGCHLD (System V). */
"CHLD",   SIGCHLD,/* Child status has changed 
(POSIX).  */


just be:

+ #ifdef SIGCLD
"CLD",SIGCLD, /* Same as SIGCHLD (System V). */
+#endif
"CHLD",   SIGCHLD,/* Child status has changed 
(POSIX).  */


---

hotspot/src/os/linux/vm/os_linux.cpp (and others)

Is the need for all the _ANDROID_ conditionals due to this not being 
Linux or not having glibc? We actually want to get rid of the dlsym 
dynamic lookup in mainline because we no longer support Linux versions 
without the desired functions!


Overall the conditionals here make this code really ugly/messy. :(

---

hotspot/src/share/vm/prims/jvm.cpp

Really hate the android conditionals in this shared code!

---

hotspot/src/share/vm/prims/jvmtiExport.cpp

Not at all clear to me that the code conditionalized belongs to 
SERVICES! Is this just a hack to exclude attach-on-demand?

---

hotspot/src/share/vm/runtime/java.cpp

Would want to look at ways to make this cleaner.

---

hotspot/src/share/vm/runtime/orderAccess.inline.hpp

These changes are ugly and should not be necessary - needs further 
examination. The whole point of intptr_t is that it will the same as 
int on 32-bit (ILP32), and same as a pointer on 64-bit (LP64). Is 
Android/iOS defining a different programming model?




On 12/12/2015 1:15 AM, Gary Adams wrote:

Here's the initial upload of changes that provides support for the ios
and android ports
for the mobile/dev repos. While there have been some preliminary reviews
of the code,
there is still more work required before we will look for more thorough
reviews
and an integration to mobile/jdk9 repos.

   Issue: https://bugs.openjdk.java.net/browse/JDK-8145132
   Webrev: http://cr.openjdk.java.net/~gadams/8145132/webrev.00/


Here's a simple configure script to generate a ios-x86_64 build for use
with the iphone simulator. (uses 

Re: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds.

[Gary Adams]

On 12/18/15 07:34, Magnus Ihse Bursie wrote:

On 2015-12-17 20:40, Gary Adams wrote:

On 12/17/15 11:09, Magnus Ihse Bursie wrote:

On 2015-12-17 14:19, Gary Adams wrote:

I've revised the original webrev based on some feedback received.
   - reverted white space only changes
   - proper copyrights on the new files
   - some hotspot files contained previously removed code

  Webrev; http://cr.openjdk.java.net/~gadams/8145132/webrev.01/

Planning to push this first batch tomorrow.


Hi Gary,

There seems to be multiple merge/diff errors in this patch. I'm 
seeing several location where this patch contains changes that is 
part of other, recently pushed change sets. This makes it hard to 
fully understand what changes you are contributing in this patch, to 
speak nothing of the merge problems that are likely to arise if this 
patch were pushed as it is.
My bad. In getting the workspace to build I had diff'ed the files 
against the latest jdk9-dev sources
and pulled in changes that were ahead of the recently cloned 
mobile/dev repos.
The next merge will bring in those updates. mobile/dev is cloned from 
jdk9-b94 and latest jdk9/dev

is at jdk9-9+b96.

While reverting the code that had newer functionality than it should,
I found the issue that dragged me down the rabbit hole. The change
to use JAVA_JAVAC in the SetupCompilers logic was a thread that
unraveled into more code than I should have touched.  I'll double
check on the next resync to make sure everything is OK.




I found several other issues as well. I'm sorry I have not been able 
to review this code before. It's a quite massive patch. If you want 
to commit the patch as-is in the mobile/dev forest and then fix my 
comments later before pushing further to mobile/jdk9, it's ok for 
me. I understand that it's tricky to manage a patch of this size. 
(But I think it's better to fix issues now, if you ask me...)
I'd like to do any simple cleanups before the initial push. We know 
there will be more pushes coming, so I'm not opposed to partial solutions

being put back at this time.


I'll start with something that you and Erik already has discussed: 
how to express tests for logic that is common to ios and macosx. 
There are places in the patch right now that I'm still not happy with.


First of all, I don't think you need to be shy of testing for macosx 
or ios. It's a bit more to write, but it's very clear to the reader, 
and code is read more often than written.
I am uncomfortable with all the places platform specific changes need 
to be made.
There isn't an easy way to express platform A is like platform B with 
the following

differences.


I agree. Platforms are alike and different in very amorphous ways. 
We've tried to capture some of this using the concept of "os type" 
(that is, to group unix-like operating systems) and "os env" (to 
differentiate the unix-emulation layers on windows). It works sort-of, 
but it's not perfect. For instance, in some respects macosx is indeed 
"unix", but in many other (GUI etc), it's different. We could of 
course try to create some kind of category "unix-except-macosx" for 
that, but in the end I don't think having 
src/java.base/unix-but-not-macosx/ would fly. :-)


So this is a tricky problem, and I believe it can only be "solved" in 
terms of getting a "best effort" solution for the platforms and 
combinations we currently support. When that support matrix changes 
too much (as with mobile), we might have to revise our model. Let's 
keep an open discussion on the best way to solve this for mobile. For 
now, though, I think the best way is to try and use the current 
framework as far as possible. Then we will learn what the actual 
limitations are and where they need to be fixed.

OK




Second, I see you introduce a OPENJDK_TARGET_OS_ENV=macosx for ios. 
It's a bit strange, since it changes the meaning of the OS_ENV 
(previously it was only used to differentiate between cygwin and 
msys in Windows), but I think it could be a reasonable modification. 
This means that you can test if OPENJDK_TARGET_OS_ENV == macosx to 
cover both the case of macosx and ios. Let's just assume that you 
need to know what you're doing when looking at OS_ENV. So this could 
be an alternative to a lot of "if target == macosx or target == 
ios", if you don't want to type that everywhere. For android it 
seems less of a point of setting OS_ENV. Or do you think you could 
unify android/linux code by this?
I thought previously we were told not to use OPENJDK_TARGET_OS_ENV 
and I asked at that time for "documentation".


You probably were. :) And it is perhaps best that you don't. :-) In 
any way, I don't see any references to the OS_ENV in this code anyway, 
so given that, you should remove this.


Removed OS_ENV settings for both andrioid and ios from platform.m4.


What I think you need is, as I understand it, rather to express some 
"os kind&q

Follow up bugs from the initial review comments

[Gary Adams]

I deferred a number of changes in order to get the first set of sources 
out to the mobile/dev repos.
Just so we don't lose sight of those changes, I've filed a few bugs that 
can be addressed independently

going forward.

 JDK-8145802: CPPFLAGS sysroot support
 JDK-8145804: ARFLAGS versus AR_OUT_OPTION conflicts in static builds
 JDK-8145806: OPENJDK_TARGET_CPU_LEGACY_LIB build variable will be retired
 JDK-8145807: JavaLauncher should use standard naming and build constructs
 JDK-8145809: Demo projects for HelloWorld for ios and android
 JDK-8145811: Fix compiler warnings

Re: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds.

[Gary Adams]

I've revised the original webrev based on some feedback received.
   - reverted white space only changes
   - proper copyrights on the new files
   - some hotspot files contained previously removed code

  Webrev; http://cr.openjdk.java.net/~gadams/8145132/webrev.01/

Planning to push this first batch tomorrow.

On 12/11/15 10:15, Gary Adams wrote:
Here's the initial upload of changes that provides support for the ios 
and android ports
for the mobile/dev repos. While there have been some preliminary 
reviews of the code,
there is still more work required before we will look for more 
thorough reviews

and an integration to mobile/jdk9 repos.

  Issue: https://bugs.openjdk.java.net/browse/JDK-8145132
  Webrev: http://cr.openjdk.java.net/~gadams/8145132/webrev.00/


Here's a simple configure script to generate a ios-x86_64 build for use
with the iphone simulator. (uses homebrew 64 bit freetype from pkgconfig)

export JAVA_HOME=`/usr/libexec/java_home -v 1.8`
export PATH=$JAVA_HOME/bin:~/homebrew/bin:$PATH

bash ../../configure \
--openjdk-target=x86_64-macos-ios \
--with-boot-jdk=$JAVA_HOME \
--disable-warnings-as-errors \
--disable-headful \
--enable-static-build=yes \
--with-jvm-variants=minimal1


Also, tested with i586-macos-ios target for 32 bit
with a locally built --with-freetype 2.6.2.

Re: RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds.

[Gary Adams]

On 12/17/15 11:09, Magnus Ihse Bursie wrote:

On 2015-12-17 14:19, Gary Adams wrote:

I've revised the original webrev based on some feedback received.
   - reverted white space only changes
   - proper copyrights on the new files
   - some hotspot files contained previously removed code

  Webrev; http://cr.openjdk.java.net/~gadams/8145132/webrev.01/

Planning to push this first batch tomorrow.


Hi Gary,

There seems to be multiple merge/diff errors in this patch. I'm seeing 
several location where this patch contains changes that is part of 
other, recently pushed change sets. This makes it hard to fully 
understand what changes you are contributing in this patch, to speak 
nothing of the merge problems that are likely to arise if this patch 
were pushed as it is.
My bad. In getting the workspace to build I had diff'ed the files 
against the latest jdk9-dev sources
and pulled in changes that were ahead of the recently cloned mobile/dev 
repos.
The next merge will bring in those updates. mobile/dev is cloned from 
jdk9-b94 and latest jdk9/dev

is at jdk9-9+b96.



I found several other issues as well. I'm sorry I have not been able 
to review this code before. It's a quite massive patch. If you want to 
commit the patch as-is in the mobile/dev forest and then fix my 
comments later before pushing further to mobile/jdk9, it's ok for me. 
I understand that it's tricky to manage a patch of this size. (But I 
think it's better to fix issues now, if you ask me...)
I'd like to do any simple cleanups before the initial push. We know 
there will be more pushes coming, so I'm not opposed to partial solutions

being put back at this time.


I'll start with something that you and Erik already has discussed: how 
to express tests for logic that is common to ios and macosx. There are 
places in the patch right now that I'm still not happy with.


First of all, I don't think you need to be shy of testing for macosx 
or ios. It's a bit more to write, but it's very clear to the reader, 
and code is read more often than written.
I am uncomfortable with all the places platform specific changes need to 
be made.
There isn't an easy way to express platform A is like platform B with 
the following

differences.



Second, I see you introduce a OPENJDK_TARGET_OS_ENV=macosx for ios. 
It's a bit strange, since it changes the meaning of the OS_ENV 
(previously it was only used to differentiate between cygwin and msys 
in Windows), but I think it could be a reasonable modification. This 
means that you can test if OPENJDK_TARGET_OS_ENV == macosx to cover 
both the case of macosx and ios. Let's just assume that you need to 
know what you're doing when looking at OS_ENV. So this could be an 
alternative to a lot of "if target == macosx or target == ios", if you 
don't want to type that everywhere. For android it seems less of a 
point of setting OS_ENV. Or do you think you could unify android/linux 
code by this?
I thought previously we were told not to use OPENJDK_TARGET_OS_ENV and I 
asked at that time for "documentation".


Third, I'm not really fond of the TOOLCHAIN_NAME variable. The concept 
is fine, but the variable name is not (I know you didn't invent 
this).  We have a TOOLCHAIN_DESCRIPTION and a TOOLCHAIN_NAME sounds 
like just a variant of that. Perhaps resusing the fluffy and 
unspecified ENV and call it TOOLCHAIN_ENV instead? I thought of 
TOOLCHAIN_VENDOR, but then again I'd assume that it'd be "apple", and 
I think we gain clarity by calling Xcode "xcode" and not "apple".


I'd be glad to use a different name or value for the flag, just let me know.

This is a change we could defer til the mobile/dev to mobile/jdk9 
integration.
At this time I'm mostly interested to know that we've used it in the 
right places.
e.g. prior to discovery of boot-jdk and xcode we used BUILD_OS macosx, 
after
that we use toolchain xcode check, for native flags and libraries we 
still check TARGET_OS

for macosx or ios when not xcode specific.


So, to the specifics:
basics.m4: It's not really true that this is build os rather than 
target os. In fact, the whole block is a mix of target and build 
dependent stuff. For instance, xattr depends on build platform but 
dsymutil depends on target os. I suggest you change to target == 
macosx || ios.

Will do.


boot-jdk.m4: At the end looks like merge error.

Will fix.
We had the big java fix in ejdk8u and it recently cam back in jdk9
recent builds.



flags.m4: Why delete CPPFLAGS for SYSROOTS?

SYSROOT does not belong on CPPFLAGS.
We needed the fix for the ios builds.



I think that if you set only LEGACY_EXTRA_CFLAGS and not EXTRA_CFLAGS, 
you will only pass this to Hotspot and not the jdk libraries. But 
honestly, the flag handling is mysterious even to me so I can't say 
for sure. But you might want to double-check this.
Not sure about this comment. We have working ios and android builds from 
the flags
that are currently being set

Re: RFR: JDK-8142907 Integration of minor fixes from the build-infra project

[Gary Adams]

On 12/14/15 07:34, David Holmes wrote:

On 14/12/2015 6:30 PM, Magnus Ihse Bursie wrote:

On 2015-12-14 09:12, David Holmes wrote:

Hi Magnus,

On 12/12/2015 8:24 AM, Magnus Ihse Bursie wrote:

On 2015-12-11 22:43, Magnus Ihse Bursie wrote:

Hi David,

Resurrecting the second part of the build-infra integrations. :)
Fortunately, no major code changes in the meantime has affected this
patch. (I did need to update the new
hotspot/make/lib/Lib-jdk.hotspot.agent.gmk though.)


It seems I forgot to include the link to the new webrev:

http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.05 





hotspot.m4:

 54 #server: normal interpreter and a tiered C1/C2 compiler
  55 #client: normal interpreter and C1 (no C2 compiler) (only
32-bit platforms)

Neither of these statements are necessarily 100% true - not all
platforms have tiered enable; some 64-bit platforms do (or will)
support client.


This code was directly moved from jdk-options.m4. But I can update the
text to better fit reality. I suggest updating the comment about 
server to:

# server: normal interpreter, and a C2 or tiered C1/C2 compiler
depending on platform
Ok?


Ok.


However, a few lines below we explicitely block enabling of client on
64-bit platforms, so I believe this statement is correct, at least for
the code as it looks now. It might be the case that the configure check
is too strict, and if so we should modify it, but as long as the check
remains I believe the comment should remain. Ok?


OK. As long as whomever removes the check knows to remove the comment. 
Both the arm32 port and the mobile project will be relaxing this afaik.
For the mobile port we have relaxed the constraint and allow a 64 bit 
client and

minimal vm to be built. I'll make sure the comment is updated in our repos.
I don't think there was a fundamental reason those variations were not 
support,
just a question of which platforms were being built and tested on a 
regular basis.




Thanks,
David


Otherwise I didn't see anything else that I obviously needed to
comment on. The proof of this is in the building. So as long as this
gets through JPRT with -testset hotspot we should be okay. :)

Great. Thanks for the review!

/Magnus


Thanks,
David



/Magnus




On 2015-11-16 05:33, David Holmes wrote:

Hi Magnus,

I had a flick through most of the files. Overall seems okay but I
have a few queries below.


Replies inline.



On 13/11/2015 12:43 PM, Magnus Ihse Bursie wrote:

The build-infra project has collected a number of minor fixes and
changes during the new hotspot build development. Its a mix of
code
cleanup and new capabilities.

Not all of these new features are immediately beneficial to the 
JDK,

but
they will be needed for the upcoming new Hotspot build, and it
will not
hurt to have them in mainline. (In fact, it will tremendously help
merging between mainline and build-infra.)

The fix addresses these issues:

In general:
* Break out hotspot configuration into hotspot.m4
* Long link lines uses @-files
* Consistently use -Wl instead of -Xlinker
* Improve clang on linux compilation
* Set shared library name explicitely on solaris
* Set correct shared library flag on Windows (-dll)
* Consistency fixes for build toolchain
* Bring compare script up to date
* General code/whitespace cleanup
* Additional functionality in MakeBase

In NativeCompilation.gmk:
* More efficient vardeps for per-file CFLAGS
* Fewer shell executions (means better performance on Windows)
* EXCLUDE_PATTERN and EXTRA_OBJECT_FILES
* Debug symbols on macosx (disabled for existing code to keep 
current

behavior)

Enabling debug info on macosx on existing jdk should be treated 
in a

follow-up bug.
Bug: https://bugs.openjdk.java.net/browse/JDK-8142907
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.01 






(It turned out that WebRev could not at the same time include files
from
multiple repos and track the history of a "hg cp":ied file. So I
created
an alternative revision here:
http://cr.openjdk.java.net/~ihse/JDK-8142907-build-infra-integration-closed/webrev.02/ 






It does not include the jdk files, but hotspot.m4 might be 
easier to

understand)


flags.m4:

  60   AC_SUBST(LEGACY_EXTRA_CFLAGS)
  61   AC_SUBST(LEGACY_EXTRA_CXXFLAGS)
  62   AC_SUBST(LEGACY_EXTRA_LDFLAGS)
  63
  64   AC_SUBST(EXTRA_CFLAGS)
  65   AC_SUBST(EXTRA_CXXFLAGS)
  66   AC_SUBST(EXTRA_LDFLAGS)

IIRC we added the legacy flags purely to pass the cross-compilation
args through to hotspot. Not sure why we need both legacy and
non-legancy variants now ??


This is part of an ongoing effort to split CFLAGS_JDK into more
reasonable parts. The current model is that we throw all possible
flags together in CFLAGS_JDK (and then further on to CFLAGS_JDKLIB et
al). While it was questionable even before, it did work when we only
built the JDK native libraries. Now that we need to build 
libjvm.so as

well, which has (for historical reason) a set 

RFR: 8145132: Initial updates for ios x86_64 mobile/dev builds.

[Gary Adams]

Here's the initial upload of changes that provides support for the ios 
and android ports
for the mobile/dev repos. While there have been some preliminary reviews 
of the code,
there is still more work required before we will look for more thorough 
reviews

and an integration to mobile/jdk9 repos.

  Issue: https://bugs.openjdk.java.net/browse/JDK-8145132
  Webrev: http://cr.openjdk.java.net/~gadams/8145132/webrev.00/


Here's a simple configure script to generate a ios-x86_64 build for use
with the iphone simulator. (uses homebrew 64 bit freetype from pkgconfig)

export JAVA_HOME=`/usr/libexec/java_home -v 1.8`
export PATH=$JAVA_HOME/bin:~/homebrew/bin:$PATH

bash ../../configure \
--openjdk-target=x86_64-macos-ios \
--with-boot-jdk=$JAVA_HOME \
--disable-warnings-as-errors \
--disable-headful \
--enable-static-build=yes \
--with-jvm-variants=minimal1


Also, tested with i586-macos-ios target for 32 bit
with a locally built --with-freetype 2.6.2.

Re: Java compilation and -g

[Gary Adams]

What is the size difference?

On 4/11/14, 10:53 AM, Chris Hegarty wrote:

On 11/04/14 15:40, Erik Joelsson wrote:

Hello,

While converting the build to the new build-infra makefiles, one thing
that annoyed me was the fact that we aren't consistently compiling with
or without -g for java code. In the new makefiles we just emulate the
same behavior, but I would like to sort it out properly now.

Currently langtools, jaxp and jaxws repos build with -g always, while
corba and jdk only build with -g when DEBUG_LEVEL is fastdebug or
slowdebug.

How would we really like this to work? Is there a reason not to ship
with -g enabled? I know from personal experience that I get very annoyed
when I can't step into the jdk classes and look at local variable values
when debugging my own java applications.


+1.

I can understand that this may be different for actual product builds.

-Chris.



/Erik