Build failure with gnu make 4.0 on Arch Linux

2013-11-01 Thread Henry Jen 

Hi,

I am trying to setup build environment on a new installation, and 
encounter following build error.


I suspect this is because of missing some required tools and software, 
however, the error message is not helpful.


Tried to echo the make commang used, but as you can see the output seems 
to be scrambled. Is there a way to find out what exact command causing 
problem? I tried to configure --with-jobs=1, that doesn't help.


The Gnu make version is 4.0, let me know what else information I can 
collect to help diagnosis the problem.


Cheers,
Henry




INFO: ZIP_DEBUGINFO_FILES=1
/usr/bin/make -s VERBOSE=-s LOG_LEVEL=warn -R -I 
/home/hjen/ws/tl/common/makefiles -f adlc.make -r  -rRs -I/home/h -j3 
-en/ws/tl/common/makefiles -I/home/hjen/ws/tl/common/makefiles 
-I/home/hjen/ws/tl/common/makefiles -I/home/hjen/ws/tl/common/makefiles 
-I/home/hjen/ws/tl/common/makefiles
/usr/bin/make: invalid option -- '/'
/usr/bin/make: invalid option -- '/'
Usage: make [options] [target] ...
Options:
  -b, -m  Ignored for compatibility.
  -B, --always-make   Unconditionally make all targets.
  -C DIRECTORY, --directory=DIRECTORY
  Change to DIRECTORY before doing anything.
  -d  Print lots of debugging information.
  --debug[=FLAGS] Print various types of debugging information.
  -e, --environment-overrides
  Environment variables override makefiles.
  --eval=STRING   Evaluate STRING as a makefile statement.
  -f FILE, --file=FILE, --makefile=FILE
  Read FILE as a makefile.
  -h, --help  Print this message and exit.
  -i, --ignore-errors Ignore errors from recipes.
  -I DIRECTORY, --include-dir=DIRECTORY
  Search DIRECTORY for included makefiles.
  -j [N], --jobs[=N]  Allow N jobs at once; infinite jobs with no arg.
  -k, --keep-goingKeep going when some targets can't be made.
  -l [N], --load-average[=N], --max-load[=N]
  Don't start multiple jobs unless load is below N.
  -L, --check-symlink-times   Use the latest mtime between symlinks and target.
  -n, --just-print, --dry-run, --recon
  Don't actually run any recipe; just print them.
  -o FILE, --old-file=FILE, --assume-old=FILE
  Consider FILE to be very old and don't remake it.
  -O[TYPE], --output-sync[=TYPE]
  Synchronize output of parallel jobs by TYPE.
  -p, --print-data-base   Print make's internal database.
  -q, --question  Run no recipe; exit status says if up to date.
  -r, --no-builtin-rules  Disable the built-in implicit rules.
  -R, --no-builtin-variables  Disable the built-in variable settings.
  -s, --silent, --quiet   Don't echo recipes.
  -S, --no-keep-going, --stop
  Turns off -k.
  -t, --touch Touch targets instead of remaking them.
  --trace Print tracing information.
  -v, --version   Print the version number of make and exit.
  -w, --print-directory   Print the current directory.
  --no-print-directoryTurn off -w, even if it was turned on implicitly.
  -W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE
  Consider FILE to be infinitely new.
  --warn-undefined-variables  Warn when an undefined variable is referenced.

This program built for x86_64-unknown-linux-gnu
Report bugs to 
make[5]: *** [ad_stuff] Error 2
/home/hjen/ws/tl/hotspot/make/linux/makefiles/top.make:91: recipe for target 
'ad_stuff' failed
make[4]: *** [product] Error 2
/home/hjen/ws/tl/hotspot/make/linux/Makefile:289: recipe for target 'product' 
failed
make[3]: *** [generic_build2] Error 2
Makefile:216: recipe for target 'generic_build2' failed
make[2]: *** [product] Error 2
Makefile:167: recipe for target 'product' failed
make[1]: *** 
[/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp]
 Error 2
HotspotWrapper.gmk:44: recipe for target 
'/home/hjen/ws/tl/build/linux-x86_64-normal-server-release/hotspot/_hotspot.timestamp'
 failed
/export/home/hjen/ws/tl//common/makefiles/Main.gmk:108: recipe for target 
'hotspot-only' failed
make: *** [hotspot-only] Error 2

Re: RFR: JDK-8027698: Platform specific jars are not being signed by the sign-jars target

2013-11-01 Thread Weijun Wang 
I didn't see any word on ucrypto.jar. Does that "wildcard" function 
automatically include it?


Thanks
Max

On 11/1/13, 18:34, Erik Joelsson wrote:

Please review this simple fix, adding sunmscapi.jar and ucrypto.jar to
the list of jars to be signed by the sign-jars target. Since these jars
are platform dependent, they aren't always present.

Bug: https://bugs.openjdk.java.net/browse/JDK-8027698
Webrev: http://cr.openjdk.java.net/~erikj/8027698/webrev.jdk.01/

/Erik

Re: RFR: JDK-8027698: Platform specific jars are not being signed by the sign-jars target

2013-11-01 Thread Bradford Wetmore 



On 11/1/2013 3:34 AM, Erik Joelsson wrote:

Please review this simple fix, adding sunmscapi.jar and ucrypto.jar to
the list of jars to be signed by the sign-jars target. Since these jars
are platform dependent, they aren't always present.

Bug: https://bugs.openjdk.java.net/browse/JDK-8027698
Webrev: http://cr.openjdk.java.net/~erikj/8027698/webrev.jdk.01/

/Erik


makefiles/SignJars.gmk
==

Overall:  Some of the existing/new lines are greater than the standard 
80 chars.


2:  Some people update the Copyright date instead of waiting for RE to 
do it.  Feel free if you're one of those.


48 & 108:  The RE process for signing jars for JDK 7/8 is completely 
different than what was originally written/described for JDK 7.  There 
is an additional separate script that RE uses to include the source_tips 
into the jar files, and then do the actual signing.  SignJars.gmk is 
here primarily for developer support.


47:  Suggest changing to:

# SPECIAL NOTE TO JCE/JDK developers: The source files must eventually
# be built, signed, and then the resulting jar files MUST BE CHECKED
# INTO THE CLOSED PART OF THE WORKSPACE*. This separate step *MUST NOT
# BE FORGOTTEN*, otherwise a bug fixed in the source code will not be
# reflected in the shipped binaries.
#
# Please consult with Release Engineering, which is responsible for
# creating the final JCE builds suitable for checkin.
#

94:  I don't see ucrypto.jar listed here.

108:  Can you please update the code here to output:

The jar files built by the 'sign-jars' target are developer
builds only and *MUST NOT* be checked into the closed workspace.

Please consult with Release Engineering: they will generate
the proper binaries for the closed workspace.

@$(PRINTF) $(README-MAKEFILE_WARNING)

Since this bug is a subtask of JDK-8027266, I'll add a few more comments 
to that bug.  I'm guessing you'll probably want to address separately.


Thanks, Erik!

Brad

Re: Heads up: New version of CYGWIN's cache breaks the windows build.

2013-11-01 Thread Bradford Wetmore 
My bug was closed as a dup, I've captured some of the pertinent info in 
both bugs.  Hopefully people can easily find the error condition if they 
hit it.


Internally, we have a minimal CYGWIN distribution that will likely be 
updated to remove ccache.  Tim just pinged me on that.


Brad


On 10/31/2013 4:51 PM, Mike Duigou wrote:

Magnus indicated in another thread earlier today that ccache doesn't do 
anything on windows since we use the microsoft compilers.

--disable-ccache or uninstall it.

I filed an RFE to disable ccache on windows.

Mike

On Oct 31 2013, at 15:50 , Bradford Wetmore  wrote:


P.S.  This version of ccache was added two days ago.

Brad


On 10/31/2013 3:42 PM, Bradford Wetmore wrote:

I just rebuilt my CYGWIN, and got ccache 3.1.9-2, which enables ccache
in the new build environment.  fixpath.exe does not play well with it.

Please see:

https://bugs.openjdk.java.net/browse/JDK-8027683

JDK-8027683: New version of CYGWIN includes ccache 3.1.9-2, breaks the
windows build.

The symptom is:

  Could not start process! Failed with error 2: The system cannot find
the file specified.

Brad

[7u] WXP/Cygwin/VS2010 patch to remove invali option from the SA compilation

2013-11-01 Thread Francis ANDRE 

Hi

Following is a patch to avoid warning messages produced by the VS2010 compiler 
when compiling SA as


cl: Ligne de commande warning D9035: l'option 'GZ' est deconseille et sera 
supprime dans une version ulterieure

cl: Ligne de commande warning D9036: utilisez 'RTC1' … la place de 'GZ'
cl: Ligne de commande warning D9035: l'option 'o' est deconseille et sera 
supprime dans une version ultrieure

cl: Ligne de commande warning D9002: option '-YX' inconnue ignoree


here the patch
---
diff --git a/make/windows/makefiles/sa.make b/make/windows/makefiles/sa.make
--- a/make/windows/makefiles/sa.make
+++ b/make/windows/makefiles/sa.make
@@ -94,7 +94,7 @@
SA_LD_FLAGS = bufferoverflowU.lib
!endif
!else
-SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -Od -D "WIN32" -D 
"_WINDOWS" -D "_DEB

UG" -D "_CONSOLE" -D "_MBCS" -YX -FD -GZ -c
+SA_CFLAGS = -nologo $(MS_RUNTIME_OPTION) -W3 -Gm $(GX_OPTION) -Od -D "WIN32" -D 
"_WINDOWS" -D "_DEB

UG" -D "_CONSOLE" -D "_MBCS" -FD -RTC1 -c
!if "$(ENABLE_FULL_DEBUG_SYMBOLS)" == "1"
SA_CFLAGS = $(SA_CFLAGS) -ZI
!endif


Francis

Removal of the old build system, partial and preliminary review (part 2)

2013-11-01 Thread Magnus Ihse Bursie 

Here is part 2 of the old build system removal.

This review is based against the previous part, i.e. where the lion's 
share of the old make files had been removed.


What remained was a handful or two of different types of files, 
scattered all around. I have checked each file and/or directory 
individually, and if it was not used, I removed it. (This was the case 
usually because the prior attempt was too conservative.)


If the files were only used by the closed parts of the source code, it 
was moved to a suitable place in the closed repos. (A separate review 
for the closed part is coming up shortly).


If it was actually used by the new build system, and it was source code 
that should be compiled, I moved it to make/src/classes or 
make/src/native, correspondingly.


If it was actually used by the new build system, and it was a data file 
that was used as input for a build tool, or some other part of the build 
process, I created a descriptive directory in make/data (e.g. classlist) 
and moved it there.


Finally, a few files belonged to utilities that is not used during the 
build. The comments on the utilities indicate that they are run manually 
and sporadically, such as CommentChecker or the tool to create the 
reorder files for native libs. Such tools will typically bit rot between 
uses, and while no-one has explicitely mentioned that they still use 
them, I did not want to remove them. I tested some of them, like the 
reorder tool, and it was indeed broken. I moved these toos into 
make/non-build-utils. Going forward, I believe these tools should 
probably find a better location and be used automatically so that they 
are tested, or they should be removed.


I did these changes one at a time, committing to a local sandbox after 
every individual step. Here is a (somewhat filtered) list of the commit 
comments. I hope they are self-descriptive enough to explain the changes 
I've made.


* Remove make/common. (Move to closed sources.)
* Remove PatchList.solaris (makefiles copy was unused) and move to 
closed sources.
* Remove make/tools/GenerateCharacter, save what's needed in 
make/data/characterdata.

* Move contents of  make/tools/UnicodeData/ to make/data/unicodedata.
* Move files actually used from make/tools/CharsetMapping to 
make/data/charsetmapping.
* Move contents of make/tools/dtdbuilder/dtds to make/data/dtdbuilder, 
and remove rest of make/tools/dtdbuilder.

* GendataTimeZone is not used anymore.
* Delete make/sun/javazic, and move remaining useful data to 
make/data/tzdata.
* Move SwingBeanInfo.template, beaninfo/images/*.gif and source code 
(which is only copied, not compiled) from make/tools/swing-beans to 
make/data/swingbeaninfo.
* Move make/javax/swing/beaninfo/manifest to 
make/data/swingbeaninfo/manifest.mf.

* Move make/tools/manifest.mf to make/data/mainmanifest/manifest.mf.
* Move make/javax/crypto/policy/ to make/data/cryptopolicy.
* Move make/tools/add_gnu_debuglink and 
make/tools/fix_empty_sec_hdr_flags to make/src/native.

* Move java source code from make/tools/src to make/src/classes.
* Move refs.allowed to data/checkdeps. (That was the last file in 
make/tools/src).
* Moving DocBeanInfo.java, GenDocletBeanInfo.java and 
GenSwingBeanInfo.java into make/src/classes/build/tools/swingbeaninfo. 
(This also means moving them to package build.tools.swingbeaninfo.)

* Move make/tools/sharing/classlist.* to make/data/classlist.
* Move the remaining tools, which are not used in the build process, to 
non-build-utils.
* Move java utilities that are not used in the build from make/src to 
make/non-build-utils/src.
* Prepare merging between makefiles and make by moving files in 
makefiles into corresponding positions. This means jpda/jdwp/jdwp.spec 
moved to data/jdwp/jdwp.spec, and sun/*/ToBin.java moved to 
src/classes/build/tools/icondata/*.


And here is the WebRev: 
http://cr.openjdk.java.net/~ihse/remove-old-build-part-2/webrev.01


/Magnus

Re: RFR: JDK-8027698: Platform specific jars are not being signed by the sign-jars target

2013-11-01 Thread Tim Bell 

Hi Erik:

Please review this simple fix, adding sunmscapi.jar and ucrypto.jar to 
the list of jars to be signed by the sign-jars target. Since these 
jars are platform dependent, they aren't always present.


Bug: https://bugs.openjdk.java.net/browse/JDK-8027698
Webrev: http://cr.openjdk.java.net/~erikj/8027698/webrev.jdk.01


Looks good to me.

Tim

Re: RFR: JDK-8027698: Platform specific jars are not being signed by the sign-jars target

2013-11-01 Thread Magnus Ihse Bursie 

On 2013-11-01 11:34, Erik Joelsson wrote:
Please review this simple fix, adding sunmscapi.jar and ucrypto.jar to 
the list of jars to be signed by the sign-jars target. Since these 
jars are platform dependent, they aren't always present.


Bug: https://bugs.openjdk.java.net/browse/JDK-8027698
Webrev: http://cr.openjdk.java.net/~erikj/8027698/webrev.jdk.01/


Looks good to me.

/Magnus

[patch] Building with Xcode 5 on OS X 10.9

2013-11-01 Thread Jürgen Kreileder 
Hi,

the appended changesets for build and hotspot allow building with 
"USE_CLANG=true make" on OS X 10.9 using Xcode 5.0.1.


Juergen

# HG changeset patch
# User Jürgen Kreileder 
# Date 1383086029 -3600
# Node ID 5cf40fd518ba9df9ef1806e9c2d6ace3ebc5366c
# Parent  4f2011496393a26dcfd7b1f7787a3673ddd32599
Allow building with "USE_CLANG=true make" on OS X Mavericks with Xcode 5.0.1

diff --git a/common/autoconf/generated-configure.sh 
b/common/autoconf/generated-configure.sh
--- a/common/autoconf/generated-configure.sh
+++ b/common/autoconf/generated-configure.sh
@@ -3865,7 +3865,7 @@
 #CUSTOM_AUTOCONF_INCLUDE
 
 # Do not change or remove the following line, it is needed for consistency 
checks:
-DATE_WHEN_GENERATED=1382702260
+DATE_WHEN_GENERATED=1383085981
 
 ###
 #
@@ -20069,11 +20069,15 @@
 # Check that this is likely to be GCC.
 $COMPILER --version 2>&1 | $GREP "Free Software Foundation" > /dev/null
 if test $? -ne 0; then
-  { $as_echo "$as_me:${as_lineno-$LINENO}: The $COMPILER_NAME compiler 
(located as $COMPILER) does not seem to be the required GCC compiler." >&5
+  COMPILER_VERSION_TEST=`$COMPILER --version 2>&1 | $HEAD -n 2 | $TAIL -n 
1 `
+  $COMPILER --version 2>&1 | $GREP "Apple LLVM" > /dev/null
+  if test $? -ne 0; then
+{ $as_echo "$as_me:${as_lineno-$LINENO}: The $COMPILER_NAME compiler 
(located as $COMPILER) does not seem to be the required GCC compiler." >&5
 $as_echo "$as_me: The $COMPILER_NAME compiler (located as $COMPILER) does not 
seem to be the required GCC compiler." >&6;}
-  { $as_echo "$as_me:${as_lineno-$LINENO}: The result from running with 
--version was: \"$COMPILER_VERSION_TEST\"" >&5
+{ $as_echo "$as_me:${as_lineno-$LINENO}: The result from running with 
--version was: \"$COMPILER_VERSION_TEST\"" >&5
 $as_echo "$as_me: The result from running with --version was: 
\"$COMPILER_VERSION_TEST\"" >&6;}
-  as_fn_error $? "GCC compiler is required. Try setting --with-tools-dir." 
"$LINENO" 5
+as_fn_error $? "GCC compiler is required. Try setting 
--with-tools-dir." "$LINENO" 5
+  fi
 fi
 
 # First line typically looks something like:
@@ -21648,11 +21652,15 @@
 # Check that this is likely to be GCC.
 $COMPILER --version 2>&1 | $GREP "Free Software Foundation" > /dev/null
 if test $? -ne 0; then
-  { $as_echo "$as_me:${as_lineno-$LINENO}: The $COMPILER_NAME compiler 
(located as $COMPILER) does not seem to be the required GCC compiler." >&5
+  COMPILER_VERSION_TEST=`$COMPILER --version 2>&1 | $HEAD -n 2 | $TAIL -n 
1 `
+  $COMPILER --version 2>&1 | $GREP "Apple LLVM" > /dev/null
+  if test $? -ne 0; then
+{ $as_echo "$as_me:${as_lineno-$LINENO}: The $COMPILER_NAME compiler 
(located as $COMPILER) does not seem to be the required GCC compiler." >&5
 $as_echo "$as_me: The $COMPILER_NAME compiler (located as $COMPILER) does not 
seem to be the required GCC compiler." >&6;}
-  { $as_echo "$as_me:${as_lineno-$LINENO}: The result from running with 
--version was: \"$COMPILER_VERSION_TEST\"" >&5
+{ $as_echo "$as_me:${as_lineno-$LINENO}: The result from running with 
--version was: \"$COMPILER_VERSION_TEST\"" >&5
 $as_echo "$as_me: The result from running with --version was: 
\"$COMPILER_VERSION_TEST\"" >&6;}
-  as_fn_error $? "GCC compiler is required. Try setting --with-tools-dir." 
"$LINENO" 5
+as_fn_error $? "GCC compiler is required. Try setting 
--with-tools-dir." "$LINENO" 5
+  fi
 fi
 
 # First line typically looks something like:
diff --git a/common/autoconf/toolchain.m4 b/common/autoconf/toolchain.m4
--- a/common/autoconf/toolchain.m4
+++ b/common/autoconf/toolchain.m4
@@ -65,9 +65,13 @@
 # Check that this is likely to be GCC.
 $COMPILER --version 2>&1 | $GREP "Free Software Foundation" > /dev/null
 if test $? -ne 0; then
-  AC_MSG_NOTICE([The $COMPILER_NAME compiler (located as $COMPILER) does 
not seem to be the required GCC compiler.])
-  AC_MSG_NOTICE([The result from running with --version was: 
"$COMPILER_VERSION_TEST"])
-  AC_MSG_ERROR([GCC compiler is required. Try setting --with-tools-dir.])
+  COMPILER_VERSION_TEST=`$COMPILER --version 2>&1 | $HEAD -n 2 | $TAIL -n 
1 `
+  $COMPILER --version 2>&1 | $GREP "Apple LLVM" > /dev/null
+  if test $? -ne 0; then
+AC_MSG_NOTICE([The $COMPILER_NAME compiler (located as $COMPILER) does 
not seem to be the required GCC compiler.])
+AC_MSG_NOTICE([The result from running with --version was: 
"$COMPILER_VERSION_TEST"])
+AC_MSG_ERROR([GCC compiler is required. Try setting --with-tools-dir.])
+  fi
 fi
 
 # First line typically looks something like:
=
# HG changeset patch
# User Jürgen Kreileder 
# Date 1383086084 -3600
# Node ID d02d1e0b9c8deeaa9e1bc59b723aef6de593e7fd
# Parent  7fd913010dbbf75260688fd2fa8964763fa49a09
Allow building wi

RFR: JDK-8027698: Platform specific jars are not being signed by the sign-jars target

2013-11-01 Thread Erik Joelsson 
Please review this simple fix, adding sunmscapi.jar and ucrypto.jar to 
the list of jars to be signed by the sign-jars target. Since these jars 
are platform dependent, they aren't always present.


Bug: https://bugs.openjdk.java.net/browse/JDK-8027698
Webrev: http://cr.openjdk.java.net/~erikj/8027698/webrev.jdk.01/

/Erik