From ted at tedneward.com Mon Jun 2 02:17:23 2008 From: ted at tedneward.com (Ted Neward) Date: Mon, 2 Jun 2008 02:17:23 -0700 Subject: OpenJDK on Solaris Dev Express 1/2008? Message-ID: <0d1f01c8c491$7a462ae0$6ed280a0$@com> Hey, anybody had luck building OpenJDK on SXDE 1/08? (Curious to know before I download the VMWare image.) I?m assuming that most of the bits will be there already, but I?d be grateful for anybody who?s ?been there, done that? to tell me if any patches or additional libraries have be downloaded and installed before building the latest JDK7 bits there?. Ted Neward Java, .NET, XML Services Consulting, Teaching, Speaking, Writing HYPERLINK "http://www.tedneward.com"http://www.tedneward.com No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.24.4/1476 - Release Date: 5/31/2008 12:25 PM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20080602/b040494a/attachment.html From Kelly.Ohair at Sun.COM Mon Jun 2 08:43:25 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 02 Jun 2008 08:43:25 -0700 Subject: OpenJDK on Solaris Dev Express 1/2008? In-Reply-To: <0d1f01c8c491$7a462ae0$6ed280a0$@com> References: <0d1f01c8c491$7a462ae0$6ed280a0$@com> Message-ID: <4844151D.8030309@sun.com> If SXDE contains Sun Studio 12 (SS12), you may have some problems with compiling hotspot. I've integrated some hotspot changes to deal with SS12 issues http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a49545cab84a (hasn't been integrated into the master jdk7/jdk7 repositories yet). The rest of the jdk may compile file with SS12, but lots of warnings about the use of -xarch options, harmless but annoying. I'm working on the rest of the SS12 Makefile changes for the jdk, to get rid of these warnings etc. If you can get a Sun Studio 11 installed, would be better right now. I used a previous version of SXDE to build OpenJDK a while back, but it had SS11 in it at that time, so it was a while ago. Looks like the latest SXDE includes Sun Studio Express compilers, which are effectively SS12+ I assume. -kto Ted Neward wrote: > Hey, anybody had luck building OpenJDK on SXDE 1/08? (Curious to know > before I download the VMWare image.) > > > > I?m assuming that most of the bits will be there already, but I?d be > grateful for anybody who?s ?been there, done that? to tell me if any > patches or additional libraries have be downloaded and installed before > building the latest JDK7 bits there?. > > > > Ted Neward > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.tedneward.com > > > > > No virus found in this outgoing message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.24.4/1476 - Release Date: > 5/31/2008 12:25 PM > From samkraju.java at gmail.com Mon Jun 2 11:59:03 2008 From: samkraju.java at gmail.com (Sam K. Raju) Date: Tue, 03 Jun 2008 00:29:03 +0530 Subject: OpenJDK Build error on Ubuntu 8.04 Message-ID: <1212433143.7870.6.camel@samkraju> Hi All, I had download the OpenJDK source code yesterday and tried to build it but I got compiler error. Somebody please help me to resolve this error. Please find error message in the attachment. Thanks, SAM -------------- next part -------------- # Java sources to be compiled: (listed in file /home/samkraju/OpenJDK/jdk7/build/linux-i586/tmp/java/java.lang/java/.classes.list) /home/samkraju/OpenJDK/jdk7/build/linux-i586/gensrc/java/lang/UNIXProcess.java /home/samkraju/OpenJDK/jdk7/build/linux-i586/gensrc/java/nio/charset/CharsetDecoder.java /home/samkraju/OpenJDK/jdk7/build/linux-i586/gensrc/java/nio/charset/CharsetEncoder.java /home/samkraju/OpenJDK/jdk7/build/linux-i586/gensrc/java/nio/DirectByteBuffer.java /home/samkraju/OpenJDK/jdk7/build/linux-i586/gensrc/java/nio/HeapByteBuffer.java /home/samkraju/OpenJDK/jdk7/build/linux-i586/gensrc/java/nio/HeapCharBuffer.java /home/samkraju/OpenJDK/jdk7/build/linux-i586/gensrc/sun/misc/Version.java /home/samkraju/OpenJDK/jdk7/build/linux-i586/gensrc/sun/util/CoreResourceBundleControl.java /home/samkraju/OpenJDK/jdk7/build/linux-i586/gensrc/sun/util/LocaleDataMetaInfo.java ../../../src/share/classes/java/io/Bits.java ../../../src/share/classes/java/io/BufferedInputStream.java ../../../src/share/classes/java/io/BufferedOutputStream.java ../../../src/share/classes/java/io/BufferedReader.java ../../../src/share/classes/java/io/BufferedWriter.java ../../../src/share/classes/java/io/ByteArrayInputStream.java ../../../src/share/classes/java/io/ByteArrayOutputStream.java ../../../src/share/classes/java/io/CharArrayReader.java ../../../src/share/classes/java/io/CharArrayWriter.java ../../../src/share/classes/java/io/CharConversionException.java ../../../src/share/classes/java/io/Closeable.java ../../../src/share/classes/java/io/Console.java ../../../src/share/classes/java/io/DataInput.java ../../../src/share/classes/java/io/DataInputStream.java ../../../src/share/classes/java/io/DataOutput.java ../../../src/share/classes/java/io/DataOutputStream.java ../../../src/share/classes/java/io/DeleteOnExitHook.java ../../../src/share/classes/java/io/EOFException.java ../../../src/share/classes/java/io/ExpiringCache.java ../../../src/share/classes/java/io/Externalizable.java ../../../src/share/classes/java/io/FileFilter.java ../../../src/share/classes/java/io/FileInputStream.java ../../../src/share/classes/java/io/File.java ../../../src/share/classes/java/io/FilenameFilter.java ../../../src/share/classes/java/io/FileNotFoundException.java ../../../src/share/classes/java/io/FileOutputStream.java ../../../src/share/classes/java/io/FilePermission.java ../../../src/share/classes/java/io/FileReader.java ../../../src/share/classes/java/io/FileSystem.java ../../../src/share/classes/java/io/FileWriter.java ../../../src/share/classes/java/io/FilterInputStream.java ../../../src/share/classes/java/io/FilterOutputStream.java ../../../src/share/classes/java/io/FilterReader.java ../../../src/share/classes/java/io/FilterWriter.java ../../../src/share/classes/java/io/Flushable.java ../../../src/share/classes/java/io/InputStream.java ../../../src/share/classes/java/io/InputStreamReader.java ../../../src/share/classes/java/io/InterruptedIOException.java ../../../src/share/classes/java/io/InvalidClassException.java ../../../src/share/classes/java/io/InvalidObjectException.java ../../../src/share/classes/java/io/IOException.java ../../../src/share/classes/java/io/LineNumberInputStream.java ../../../src/share/classes/java/io/LineNumberReader.java ../../../src/share/classes/java/io/NotActiveException.java ../../../src/share/classes/java/io/NotSerializableException.java ../../../src/share/classes/java/io/ObjectInput.java ../../../src/share/classes/java/io/ObjectInputStream.java ../../../src/share/classes/java/io/ObjectInputValidation.java ../../../src/share/classes/java/io/ObjectOutput.java ../../../src/share/classes/java/io/ObjectOutputStream.java ../../../src/share/classes/java/io/ObjectStreamClass.java ../../../src/share/classes/java/io/ObjectStreamConstants.java ../../../src/share/classes/java/io/ObjectStreamException.java ../../../src/share/classes/java/io/ObjectStreamField.java ../../../src/share/classes/java/io/OptionalDataException.java ../../../src/share/classes/java/io/OutputStream.java ../../../src/share/classes/java/io/OutputStreamWriter.java ../../../src/share/classes/java/io/PipedInputStream.java ../../../src/share/classes/java/io/PipedOutputStream.java ../../../src/share/classes/java/io/PipedReader.java ../../../src/share/classes/java/io/PipedWriter.java ../../../src/share/classes/java/io/PrintStream.java ../../../src/share/classes/java/io/PrintWriter.java ../../../src/share/classes/java/io/PushbackInputStream.java ../../../src/share/classes/java/io/PushbackReader.java ../../../src/share/classes/java/io/RandomAccessFile.java ../../../src/share/classes/java/io/Reader.java ../../../src/share/classes/java/io/SequenceInputStream.java ../../../src/share/classes/java/io/Serializable.java ../../../src/share/classes/java/io/SerializablePermission.java ../../../src/share/classes/java/io/StreamCorruptedException.java ../../../src/share/classes/java/io/StreamTokenizer.java ../../../src/share/classes/java/io/StringBufferInputStream.java ../../../src/share/classes/java/io/StringReader.java ../../../src/share/classes/java/io/StringWriter.java ../../../src/share/classes/java/io/SyncFailedException.java ../../../src/share/classes/java/io/UnsupportedEncodingException.java ../../../src/share/classes/java/io/UTFDataFormatException.java ../../../src/share/classes/java/io/WriteAbortedException.java ../../../src/share/classes/java/io/Writer.java ../../../src/share/classes/java/lang/AbstractMethodError.java ../../../src/share/classes/java/lang/AbstractStringBuilder.java ../../../src/share/classes/java/lang/Appendable.java ../../../src/share/classes/java/lang/ApplicationShutdownHooks.java ../../../src/share/classes/java/lang/ArithmeticException.java ../../../src/share/classes/java/lang/ArrayIndexOutOfBoundsException.java ../../../src/share/classes/java/lang/ArrayStoreException.java ../../../src/share/classes/java/lang/AssertionError.java ../../../src/share/classes/java/lang/AssertionStatusDirectives.java ../../../src/share/classes/java/lang/Boolean.java ../../../src/share/classes/java/lang/Byte.java ../../../src/share/classes/java/lang/CharacterData.java ../../../src/share/classes/java/lang/Character.java ../../../src/share/classes/java/lang/CharSequence.java ../../../src/share/classes/java/lang/ClassCastException.java ../../../src/share/classes/java/lang/ClassCircularityError.java ../../../src/share/classes/java/lang/ClassFormatError.java ../../../src/share/classes/java/lang/Class.java ../../../src/share/classes/java/lang/ClassLoader.java ../../../src/share/classes/java/lang/ClassNotFoundException.java ../../../src/share/classes/java/lang/Cloneable.java ../../../src/share/classes/java/lang/CloneNotSupportedException.java ../../../src/share/classes/java/lang/Comparable.java ../../../src/share/classes/java/lang/Compiler.java ../../../src/share/classes/java/lang/ConditionalSpecialCasing.java ../../../src/share/classes/java/lang/Double.java ../../../src/share/classes/java/lang/EnumConstantNotPresentException.java ../../../src/share/classes/java/lang/Enum.java ../../../src/share/classes/java/lang/Error.java ../../../src/share/classes/java/lang/ExceptionInInitializerError.java ../../../src/share/classes/java/lang/Exception.java ../../../src/share/classes/java/lang/Float.java ../../../src/share/classes/java/lang/IllegalAccessError.java ../../../src/share/classes/java/lang/IllegalAccessException.java ../../../src/share/classes/java/lang/IllegalArgumentException.java ../../../src/share/classes/java/lang/IllegalMonitorStateException.java ../../../src/share/classes/java/lang/IllegalStateException.java ../../../src/share/classes/java/lang/IllegalThreadStateException.java ../../../src/share/classes/java/lang/IncompatibleClassChangeError.java ../../../src/share/classes/java/lang/IndexOutOfBoundsException.java ../../../src/share/classes/java/lang/InheritableThreadLocal.java ../../../src/share/classes/java/lang/InstantiationError.java ../../../src/share/classes/java/lang/InstantiationException.java ../../../src/share/classes/java/lang/Integer.java ../../../src/share/classes/java/lang/InternalError.java ../../../src/share/classes/java/lang/InterruptedException.java ../../../src/share/classes/java/lang/LinkageError.java ../../../src/share/classes/java/lang/Long.java ../../../src/share/classes/java/lang/Math.java ../../../src/share/classes/java/lang/NegativeArraySizeException.java ../../../src/share/classes/java/lang/NoClassDefFoundError.java ../../../src/share/classes/java/lang/NoSuchFieldError.java ../../../src/share/classes/java/lang/NoSuchFieldException.java ../../../src/share/classes/java/lang/NoSuchMethodError.java ../../../src/share/classes/java/lang/NoSuchMethodException.java ../../../src/share/classes/java/lang/NullPointerException.java ../../../src/share/classes/java/lang/NumberFormatException.java ../../../src/share/classes/java/lang/Number.java ../../../src/share/classes/java/lang/Object.java ../../../src/share/classes/java/lang/OutOfMemoryError.java ../../../src/share/classes/java/lang/Override.java ../../../src/share/classes/java/lang/Package.java ../../../src/share/classes/java/lang/ProcessBuilder.java ../../../src/share/classes/java/lang/Process.java ../../../src/share/classes/java/lang/Readable.java ../../../src/share/classes/java/lang/ref/Finalizer.java ../../../src/share/classes/java/lang/ref/FinalReference.java ../../../src/share/classes/java/lang/reflect/AccessibleObject.java ../../../src/share/classes/java/lang/reflect/Array.java ../../../src/share/classes/java/lang/reflect/Constructor.java ../../../src/share/classes/java/lang/reflect/Field.java ../../../src/share/classes/java/lang/reflect/InvocationTargetException.java ../../../src/share/classes/java/lang/reflect/Method.java ../../../src/share/classes/java/lang/reflect/Proxy.java ../../../src/share/classes/java/lang/ref/PhantomReference.java ../../../src/share/classes/java/lang/ref/Reference.java ../../../src/share/classes/java/lang/ref/ReferenceQueue.java ../../../src/share/classes/java/lang/ref/SoftReference.java ../../../src/share/classes/java/lang/ref/WeakReference.java ../../../src/share/classes/java/lang/Runnable.java ../../../src/share/classes/java/lang/RuntimeException.java ../../../src/share/classes/java/lang/Runtime.java ../../../src/share/classes/java/lang/RuntimePermission.java ../../../src/share/classes/java/lang/SecurityException.java ../../../src/share/classes/java/lang/SecurityManager.java ../../../src/share/classes/java/lang/Short.java ../../../src/share/classes/java/lang/Shutdown.java ../../../src/share/classes/java/lang/StackOverflowError.java ../../../src/share/classes/java/lang/StackTraceElement.java ../../../src/share/classes/java/lang/StrictMath.java ../../../src/share/classes/java/lang/StringBuffer.java ../../../src/share/classes/java/lang/StringBuilder.java ../../../src/share/classes/java/lang/StringCoding.java ../../../src/share/classes/java/lang/StringIndexOutOfBoundsException.java ../../../src/share/classes/java/lang/String.java ../../../src/share/classes/java/lang/SuppressWarnings.java ../../../src/share/classes/java/lang/System.java ../../../src/share/classes/java/lang/ThreadDeath.java ../../../src/share/classes/java/lang/ThreadGroup.java ../../../src/share/classes/java/lang/Thread.java ../../../src/share/classes/java/lang/ThreadLocal.java ../../../src/share/classes/java/lang/Throwable.java ../../../src/share/classes/java/lang/TypeNotPresentException.java ../../../src/share/classes/java/lang/UnknownError.java ../../../src/share/classes/java/lang/UnsatisfiedLinkError.java ../../../src/share/classes/java/lang/UnsupportedClassVersionError.java ../../../src/share/classes/java/lang/UnsupportedOperationException.java ../../../src/share/classes/java/lang/VerifyError.java ../../../src/share/classes/java/lang/VirtualMachineError.java ../../../src/share/classes/java/lang/Void.java ../../../src/share/classes/java/net/URLClassLoader.java ../../../src/share/classes/java/net/URLConnection.java ../../../src/share/classes/java/nio/Bits.java ../../../src/share/classes/java/nio/charset/Charset.java ../../../src/share/classes/java/nio/charset/UnmappableCharacterException.java ../../../src/share/classes/java/security/AccessController.java ../../../src/share/classes/java/security/ProtectionDomain.java ../../../src/share/classes/java/util/AbstractCollection.java ../../../src/share/classes/java/util/AbstractList.java ../../../src/share/classes/java/util/AbstractMap.java ../../../src/share/classes/java/util/AbstractQueue.java ../../../src/share/classes/java/util/AbstractSequentialList.java ../../../src/share/classes/java/util/AbstractSet.java ../../../src/share/classes/java/util/ArrayDeque.java ../../../src/share/classes/java/util/ArrayList.java ../../../src/share/classes/java/util/Arrays.java ../../../src/share/classes/java/util/BitSet.java ../../../src/share/classes/java/util/Calendar.java ../../../src/share/classes/java/util/Collection.java ../../../src/share/classes/java/util/Collections.java ../../../src/share/classes/java/util/Comparator.java ../../../src/share/classes/java/util/concurrent/AbstractExecutorService.java ../../../src/share/classes/java/util/concurrent/ArrayBlockingQueue.java ../../../src/share/classes/java/util/concurrent/atomic/AtomicBoolean.java ../../../src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ../../../src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ../../../src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ../../../src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ../../../src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ../../../src/share/classes/java/util/concurrent/atomic/AtomicLong.java ../../../src/share/classes/java/util/concurrent/atomic/AtomicMarkableReference.java ../../../src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ../../../src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ../../../src/share/classes/java/util/concurrent/atomic/AtomicReference.java ../../../src/share/classes/java/util/concurrent/atomic/AtomicStampedReference.java ../../../src/share/classes/java/util/concurrent/BlockingDeque.java ../../../src/share/classes/java/util/concurrent/BlockingQueue.java ../../../src/share/classes/java/util/concurrent/BrokenBarrierException.java ../../../src/share/classes/java/util/concurrent/Callable.java ../../../src/share/classes/java/util/concurrent/CancellationException.java ../../../src/share/classes/java/util/concurrent/CompletionService.java ../../../src/share/classes/java/util/concurrent/ConcurrentHashMap.java ../../../src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ../../../src/share/classes/java/util/concurrent/ConcurrentMap.java ../../../src/share/classes/java/util/concurrent/ConcurrentNavigableMap.java ../../../src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ../../../src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ../../../src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ../../../src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java ../../../src/share/classes/java/util/concurrent/CountDownLatch.java ../../../src/share/classes/java/util/concurrent/CyclicBarrier.java ../../../src/share/classes/java/util/concurrent/Delayed.java ../../../src/share/classes/java/util/concurrent/DelayQueue.java ../../../src/share/classes/java/util/concurrent/Exchanger.java ../../../src/share/classes/java/util/concurrent/ExecutionException.java ../../../src/share/classes/java/util/concurrent/ExecutorCompletionService.java ../../../src/share/classes/java/util/concurrent/Executor.java ../../../src/share/classes/java/util/concurrent/ExecutorService.java ../../../src/share/classes/java/util/concurrent/Executors.java ../../../src/share/classes/java/util/concurrent/Future.java ../../../src/share/classes/java/util/concurrent/FutureTask.java ../../../src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ../../../src/share/classes/java/util/concurrent/LinkedBlockingQueue.java ../../../src/share/classes/java/util/concurrent/locks/AbstractOwnableSynchronizer.java ../../../src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ../../../src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java ../../../src/share/classes/java/util/concurrent/locks/Condition.java ../../../src/share/classes/java/util/concurrent/locks/Lock.java ../../../src/share/classes/java/util/concurrent/locks/LockSupport.java ../../../src/share/classes/java/util/concurrent/locks/ReadWriteLock.java ../../../src/share/classes/java/util/concurrent/locks/ReentrantLock.java ../../../src/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java ../../../src/share/classes/java/util/ConcurrentModificationException.java ../../../src/share/classes/java/util/concurrent/PriorityBlockingQueue.java ../../../src/share/classes/java/util/concurrent/RejectedExecutionException.java ../../../src/share/classes/java/util/concurrent/RejectedExecutionHandler.java ../../../src/share/classes/java/util/concurrent/RunnableFuture.java ../../../src/share/classes/java/util/concurrent/RunnableScheduledFuture.java ../../../src/share/classes/java/util/concurrent/ScheduledExecutorService.java ../../../src/share/classes/java/util/concurrent/ScheduledFuture.java ../../../src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ../../../src/share/classes/java/util/concurrent/Semaphore.java ../../../src/share/classes/java/util/concurrent/SynchronousQueue.java ../../../src/share/classes/java/util/concurrent/ThreadFactory.java ../../../src/share/classes/java/util/concurrent/ThreadPoolExecutor.java ../../../src/share/classes/java/util/concurrent/TimeoutException.java ../../../src/share/classes/java/util/concurrent/TimeUnit.java ../../../src/share/classes/java/util/Currency.java ../../../src/share/classes/java/util/Date.java ../../../src/share/classes/java/util/Deque.java ../../../src/share/classes/java/util/Dictionary.java ../../../src/share/classes/java/util/DuplicateFormatFlagsException.java ../../../src/share/classes/java/util/EmptyStackException.java ../../../src/share/classes/java/util/Enumeration.java ../../../src/share/classes/java/util/EnumMap.java ../../../src/share/classes/java/util/EnumSet.java ../../../src/share/classes/java/util/EventListener.java ../../../src/share/classes/java/util/EventListenerProxy.java ../../../src/share/classes/java/util/EventObject.java ../../../src/share/classes/java/util/FormatFlagsConversionMismatchException.java ../../../src/share/classes/java/util/FormattableFlags.java ../../../src/share/classes/java/util/Formattable.java ../../../src/share/classes/java/util/FormatterClosedException.java ../../../src/share/classes/java/util/Formatter.java ../../../src/share/classes/java/util/GregorianCalendar.java ../../../src/share/classes/java/util/HashMap.java ../../../src/share/classes/java/util/HashSet.java ../../../src/share/classes/java/util/Hashtable.java ../../../src/share/classes/java/util/IdentityHashMap.java ../../../src/share/classes/java/util/IllegalFormatCodePointException.java ../../../src/share/classes/java/util/IllegalFormatConversionException.java ../../../src/share/classes/java/util/IllegalFormatException.java ../../../src/share/classes/java/util/IllegalFormatFlagsException.java ../../../src/share/classes/java/util/IllegalFormatPrecisionException.java ../../../src/share/classes/java/util/IllegalFormatWidthException.java ../../../src/share/classes/java/util/InputMismatchException.java ../../../src/share/classes/java/util/InvalidPropertiesFormatException.java ../../../src/share/classes/java/util/Iterator.java ../../../src/share/classes/java/util/JapaneseImperialCalendar.java ../../../src/share/classes/java/util/JumboEnumSet.java ../../../src/share/classes/java/util/LinkedHashMap.java ../../../src/share/classes/java/util/LinkedHashSet.java ../../../src/share/classes/java/util/LinkedList.java ../../../src/share/classes/java/util/ListIterator.java ../../../src/share/classes/java/util/List.java ../../../src/share/classes/java/util/ListResourceBundle.java ../../../src/share/classes/java/util/LocaleISOData.java ../../../src/share/classes/java/util/Locale.java ../../../src/share/classes/java/util/Map.java ../../../src/share/classes/java/util/MissingFormatArgumentException.java ../../../src/share/classes/java/util/MissingFormatWidthException.java ../../../src/share/classes/java/util/MissingResourceException.java ../../../src/share/classes/java/util/NavigableMap.java ../../../src/share/classes/java/util/NavigableSet.java ../../../src/share/classes/java/util/NoSuchElementException.java ../../../src/share/classes/java/util/Observable.java ../../../src/share/classes/java/util/Observer.java ../../../src/share/classes/java/util/prefs/AbstractPreferences.java ../../../src/share/classes/java/util/prefs/BackingStoreException.java ../../../src/share/classes/java/util/prefs/Base64.java ../../../src/share/classes/java/util/prefs/InvalidPreferencesFormatException.java ../../../src/share/classes/java/util/prefs/NodeChangeEvent.java ../../../src/share/classes/java/util/prefs/NodeChangeListener.java ../../../src/share/classes/java/util/prefs/PreferenceChangeEvent.java ../../../src/share/classes/java/util/prefs/PreferenceChangeListener.java ../../../src/share/classes/java/util/prefs/PreferencesFactory.java ../../../src/share/classes/java/util/prefs/Preferences.java ../../../src/share/classes/java/util/prefs/XmlSupport.java ../../../src/share/classes/java/util/PriorityQueue.java ../../../src/share/classes/java/util/Properties.java ../../../src/share/classes/java/util/PropertyPermission.java ../../../src/share/classes/java/util/PropertyResourceBundle.java ../../../src/share/classes/java/util/Queue.java ../../../src/share/classes/java/util/Random.java ../../../src/share/classes/java/util/regex/ASCII.java ../../../src/share/classes/java/util/regex/Matcher.java ../../../src/share/classes/java/util/regex/MatchResult.java ../../../src/share/classes/java/util/regex/Pattern.java ../../../src/share/classes/java/util/regex/PatternSyntaxException.java ../../../src/share/classes/java/util/RegularEnumSet.java ../../../src/share/classes/java/util/ResourceBundle.java ../../../src/share/classes/java/util/Scanner.java ../../../src/share/classes/java/util/ServiceConfigurationError.java ../../../src/share/classes/java/util/ServiceLoader.java ../../../src/share/classes/java/util/Set.java ../../../src/share/classes/java/util/SimpleTimeZone.java ../../../src/share/classes/java/util/SortedMap.java ../../../src/share/classes/java/util/SortedSet.java ../../../src/share/classes/java/util/spi/CurrencyNameProvider.java ../../../src/share/classes/java/util/spi/LocaleNameProvider.java ../../../src/share/classes/java/util/spi/LocaleServiceProvider.java ../../../src/share/classes/java/util/spi/TimeZoneNameProvider.java ../../../src/share/classes/java/util/Stack.java ../../../src/share/classes/java/util/StringTokenizer.java ../../../src/share/classes/java/util/Timer.java ../../../src/share/classes/java/util/TimerTask.java ../../../src/share/classes/java/util/TimeZone.java ../../../src/share/classes/java/util/TooManyListenersException.java ../../../src/share/classes/java/util/TreeMap.java ../../../src/share/classes/java/util/TreeSet.java ../../../src/share/classes/java/util/UnknownFormatConversionException.java ../../../src/share/classes/java/util/UnknownFormatFlagsException.java ../../../src/share/classes/java/util/UUID.java ../../../src/share/classes/java/util/Vector.java ../../../src/share/classes/java/util/WeakHashMap.java ../../../src/share/classes/java/util/XMLUtils.java ../../../src/share/classes/sun/misc/ASCIICaseInsensitiveComparator.java ../../../src/share/classes/sun/misc/FloatingDecimal.java ../../../src/share/classes/sun/misc/FormattedFloatingDecimal.java ../../../src/share/classes/sun/misc/GC.java ../../../src/share/classes/sun/misc/JavaIOAccess.java ../../../src/share/classes/sun/misc/JavaIODeleteOnExitAccess.java ../../../src/share/classes/sun/misc/JavaIOFileDescriptorAccess.java ../../../src/share/classes/sun/misc/JavaLangAccess.java ../../../src/share/classes/sun/misc/Launcher.java ../../../src/share/classes/sun/misc/MessageUtils.java ../../../src/share/classes/sun/misc/MetaIndex.java ../../../src/share/classes/sun/misc/NativeSignalHandler.java ../../../src/share/classes/sun/misc/Service.java ../../../src/share/classes/sun/misc/Signal.java ../../../src/share/classes/sun/misc/URLClassPath.java ../../../src/share/classes/sun/misc/VM.java ../../../src/share/classes/sun/misc/VMSupport.java ../../../src/share/classes/sun/net/www/protocol/file/FileURLConnection.java ../../../src/share/classes/sun/net/www/protocol/jar/Handler.java ../../../src/share/classes/sun/net/www/protocol/jar/JarURLConnection.java ../../../src/share/classes/sun/reflect/ConstantPool.java ../../../src/share/classes/sun/reflect/NativeConstructorAccessorImpl.java ../../../src/share/classes/sun/reflect/NativeMethodAccessorImpl.java ../../../src/share/classes/sun/reflect/Reflection.java ../../../src/share/classes/sun/util/BuddhistCalendar.java ../../../src/share/classes/sun/util/calendar/AbstractCalendar.java ../../../src/share/classes/sun/util/calendar/BaseCalendar.java ../../../src/share/classes/sun/util/calendar/CalendarDate.java ../../../src/share/classes/sun/util/calendar/CalendarSystem.java ../../../src/share/classes/sun/util/calendar/CalendarUtils.java ../../../src/share/classes/sun/util/calendar/Era.java ../../../src/share/classes/sun/util/calendar/Gregorian.java ../../../src/share/classes/sun/util/calendar/ImmutableGregorianDate.java ../../../src/share/classes/sun/util/calendar/JulianCalendar.java ../../../src/share/classes/sun/util/calendar/LocalGregorianCalendar.java ../../../src/share/classes/sun/util/calendar/ZoneInfoFile.java ../../../src/share/classes/sun/util/calendar/ZoneInfo.java ../../../src/share/classes/sun/util/EmptyListResourceBundle.java ../../../src/share/classes/sun/util/LocaleServiceProviderPool.java ../../../src/share/classes/sun/util/ResourceBundleEnumeration.java ../../../src/share/classes/sun/util/TimeZoneNameUtility.java ../../../src/solaris/classes/java/io/FileDescriptor.java ../../../src/solaris/classes/java/io/UnixFileSystem.java ../../../src/solaris/classes/java/lang/ProcessEnvironment.java ../../../src/solaris/classes/java/lang/ProcessImpl.java ../../../src/solaris/classes/java/lang/Terminator.java ../../../src/solaris/classes/java/util/prefs/FileSystemPreferencesFactory.java ../../../src/solaris/classes/java/util/prefs/FileSystemPreferences.java ../../../src/solaris/classes/sun/misc/FileURLMapper.java ../../../src/solaris/classes/sun/net/www/protocol/file/Handler.java # Running javac: /usr/lib/jvm/java-6-openjdk/bin/java -client -Xmx896m -Xms128m -XX:PermSize=32m -XX:MaxPermSize=160m -Xbootclasspath/p:/home/samkraju/OpenJDK/jdk7/build/linux-i586/langtools/dist/bootstrap/lib/javac.jar -jar /home/samkraju/OpenJDK/jdk7/build/linux-i586/langtools/dist/bootstrap/lib/javac.jar -source 1.5 -target 5 -encoding ascii -Xbootclasspath:/home/samkraju/OpenJDK/jdk7/build/linux-i586/classes -sourcepath /home/samkraju/OpenJDK/jdk7/build/linux-i586/gensrc:../../../src/solaris/classes:../../../src/share/classes -d /home/samkraju/OpenJDK/jdk7/build/linux-i586/classes @/home/samkraju/OpenJDK/jdk7/build/linux-i586/tmp/java/java.lang/java/.classes.list.filtered /home/samkraju/OpenJDK/jdk7/build/linux-i586/gensrc/java/nio/charset/CharsetEncoder.java:142: cannot find symbol symbol : class $replType$ location: class java.nio.charset.CharsetEncoder private $replType$ replacement; ^ /home/samkraju/OpenJDK/jdk7/build/linux-i586/gensrc/java/nio/charset/CharsetEncoder.java:185: cannot find symbol symbol : class $replType$ location: class java.nio.charset.CharsetEncoder $replType$ replacement) ^ /home/samkraju/OpenJDK/jdk7/build/linux-i586/gensrc/java/nio/charset/CharsetEncoder.java:246: cannot find symbol symbol : class $replType$ location: class java.nio.charset.CharsetEncoder public final $replType$ replacement() { ^ /home/samkraju/OpenJDK/jdk7/build/linux-i586/gensrc/java/nio/charset/CharsetEncoder.java:275: cannot find symbol symbol : class $replType$ location: class java.nio.charset.CharsetEncoder public final CharsetEncoder replaceWith($replType$ newReplacement) { ^ /home/samkraju/OpenJDK/jdk7/build/linux-i586/gensrc/java/nio/charset/CharsetEncoder.java:301: cannot find symbol symbol : class $replType$ location: class java.nio.charset.CharsetEncoder protected void implReplaceWith($replType$ newReplacement) { ^ Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. 5 errors make[3]: *** [.compile.classlist] Error 1 make[3]: Leaving directory `/home/samkraju/OpenJDK/jdk7/jdk/make/java/java' make[2]: *** [all] Error 1 make[2]: Leaving directory `/home/samkraju/OpenJDK/jdk7/jdk/make/java' make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/samkraju/OpenJDK/jdk7/jdk/make' make: *** [jdk-build] Error 2 samkraju at samkraju:~/OpenJDK/jdk7$ From Tim.Bell at Sun.COM Mon Jun 2 12:10:39 2008 From: Tim.Bell at Sun.COM (Tim Bell) Date: Mon, 02 Jun 2008 12:10:39 -0700 Subject: OpenJDK Build error on Ubuntu 8.04 In-Reply-To: <1212433143.7870.6.camel@samkraju> References: <1212433143.7870.6.camel@samkraju> Message-ID: <484445AF.5000309@sun.com> Hello Sam: > Somebody please help me to resolve this error. Please find error > message in the attachment. [... snip! ...] > /home/samkraju/OpenJDK/jdk7/build/linux-i586/gensrc/java/nio/charset/CharsetEncoder.java:142: cannot find symbol > symbol : class $replType$ > location: class java.nio.charset.CharsetEncoder > private $replType$ replacement; This is the /bin/bash versus /bin/dash issue on recent release(s) of Ubuntu. There are a couple of related bug IDs: http://bugs.sun.com/view_bug.do?bug_id=6681798 https://bugs.launchpad.net/ubuntu/+source/dash/+bug/61463 Also this thread on build-dev (at) openjdk.java.net: http://mail.openjdk.java.net/pipermail/build-dev/2008-May/001047.html The workaround (according to Martin) is 'sudo dpkg-reconfigure dash' and answer no HTH - Tim From David.Herron at Sun.COM Mon Jun 2 12:11:09 2008 From: David.Herron at Sun.COM (David Herron) Date: Mon, 02 Jun 2008 12:11:09 -0700 Subject: OpenJDK Build error on Ubuntu 8.04 In-Reply-To: <1212433143.7870.6.camel@samkraju> References: <1212433143.7870.6.camel@samkraju> Message-ID: <484445CD.7050700@sun.com> Sam K. Raju wrote: > Hi All, > > I had download the OpenJDK source code yesterday and tried to build > it but I got compiler error. > > Somebody please help me to resolve this error. Please find error > message in the attachment. > > Thanks, > SAM > That's a known issue. On Ubuntu 8.04 they use 'dash' rather than 'bash' and it's mostly compatible but for the dash in 8.04 it incorrectly handles some shell scripts in the openjdk source tree that are used to process some java template sources that create the some of the java source files. root at mini:~# ls -l /bin/sh lrwxrwxrwx 1 root root 4 2008-04-23 08:49 /bin/sh -> dash I suppose one fix would be to change that symbolic link to point to 'bash' instead. Another workaround is to add a 'SHELL=/bin/bash' to one or more makefile. - David Herron From Kelly.Ohair at Sun.COM Mon Jun 2 13:09:52 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 02 Jun 2008 13:09:52 -0700 Subject: OpenJDK Build error on Ubuntu 8.04 In-Reply-To: <1212433143.7870.6.camel@samkraju> References: <1212433143.7870.6.camel@samkraju> Message-ID: <48445390.3000802@sun.com> This looks like that sh vs. bash issue. See http://mail.openjdk.java.net/pipermail/nio-dev/2008-May/000026.html -kto Sam K. Raju wrote: > Hi All, > > I had download the OpenJDK source code yesterday and tried to build > it but I got compiler error. > > Somebody please help me to resolve this error. Please find error > message in the attachment. > > Thanks, > SAM > From David.Herron at Sun.COM Mon Jun 2 13:38:53 2008 From: David.Herron at Sun.COM (David Herron) Date: Mon, 02 Jun 2008 13:38:53 -0700 Subject: OpenJDK Build error on Ubuntu 8.04 In-Reply-To: <484445AF.5000309@sun.com> References: <1212433143.7870.6.camel@samkraju> <484445AF.5000309@sun.com> Message-ID: <48445A5D.1060500@sun.com> Tim Bell wrote: > Hello Sam: > >> Somebody please help me to resolve this error. Please find error >> message in the attachment. > [... snip! ...] > >> /home/samkraju/OpenJDK/jdk7/build/linux-i586/gensrc/java/nio/charset/CharsetEncoder.java:142: >> cannot find symbol >> symbol : class $replType$ >> location: class java.nio.charset.CharsetEncoder >> private $replType$ replacement; > > This is the /bin/bash versus /bin/dash issue on recent release(s) of > Ubuntu. > > There are a couple of related bug IDs: > > http://bugs.sun.com/view_bug.do?bug_id=6681798 > https://bugs.launchpad.net/ubuntu/+source/dash/+bug/61463 > > Also this thread on build-dev (at) openjdk.java.net: > > http://mail.openjdk.java.net/pipermail/build-dev/2008-May/001047.html > > The workaround (according to Martin) is 'sudo dpkg-reconfigure dash' > and answer no > > HTH - Tim Hey, Tim, thanks. I updated the bug with those bits of data as the suggested workaround. It'll take 24+ hours for the bug update to show publicly. - David Herron From twisti at complang.tuwien.ac.at Tue Jun 3 00:17:33 2008 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Tue, 03 Jun 2008 09:17:33 +0200 Subject: OpenJDK on Solaris Dev Express 1/2008? In-Reply-To: <4844151D.8030309@sun.com> References: <0d1f01c8c491$7a462ae0$6ed280a0$@com> <4844151D.8030309@sun.com> Message-ID: <1212477453.18514.3.camel@imac523d.theobroma-systems.com> On Mon, 2008-06-02 at 08:43 -0700, Kelly O'Hair wrote: > If SXDE contains Sun Studio 12 (SS12), you may have some problems with compiling > hotspot. I've integrated some hotspot changes to deal with SS12 issues > http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a49545cab84a > (hasn't been integrated into the master jdk7/jdk7 repositories yet). > > The rest of the jdk may compile file with SS12, but lots of warnings about > the use of -xarch options, harmless but annoying. I'm working on the rest > of the SS12 Makefile changes for the jdk, to get rid of these warnings etc. > > If you can get a Sun Studio 11 installed, would be better right now. > > I used a previous version of SXDE to build OpenJDK a while back, but it > had SS11 in it at that time, so it was a while ago. > Looks like the latest SXDE includes Sun Studio Express compilers, which > are effectively SS12+ I assume. Is it possible to build OpenJDK for OpenSolaris with GCC? - twisti From aph at redhat.com Tue Jun 3 01:22:39 2008 From: aph at redhat.com (Andrew Haley) Date: Tue, 03 Jun 2008 09:22:39 +0100 Subject: OpenJDK Build error on Ubuntu 8.04 In-Reply-To: <484445CD.7050700@sun.com> References: <1212433143.7870.6.camel@samkraju> <484445CD.7050700@sun.com> Message-ID: <4844FF4F.1060108@redhat.com> David Herron wrote: > Sam K. Raju wrote: >> Hi All, >> >> I had download the OpenJDK source code yesterday and tried to build >> it but I got compiler error. >> >> Somebody please help me to resolve this error. Please find error >> message in the attachment. >> >> Thanks, >> SAM >> > > That's a known issue. On Ubuntu 8.04 they use 'dash' rather than 'bash' > and it's mostly compatible but for the dash in 8.04 it incorrectly > handles some shell scripts in the openjdk source tree that are used to > process some java template sources that create the some of the java > source files. > > root at mini:~# ls -l /bin/sh > lrwxrwxrwx 1 root root 4 2008-04-23 08:49 /bin/sh -> dash > > I suppose one fix would be to change that symbolic link to point to > 'bash' instead. Another workaround is to add a 'SHELL=/bin/bash' to one > or more makefile. But if one of our scripts actually needs bash (not just sh) why not use #!/bin/bash ? Andrew. From Kelly.Ohair at Sun.COM Tue Jun 3 08:28:04 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 03 Jun 2008 08:28:04 -0700 Subject: OpenJDK on Solaris Dev Express 1/2008? In-Reply-To: <1212477453.18514.3.camel@imac523d.theobroma-systems.com> References: <0d1f01c8c491$7a462ae0$6ed280a0$@com> <4844151D.8030309@sun.com> <1212477453.18514.3.camel@imac523d.theobroma-systems.com> Message-ID: <48456304.5060302@sun.com> I'm not sure what the state of the Makefiles are for building with gcc on Solaris. It has been done in the past, from the artifacts I see in the Makefiles, however, it won't 'just build', it will take some changes. In general we focus on one compiler set per OS, the one that has the most potential for performance and makes the most sense for that OS. Takes a great deal of testing and performance tests to 'validate' that even a particular release of a compiler isn't regressing us. We will be going through that validation process as we change our default JDK7 compilers to SS12 on Solaris, gcc4 on Linux, and VS2008 on Windows. -kto Christian Thalinger wrote: > On Mon, 2008-06-02 at 08:43 -0700, Kelly O'Hair wrote: >> If SXDE contains Sun Studio 12 (SS12), you may have some problems with compiling >> hotspot. I've integrated some hotspot changes to deal with SS12 issues >> http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a49545cab84a >> (hasn't been integrated into the master jdk7/jdk7 repositories yet). >> >> The rest of the jdk may compile file with SS12, but lots of warnings about >> the use of -xarch options, harmless but annoying. I'm working on the rest >> of the SS12 Makefile changes for the jdk, to get rid of these warnings etc. >> >> If you can get a Sun Studio 11 installed, would be better right now. >> >> I used a previous version of SXDE to build OpenJDK a while back, but it >> had SS11 in it at that time, so it was a while ago. >> Looks like the latest SXDE includes Sun Studio Express compilers, which >> are effectively SS12+ I assume. > > Is it possible to build OpenJDK for OpenSolaris with GCC? > > - twisti > From twisti at complang.tuwien.ac.at Tue Jun 3 08:39:11 2008 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Tue, 03 Jun 2008 17:39:11 +0200 Subject: OpenJDK on Solaris Dev Express 1/2008? In-Reply-To: <48456304.5060302@sun.com> References: <0d1f01c8c491$7a462ae0$6ed280a0$@com> <4844151D.8030309@sun.com> <1212477453.18514.3.camel@imac523d.theobroma-systems.com> <48456304.5060302@sun.com> Message-ID: <1212507551.18514.41.camel@imac523d.theobroma-systems.com> On Tue, 2008-06-03 at 08:28 -0700, Kelly O'Hair wrote: > I'm not sure what the state of the Makefiles are for building with gcc > on Solaris. It has been done in the past, from the artifacts I see in the > Makefiles, however, it won't 'just build', it will take some changes. > > In general we focus on one compiler set per OS, the one that has > the most potential for performance and makes the most sense for that OS. > Takes a great deal of testing and performance tests to 'validate' that > even a particular release of a compiler isn't regressing us. > > We will be going through that validation process as we change our > default JDK7 compilers to SS12 on Solaris, gcc4 on Linux, and > VS2008 on Windows. I see. Maybe I can give it try someday. - twisti From martinrb at google.com Tue Jun 3 09:55:30 2008 From: martinrb at google.com (Martin Buchholz) Date: Tue, 3 Jun 2008 09:55:30 -0700 Subject: OpenJDK Build error on Ubuntu 8.04 In-Reply-To: <4844FF4F.1060108@redhat.com> References: <1212433143.7870.6.camel@samkraju> <484445CD.7050700@sun.com> <4844FF4F.1060108@redhat.com> Message-ID: <1ccfd1c10806030955j4f71b37eua2bd60df5e887c8b@mail.gmail.com> sh is a horrible programming language whose primary virtue is portability -- every Unix system since the dark ages has it. Much of that is lost when replacing #!/bin/sh with #!/bin/bash. Might as well upgrade to a "real" programming language. Martin On Tue, Jun 3, 2008 at 1:22 AM, Andrew Haley wrote: > But if one of our scripts actually needs bash (not just sh) why not use > #!/bin/bash ? > > Andrew. > From aph at redhat.com Tue Jun 3 10:09:17 2008 From: aph at redhat.com (Andrew Haley) Date: Tue, 03 Jun 2008 18:09:17 +0100 Subject: OpenJDK Build error on Ubuntu 8.04 In-Reply-To: <1ccfd1c10806030955j4f71b37eua2bd60df5e887c8b@mail.gmail.com> References: <1212433143.7870.6.camel@samkraju> <484445CD.7050700@sun.com> <4844FF4F.1060108@redhat.com> <1ccfd1c10806030955j4f71b37eua2bd60df5e887c8b@mail.gmail.com> Message-ID: <48457ABD.3000506@redhat.com> Martin Buchholz wrote: > On Tue, Jun 3, 2008 at 1:22 AM, Andrew Haley wrote: >> But if one of our scripts actually needs bash (not just sh) why not use >> #!/bin/bash ? > sh is a horrible programming language whose primary virtue is > portability -- every Unix system since the dark ages has it. > Much of that is lost when replacing #!/bin/sh with #!/bin/bash. > Might as well upgrade to a "real" programming language. Sure, but this bug seems to suggest that we *already* rely on /bin/bash, but we pretend not to by assuming that /bin/sh runs bash. If we rely on bash, let's be straight about it. Andrew. From David.Herron at Sun.COM Tue Jun 3 10:48:24 2008 From: David.Herron at Sun.COM (David Herron) Date: Tue, 03 Jun 2008 10:48:24 -0700 Subject: Relying on /bin/sh compatibility ? ... Re: OpenJDK Build error on Ubuntu 8.04 In-Reply-To: <48457ABD.3000506@redhat.com> References: <1212433143.7870.6.camel@samkraju> <484445CD.7050700@sun.com> <4844FF4F.1060108@redhat.com> <1ccfd1c10806030955j4f71b37eua2bd60df5e887c8b@mail.gmail.com> <48457ABD.3000506@redhat.com> Message-ID: <484583E8.1070900@sun.com> Andrew Haley wrote: > Martin Buchholz wrote: > >> On Tue, Jun 3, 2008 at 1:22 AM, Andrew Haley wrote: >> >>> But if one of our scripts actually needs bash (not just sh) why not use >>> #!/bin/bash ? >>> >> sh is a horrible programming language whose primary virtue is >> portability -- every Unix system since the dark ages has it. >> Much of that is lost when replacing #!/bin/sh with #!/bin/bash. >> Might as well upgrade to a "real" programming language. >> > > Sure, but this bug seems to suggest that we *already* rely on > /bin/bash, but we pretend not to by assuming that /bin/sh runs > bash. If we rely on bash, let's be straight about it. > > Andrew. > er.. there's a little more to it than that, methinks. First, because it's /bin/sh that's portable (not /bin/bash) I believe the shell scripts should be written for compatibility with /bin/sh Second, it's an open question whether dash or bash does a better job of implementing /bin/sh and I have no clue as to which does the better job. I think it's either a) fix the script in question or b) fix dash. BTW does anybody know where to get a SHCK? (/bin/sh Compatibility Kit) How can we be sure any /bin/sh interpreter is actually compatible with /bin/sh ?? - David Herron -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20080603/3f0ad0ac/attachment.html From Kelly.Ohair at Sun.COM Tue Jun 3 10:53:50 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 03 Jun 2008 10:53:50 -0700 Subject: OpenJDK Build error on Ubuntu 8.04 In-Reply-To: <48457ABD.3000506@redhat.com> References: <1212433143.7870.6.camel@samkraju> <484445CD.7050700@sun.com> <4844FF4F.1060108@redhat.com> <1ccfd1c10806030955j4f71b37eua2bd60df5e887c8b@mail.gmail.com> <48457ABD.3000506@redhat.com> Message-ID: <4845852E.6090508@sun.com> As far as I know, only Ubuntu (and only 8.04?) depends on bash. No other OS seems to have a problem using plain old antique sh. --- Ideally, these sh scripts used in the build process should be changed to be something else, maybe small Java apps. Someday. -kto Andrew Haley wrote: > Martin Buchholz wrote: > >> On Tue, Jun 3, 2008 at 1:22 AM, Andrew Haley wrote: >>> But if one of our scripts actually needs bash (not just sh) why not use >>> #!/bin/bash ? > >> sh is a horrible programming language whose primary virtue is >> portability -- every Unix system since the dark ages has it. >> Much of that is lost when replacing #!/bin/sh with #!/bin/bash. >> Might as well upgrade to a "real" programming language. > > Sure, but this bug seems to suggest that we *already* rely on > /bin/bash, but we pretend not to by assuming that /bin/sh runs > bash. If we rely on bash, let's be straight about it. > > Andrew. From gnu_andrew at member.fsf.org Tue Jun 3 11:15:14 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 3 Jun 2008 19:15:14 +0100 Subject: OpenJDK Build error on Ubuntu 8.04 In-Reply-To: <4845852E.6090508@sun.com> References: <1212433143.7870.6.camel@samkraju> <484445CD.7050700@sun.com> <4844FF4F.1060108@redhat.com> <1ccfd1c10806030955j4f71b37eua2bd60df5e887c8b@mail.gmail.com> <48457ABD.3000506@redhat.com> <4845852E.6090508@sun.com> Message-ID: <17c6771e0806031115m49ea3aces6175e0872da91b0f@mail.gmail.com> 2008/6/3 Kelly O'Hair : > As far as I know, only Ubuntu (and only 8.04?) depends on bash. > No other OS seems to have a problem using plain old antique sh. > > --- > > Ideally, these sh scripts used in the build process should be changed > to be something else, maybe small Java apps. Someday. > > -kto > The shift to using Ant already made the build more tricky IMO. Relying on Java for building Java even more just seems prone to problems, especially when it comes to bootstrapping. -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Tue Jun 3 11:32:27 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 3 Jun 2008 19:32:27 +0100 Subject: Relying on /bin/sh compatibility ? ... Re: OpenJDK Build error on Ubuntu 8.04 In-Reply-To: <484583E8.1070900@sun.com> References: <1212433143.7870.6.camel@samkraju> <484445CD.7050700@sun.com> <4844FF4F.1060108@redhat.com> <1ccfd1c10806030955j4f71b37eua2bd60df5e887c8b@mail.gmail.com> <48457ABD.3000506@redhat.com> <484583E8.1070900@sun.com> Message-ID: <17c6771e0806031132o5a6b04c3kaea13944d1d635b7@mail.gmail.com> > BTW does anybody know where to get a SHCK? (/bin/sh > Compatibility Kit) How can we be sure any /bin/sh interpreter is actually > compatible with /bin/sh ?? > > - David Herron > > > > I hear the license terms mean people can't really talk about the SHCK... -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Kelly.Ohair at Sun.COM Tue Jun 3 11:56:39 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 03 Jun 2008 11:56:39 -0700 Subject: OpenJDK Build error on Ubuntu 8.04 In-Reply-To: <17c6771e0806031115m49ea3aces6175e0872da91b0f@mail.gmail.com> References: <1212433143.7870.6.camel@samkraju> <484445CD.7050700@sun.com> <4844FF4F.1060108@redhat.com> <1ccfd1c10806030955j4f71b37eua2bd60df5e887c8b@mail.gmail.com> <48457ABD.3000506@redhat.com> <4845852E.6090508@sun.com> <17c6771e0806031115m49ea3aces6175e0872da91b0f@mail.gmail.com> Message-ID: <484593E7.4000308@sun.com> Java (BOOTJDK) is and will always be a requirement to build the JDK, can't see that ever going away. Many build tools are already written in Java (see jdk/make/tools) so I don't see how changing sh scripts to Java changes the build dependencies. As far as Ant goes, I have mixed feelings about it. But I'm becoming convinced that it has some big benefits when building Java code, and integrates better with the various IDEs. Just so I understand the issues, exactly how has the shift to Ant made the build more tricky for you? -kto Andrew John Hughes wrote: > 2008/6/3 Kelly O'Hair : >> As far as I know, only Ubuntu (and only 8.04?) depends on bash. >> No other OS seems to have a problem using plain old antique sh. >> >> --- >> >> Ideally, these sh scripts used in the build process should be changed >> to be something else, maybe small Java apps. Someday. >> >> -kto >> > > The shift to using Ant already made the build more tricky IMO. > Relying on Java for building Java even more just seems prone to > problems, > especially when it comes to bootstrapping. From aph at redhat.com Tue Jun 3 12:04:04 2008 From: aph at redhat.com (Andrew Haley) Date: Tue, 03 Jun 2008 20:04:04 +0100 Subject: Relying on /bin/sh compatibility ? ... Re: OpenJDK Build error on Ubuntu 8.04 In-Reply-To: <484583E8.1070900@sun.com> References: <1212433143.7870.6.camel@samkraju> <484445CD.7050700@sun.com> <4844FF4F.1060108@redhat.com> <1ccfd1c10806030955j4f71b37eua2bd60df5e887c8b@mail.gmail.com> <48457ABD.3000506@redhat.com> <484583E8.1070900@sun.com> Message-ID: <484595A4.9040509@redhat.com> David Herron wrote: > Andrew Haley wrote: >> Martin Buchholz wrote: >> >>> On Tue, Jun 3, 2008 at 1:22 AM, Andrew Haley wrote: >>> >>>> But if one of our scripts actually needs bash (not just sh) why not use >>>> #!/bin/bash ? >>>> >>> sh is a horrible programming language whose primary virtue is >>> portability -- every Unix system since the dark ages has it. >>> Much of that is lost when replacing #!/bin/sh with #!/bin/bash. >>> Might as well upgrade to a "real" programming language. >>> >> >> Sure, but this bug seems to suggest that we *already* rely on >> /bin/bash, but we pretend not to by assuming that /bin/sh runs >> bash. If we rely on bash, let's be straight about it. > er.. there's a little more to it than that, methinks. > > First, because it's /bin/sh that's portable (not /bin/bash) I believe > the shell scripts should be written for compatibility with /bin/sh No argument. > Second, it's an open question whether dash or bash does a better job of > implementing /bin/sh and I have no clue as to which does the better job. Ah, okay. My understanding was that dash is being correct in its implementation of sh, but the script was assuming more than just sh -- but I'm not a sh expert either. > I think it's either a) fix the script in question or b) fix dash. > > BTW does anybody know where to get a SHCK? (/bin/sh > Compatibility Kit) How can we be sure any /bin/sh interpreter is > actually compatible with /bin/sh ?? I use as a reference Kernighan & Pike, _The UNIX Programming Environment_, which has a "year zero" baseline of sh facilities. :-) Andrew. From martinrb at google.com Tue Jun 3 12:04:57 2008 From: martinrb at google.com (Martin Buchholz) Date: Tue, 3 Jun 2008 12:04:57 -0700 Subject: OpenJDK Build error on Ubuntu 8.04 In-Reply-To: <48457ABD.3000506@redhat.com> References: <1212433143.7870.6.camel@samkraju> <484445CD.7050700@sun.com> <4844FF4F.1060108@redhat.com> <1ccfd1c10806030955j4f71b37eua2bd60df5e887c8b@mail.gmail.com> <48457ABD.3000506@redhat.com> Message-ID: <1ccfd1c10806031204r2ccd6685tdfd4e4cd8dcf5fc9@mail.gmail.com> On Tue, Jun 3, 2008 at 10:09 AM, Andrew Haley wrote: > Martin Buchholz wrote: > Sure, but this bug seems to suggest that we *already* rely on > /bin/bash, but we pretend not to by assuming that /bin/sh runs > bash. If we rely on bash, let's be straight about it. What the JDK build process comes to rely upon is the intersection of the features of the commands available on the various systems where the JDK has historically been built. In the case of /bin/sh, that is the Solaris and bash (but *not* BSD) implementations of sh. Solaris is the "native" OS for Sun employees in the same way that Linux is the "native" OS for Red Hat employees. Martin From Erik.Trimble at Sun.COM Tue Jun 3 15:51:12 2008 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Tue, 03 Jun 2008 15:51:12 -0700 Subject: OpenJDK on Solaris Dev Express 1/2008? In-Reply-To: <48456304.5060302@sun.com> References: <0d1f01c8c491$7a462ae0$6ed280a0$@com> <4844151D.8030309@sun.com> <1212477453.18514.3.camel@imac523d.theobroma-systems.com> <48456304.5060302@sun.com> Message-ID: <4845CAE0.8000605@sun.com> Kelly O'Hair wrote: > I'm not sure what the state of the Makefiles are for building with gcc > on Solaris. It has been done in the past, from the artifacts I see in the > Makefiles, however, it won't 'just build', it will take some changes. > > In general we focus on one compiler set per OS, the one that has > the most potential for performance and makes the most sense for that OS. > Takes a great deal of testing and performance tests to 'validate' that > even a particular release of a compiler isn't regressing us. > > We will be going through that validation process as we change our > default JDK7 compilers to SS12 on Solaris, gcc4 on Linux, and > VS2008 on Windows. > > -kto > > Christian Thalinger wrote: >> On Mon, 2008-06-02 at 08:43 -0700, Kelly O'Hair wrote: >>> If SXDE contains Sun Studio 12 (SS12), you may have some problems >>> with compiling >>> hotspot. I've integrated some hotspot changes to deal with SS12 issues >>> http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/a49545cab84a >>> (hasn't been integrated into the master jdk7/jdk7 repositories yet). >>> >>> The rest of the jdk may compile file with SS12, but lots of warnings >>> about >>> the use of -xarch options, harmless but annoying. I'm working on the >>> rest >>> of the SS12 Makefile changes for the jdk, to get rid of these >>> warnings etc. >>> >>> If you can get a Sun Studio 11 installed, would be better right now. >>> >>> I used a previous version of SXDE to build OpenJDK a while back, but it >>> had SS11 in it at that time, so it was a while ago. >>> Looks like the latest SXDE includes Sun Studio Express compilers, which >>> are effectively SS12+ I assume. >> >> Is it possible to build OpenJDK for OpenSolaris with GCC? >> >> - twisti >> Followup to Kelly here: The Hotspot VM (which is (mostly) what is using the compiler), is set up to build with SunStudio 11. As Kelly notes, we're (well, actually, most He) is in the process of validating SS12 as a build compiler. GCC will NOT work under Solaris/SPARC, and I'm pretty darned sure it won't work under Solaris/x86 or Solaris/x64. There are some significant GCC-isms which the JDK does not currently support. That said, it would not be terribly difficult to modify the source to get GCC to work, but you'd definitely have to spend a bit of time doing so. Sadly, C compilers are not interchangeable. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From twisti at complang.tuwien.ac.at Wed Jun 4 04:16:27 2008 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Wed, 04 Jun 2008 13:16:27 +0200 Subject: OpenJDK on Solaris Dev Express 1/2008? In-Reply-To: <4845CAE0.8000605@sun.com> References: <0d1f01c8c491$7a462ae0$6ed280a0$@com> <4844151D.8030309@sun.com> <1212477453.18514.3.camel@imac523d.theobroma-systems.com> <48456304.5060302@sun.com> <4845CAE0.8000605@sun.com> Message-ID: <1212578187.12118.0.camel@imac523d.theobroma-systems.com> On Tue, 2008-06-03 at 15:51 -0700, Erik Trimble wrote: > The Hotspot VM (which is (mostly) what is using the compiler), is set up > to build with SunStudio 11. As Kelly notes, we're (well, actually, most > He) is in the process of validating SS12 as a build compiler. > > GCC will NOT work under Solaris/SPARC, and I'm pretty darned sure it > won't work under Solaris/x86 or Solaris/x64. There are some > significant GCC-isms which the JDK does not currently support. OK. > > That said, it would not be terribly difficult to modify the source to > get GCC to work, but you'd definitely have to spend a bit of time doing so. > > > Sadly, C compilers are not interchangeable. Yeah, I know :-/ - twisti From gnu_andrew at member.fsf.org Wed Jun 4 06:35:53 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 4 Jun 2008 14:35:53 +0100 Subject: OpenJDK on Solaris Dev Express 1/2008? In-Reply-To: <4845CAE0.8000605@sun.com> References: <0d1f01c8c491$7a462ae0$6ed280a0$@com> <4844151D.8030309@sun.com> <1212477453.18514.3.camel@imac523d.theobroma-systems.com> <48456304.5060302@sun.com> <4845CAE0.8000605@sun.com> Message-ID: <17c6771e0806040635o4711184er1a9e9c1eb0972d4b@mail.gmail.com> > GCC will NOT work under Solaris/SPARC, and I'm pretty darned sure it won't > work under Solaris/x86 or Solaris/x64. There are some significant GCC-isms > which the JDK does not currently support. > > That said, it would not be terribly difficult to modify the source to get > GCC to work, but you'd definitely have to spend a bit of time doing so. Maybe the next logical campaign is to avoid the Sun Studio trap then... :) -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Kelly.Ohair at Sun.COM Wed Jun 4 08:47:19 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 04 Jun 2008 08:47:19 -0700 Subject: OpenJDK on Solaris Dev Express 1/2008? In-Reply-To: <17c6771e0806040635o4711184er1a9e9c1eb0972d4b@mail.gmail.com> References: <0d1f01c8c491$7a462ae0$6ed280a0$@com> <4844151D.8030309@sun.com> <1212477453.18514.3.camel@imac523d.theobroma-systems.com> <48456304.5060302@sun.com> <4845CAE0.8000605@sun.com> <17c6771e0806040635o4711184er1a9e9c1eb0972d4b@mail.gmail.com> Message-ID: <4846B907.4010608@sun.com> Not sure what you mean by the Sun Studio trap. Each release of a compiler requires some kind of work to the Makefiles, happened with gcc4, and will happen with SS12 and VS2008. -kto Andrew John Hughes wrote: >> GCC will NOT work under Solaris/SPARC, and I'm pretty darned sure it won't >> work under Solaris/x86 or Solaris/x64. There are some significant GCC-isms >> which the JDK does not currently support. >> >> That said, it would not be terribly difficult to modify the source to get >> GCC to work, but you'd definitely have to spend a bit of time doing so. > > Maybe the next logical campaign is to avoid the Sun Studio trap then... :) From martinrb at google.com Wed Jun 4 16:08:47 2008 From: martinrb at google.com (Martin Buchholz) Date: Wed, 4 Jun 2008 16:08:47 -0700 Subject: Improper passing of variables to submake Message-ID: <1ccfd1c10806041608o71ce93cdj196332b93d268ada@mail.gmail.com> This is a bug report with patch. Tim or Kelly, please file a bug on my behalf, and review my fix. In OpenJDK7, If you do "make sanity" from the root of the forest, I get PREVIOUS_JDK_FILE = jdk--linux-i586.tar.gz ALT_PREVIOUS_JDK_FILE = PREVIOUS_JRE_FILE = jre--linux-i586.tar.gz ALT_PREVIOUS_JRE_FILE = If I do this from jdk/make, I get: PREVIOUS_JDK_FILE = jdk-6-linux-i586.tar.gz ALT_PREVIOUS_JDK_FILE = PREVIOUS_JRE_FILE = jre-6-linux-i586.tar.gz ALT_PREVIOUS_JRE_FILE = Why the difference? It's the same code generating these messages in both cases?!?! Analyzing the twisty maze of Makefiles, I see the "6" comes from PREVIOUS_JDK_UNDERSCORE_VERSION, which in turn comes from PREVIOUS_MINOR_VERSION. which is in turn initialized here: ifndef JDK_MINOR_VERSION JDK_MINOR_VERSION = 7 PREVIOUS_MINOR_VERSION = 6 endif The above code assumes that JDK_MINOR_VERSION is set if and only if PREVIOUS_MINOR_VERSION is set. However, that invariant is violated by the way makefile variables are passed to submakes via COMMON_BUILD_ARGUMENTS # Common make arguments (supplied to all component builds) COMMON_BUILD_ARGUMENTS = \ JDK_TOPDIR=$(ABS_JDK_TOPDIR) \ JDK_MAKE_SHARED_DIR=$(ABS_JDK_TOPDIR)/make/common/shared \ EXTERNALSANITYCONTROL=true \ TARGET_CLASS_VERSION=$(TARGET_CLASS_VERSION) \ MILESTONE=$(MILESTONE) \ BUILD_NUMBER=$(BUILD_NUMBER) \ JDK_BUILD_NUMBER=$(JDK_BUILD_NUMBER) \ FULL_VERSION=$(FULL_VERSION) \ PREVIOUS_JDK_VERSION=$(PREVIOUS_JDK_VERSION) \ JDK_VERSION=$(JDK_VERSION) \ JDK_MKTG_VERSION=$(JDK_MKTG_VERSION) \ JDK_MAJOR_VERSION=$(JDK_MAJOR_VERSION) \ JDK_MINOR_VERSION=$(JDK_MINOR_VERSION) \ JDK_MICRO_VERSION=$(JDK_MICRO_VERSION) which in turn makes the fix obvious (but we had better make sure to audit all the above variables for occurences of the same bug) (Note also that more serious consequences could come from the incorrect assignments to variables) # HG changeset patch # User martin # Date 1212620758 25200 # Node ID 33721e5e42170723d2ac66ed1d5929e688ea1404 # Parent 56652b46f328937f6b9b5130f1e4cd80f48868ef [mq]: MakeVariables.patch diff --git a/make/Defs-internal.gmk b/make/Defs-internal.gmk --- a/make/Defs-internal.gmk +++ b/make/Defs-internal.gmk @@ -225,7 +225,10 @@ JDK_MKTG_VERSION=$(JDK_MKTG_VERSION) \ JDK_MAJOR_VERSION=$(JDK_MAJOR_VERSION) \ JDK_MINOR_VERSION=$(JDK_MINOR_VERSION) \ - JDK_MICRO_VERSION=$(JDK_MICRO_VERSION) + JDK_MICRO_VERSION=$(JDK_MICRO_VERSION) \ + PREVIOUS_MAJOR_VERSION=$(PREVIOUS_MAJOR_VERSION) \ + PREVIOUS_MINOR_VERSION=$(PREVIOUS_MINOR_VERSION) \ + PREVIOUS_MICRO_VERSION=$(PREVIOUS_MICRO_VERSION) ifdef ARCH_DATA_MODEL COMMON_BUILD_ARGUMENTS += ARCH_DATA_MODEL=$(ARCH_DATA_MODEL) From martinrb at google.com Wed Jun 4 17:05:49 2008 From: martinrb at google.com (Martin Buchholz) Date: Wed, 4 Jun 2008 17:05:49 -0700 Subject: Removing vestigial MOTIF references from Makefiles Message-ID: <1ccfd1c10806041705y46e727e5i235684b44027551@mail.gmail.com> Kelly or Tim, here's a bug report with patch. Please file a bug and review my fix. Compiling jawt, I see an unintended and unlikely-to-succeed CPP flag -I/include The culprit appears to be a vestigial reference to the undefined MOTIF_DIR CPPFLAGS += -I$(OPENWIN_HOME)/include \ -I$(MOTIF_DIR)/include \ There are references to MOTIF_DIR and MOTIF_LIB in mawt.gmk as well, but I completely failed to understand what's going on there. Oh well. Perhaps we could motivate someone to expunge the MOTIF gunk left in there. Here's the fix: # HG changeset patch # User martin # Date 1212624109 25200 # Node ID 8d4107e89acb62063238f37ae6fa7226c00e9b2e # Parent b6601ba7f6dfe0d93e40b2891c581c30fdd92289 [mq]: NukeMotif.patch diff --git a/make/sun/jawt/Makefile b/make/sun/jawt/Makefile --- a/make/sun/jawt/Makefile +++ b/make/sun/jawt/Makefile @@ -93,7 +93,6 @@ # Other extra flags needed for compiling. # CPPFLAGS += -I$(OPENWIN_HOME)/include \ - -I$(MOTIF_DIR)/include \ -I$(SHARE_SRC)/native/$(PKGDIR)/debug \ -I$(SHARE_SRC)/native/$(PKGDIR)/image \ -I$(SHARE_SRC)/native/$(PKGDIR)/image/cvutils \ Here's the shell transcript excerpt Rebuilding /home/martinrb/ws/build/build/linux-i586/lib/i386/libjawt.so because of /home/martinrb/ws/build/build/linux-i586/tmp/sun/sun.awt/jawt/obj/.files_compiled mapfile-vers /usr/bin/gcc -O2 -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN -Di586 -DARCH='"i586"' -DLINUX -DRELEASE='"1.7.0-internal"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -I. -I/home/martinrb/ws/build/build/linux-i586/tmp/sun/sun.awt/jawt/CClassHeaders -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export -I../../../src/share/javavm/include -I../../../src/solaris/javavm/include -I../../../src/share/native/common -I../../../src/solaris/native/common -I../../../src/share/native/sun/awt -I../../../src/solaris/native/sun/awt -I/usr/X11R6/include -I/include -I../../../src/share/native/sun/awt/debug -I../../../src/share/native/sun/awt/image -I../../../src/share/native/sun/awt/image/cvutils -I../../../src/share/native/sun/awt/alphacomposite -I../../../src/share/native/sun/awt/medialib -I../../../src/solaris/native/sun/awt/medialib -I../../../src/share/native/sun/awt/../java2d/loops -I../../../src/share/native/sun/awt/../java2d/pipe -I../../../src/share/native/sun/awt/../java2d/opengl -I../../../src/solaris/native/sun/awt/../java2d/opengl -I../../../src/solaris/native/sun/awt/../java2d/x11 -I../../../src/share/native/sun/awt/../dc/doe -I../../../src/share/native/sun/awt/../dc/path -I../../../src/solaris/native/sun/awt/../jdga -Xlinker -O1 -Xlinker -version-script=mapfile-vers -Xlinker -z -Xlinker origin -Xlinker -rpath -Xlinker \$ORIGIN -z defs -L/home/martinrb/ws/build/build/linux-i586/lib/i386 -Wl,-soname=libjawt.so -shared -mimpure-text -o /home/martinrb/ws/build/build/linux-i586/lib/i386/libjawt.so /home/martinrb/ws/build/build/linux-i586/tmp/sun/sun.awt/jawt/obj/jawt.o -L/home/martinrb/ws/build/build/linux-i586/lib/i386 -lawt -L/home/martinrb/ws/build/build/linux-i586/lib/i386/xawt -lmawt -ljava -L/home/martinrb/ws/build/build/linux-i586/lib/i386/server -ljvm -lc From kelly.ohair at sun.com Wed Jun 4 17:51:41 2008 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Thu, 05 Jun 2008 00:51:41 +0000 Subject: hg: jdk7/build/corba: 6563752: Build and test JDK7 with Sun Studio 12 Express compilers (prep makefiles) Message-ID: <20080605005142.8283328FB5@hg.openjdk.java.net> Changeset: 9eeb4966acae Author: ohair Date: 2008-06-04 09:27 -0700 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/9eeb4966acae 6563752: Build and test JDK7 with Sun Studio 12 Express compilers (prep makefiles) Summary: Changes to support building with SS12. Reviewed-by: tbell ! make/common/shared/Compiler-sun.gmk ! make/jprt.config From Tim.Bell at Sun.COM Wed Jun 4 18:36:40 2008 From: Tim.Bell at Sun.COM (Tim Bell) Date: Wed, 04 Jun 2008 18:36:40 -0700 Subject: Improper passing of variables to submake In-Reply-To: <1ccfd1c10806041608o71ce93cdj196332b93d268ada@mail.gmail.com> References: <1ccfd1c10806041608o71ce93cdj196332b93d268ada@mail.gmail.com> Message-ID: <48474328.8070203@sun.com> Hi Martin: > In OpenJDK7, > If you do "make sanity" from the root of the forest, I get This is new bug-ID 6710904 "COMMON_BUILD_ARGUMENTS needs PREVIOUS_..._VERSION settings" It should be visible on http://bugs.sun.com/bugdatabase/ in 24 to 48 hours. Tim From Tim.Bell at Sun.COM Wed Jun 4 18:40:49 2008 From: Tim.Bell at Sun.COM (Tim Bell) Date: Wed, 04 Jun 2008 18:40:49 -0700 Subject: Removing vestigial MOTIF references from Makefiles In-Reply-To: <1ccfd1c10806041705y46e727e5i235684b44027551@mail.gmail.com> References: <1ccfd1c10806041705y46e727e5i235684b44027551@mail.gmail.com> Message-ID: <48474421.4070109@sun.com> Hi Martin: > Compiling jawt, I see an unintended and unlikely-to-succeed CPP flag > > -I/include This is new bug-ID 6710907 "vestigial MOTIF references from Makefiles" It should be visible on http://bugs.sun.com/bugdatabase/ in 24 to 48 hours. Tim From jesse.glick at sun.com Wed Jun 4 19:13:06 2008 From: jesse.glick at sun.com (Jesse Glick) Date: Wed, 04 Jun 2008 22:13:06 -0400 Subject: OpenJDK Build error on Ubuntu 8.04 In-Reply-To: <4845852E.6090508@sun.com> References: <1212433143.7870.6.camel@samkraju> <484445CD.7050700@sun.com> <4844FF4F.1060108@redhat.com> <1ccfd1c10806030955j4f71b37eua2bd60df5e887c8b@mail.gmail.com> <48457ABD.3000506@redhat.com> <4845852E.6090508@sun.com> Message-ID: Kelly O'Hair wrote: > these sh scripts used in the build process should be changed to be > something else, maybe small Java apps. Would also be nice to not name the version-controlled input files *.java when they are not in fact valid Java source. I am referring to the output of hg -R jdk loc -r tip '**/*-*.java' | fgrep -v package-info.java BTW the two Version-template.java's seem gratuitous; could just as easily put the version number into a .properties file loaded at runtime by the class, rather than running a preprocessor. From kelly.ohair at sun.com Wed Jun 4 21:15:14 2008 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Thu, 05 Jun 2008 04:15:14 +0000 Subject: hg: jdk7/build/jdk: 6563752: Build and test JDK7 with Sun Studio 12 Express compilers (prep makefiles) Message-ID: <20080605041545.B2A6028FDC@hg.openjdk.java.net> Changeset: f9467b4496dc Author: ohair Date: 2008-06-04 09:38 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/f9467b4496dc 6563752: Build and test JDK7 with Sun Studio 12 Express compilers (prep makefiles) Summary: Changes to support building with SS12. Reviewed-by: tbell ! make/common/Defs-solaris.gmk ! make/common/shared/Compiler-sun.gmk ! make/jdk_generic_profile.sh ! make/jprt.config From gnu_andrew at member.fsf.org Thu Jun 5 04:09:47 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 5 Jun 2008 12:09:47 +0100 Subject: OpenJDK on Solaris Dev Express 1/2008? In-Reply-To: <4846B907.4010608@sun.com> References: <0d1f01c8c491$7a462ae0$6ed280a0$@com> <4844151D.8030309@sun.com> <1212477453.18514.3.camel@imac523d.theobroma-systems.com> <48456304.5060302@sun.com> <4845CAE0.8000605@sun.com> <17c6771e0806040635o4711184er1a9e9c1eb0972d4b@mail.gmail.com> <4846B907.4010608@sun.com> Message-ID: <17c6771e0806050409g2ceab10fj35902f0d78cd5f04@mail.gmail.com> 2008/6/4 Kelly O'Hair : > Not sure what you mean by the Sun Studio trap. > I'm referring back to the Java trap - before Sun released their JDK under the GPL, it was possible to have applications under a Free Software license written in Java which couldn't be run in a Free environment because they would only work under the proprietary JDK. GNU Classpath was the community's attempt to free Java from this trap. Only being able to build the OpenJDK using the proprietary Sun Studio compiler on Solaris creates a similar issue, though the scope of the problem is fortunately more restricted. I'm not sure OpenSolaris itself can even be built with GCC, which is an even worse issue - it's not truly Free Software if it can only be built with proprietary tools. > Each release of a compiler requires some kind of work to the Makefiles, > happened with gcc4, and will happen with SS12 and VS2008. > While I can understand some changes being necessary for major releases (e.g. the move from GCC 3 to 4), every single release shouldn't need work; this suggest an issue with the build system itself. > -kto > > Andrew John Hughes wrote: >>> >>> GCC will NOT work under Solaris/SPARC, and I'm pretty darned sure it >>> won't >>> work under Solaris/x86 or Solaris/x64. There are some significant >>> GCC-isms >>> which the JDK does not currently support. >>> >>> That said, it would not be terribly difficult to modify the source to get >>> GCC to work, but you'd definitely have to spend a bit of time doing so. >> >> Maybe the next logical campaign is to avoid the Sun Studio trap then... :) > -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Erik.Trimble at Sun.COM Thu Jun 5 05:23:16 2008 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Thu, 05 Jun 2008 05:23:16 -0700 Subject: OpenJDK on Solaris Dev Express 1/2008? In-Reply-To: <17c6771e0806050409g2ceab10fj35902f0d78cd5f04@mail.gmail.com> References: <0d1f01c8c491$7a462ae0$6ed280a0$@com> <4844151D.8030309@sun.com> <1212477453.18514.3.camel@imac523d.theobroma-systems.com> <48456304.5060302@sun.com> <4845CAE0.8000605@sun.com> <17c6771e0806040635o4711184er1a9e9c1eb0972d4b@mail.gmail.com> <4846B907.4010608@sun.com> <17c6771e0806050409g2ceab10fj35902f0d78cd5f04@mail.gmail.com> Message-ID: <4847DAB4.20008@sun.com> Andrew John Hughes wrote: > 2008/6/4 Kelly O'Hair : > >> Not sure what you mean by the Sun Studio trap. >> >> > > I'm referring back to the Java trap - before Sun released their JDK > under the GPL, > it was possible to have applications under a Free Software license > written in Java > which couldn't be run in a Free environment because they would only work under > the proprietary JDK. GNU Classpath was the community's attempt to free Java > from this trap. > > Only being able to build the OpenJDK using the proprietary Sun Studio > compiler on Solaris creates > a similar issue, though the scope of the problem is fortunately more > restricted. I'm not sure OpenSolaris > itself can even be built with GCC, which is an even worse issue - it's > not truly Free Software if it can only > be built with proprietary tools. > > This is NOT a trap. This is a CHOICE OF PREFERENCE made by the FS Community. It is no more a trap than using GPL'd programs in conjunction with the Apache http server is. Just because we don't play exactly in your world doesn't mean there is a trap. Traps are when you cannot replace a whole component layer easily with something else. So, if your GPL'd Java program had to run on a Sun JDK under Solaris, that would certainly be true. However, you can run your Java program on one of about 4 major JDKs now, under over a dozen OSes, so that hardly qualifies as a trap. Remember, not everyone wants everything in one particular format (or, license). We've got end-users who can't stand the GPL, for some _very_ good reasons. We've got other folks who are sore at us for not using an MPL-style license. So, I take license-criticism extremely poorly. >> Each release of a compiler requires some kind of work to the Makefiles, >> happened with gcc4, and will happen with SS12 and VS2008. >> > > While I can understand some changes being necessary for major releases > (e.g. the move from GCC 3 to 4), > every single release shouldn't need work; this suggest an issue with > the build system itself. > Sadly, no, this is an issue with the COMPILERS, not the make system. GCC, SS, and all other compilers has a nasty tendency to subtly break all sorts of things without rev-ing the major version number. In GCCs case, this is often directly related to changes in GLIBC, particularly on Linux. GCC has some bad (recent) history, as major changes were implemented without obvious notice, with no major version bump, and occasionally with no minor version bump either. gcc 3.2 is considerably different than 3.3 or 3.4. And, in Microsoft's case, their myriad of different compiler 'distros' within the same general release (i.e. Visual Studio vs Express vs VS Professional) is even worse, as they support very different library sets and compiler flags. So, every time we want to support a new compiler, there's some work to be done to discover these differences, and adjust the makefiles to compensate. It would certainly be nice for the JDK to be able to build with more than one compiler on any given platform. But that's what a community is for - people interested in using a specific compiler should certainly not be prevented from doing so. Our (Sun's) interest is primarily in supporting our own compilers. That said, the make system could use some serious streamlining, and the code itself could _really_ do a much better job of disentangling itself, so that it could be built in a more modular form. >> Andrew John Hughes wrote: >> >>>> GCC will NOT work under Solaris/SPARC, and I'm pretty darned sure it >>>> won't >>>> work under Solaris/x86 or Solaris/x64. There are some significant >>>> GCC-isms >>>> which the JDK does not currently support. >>>> >>>> That said, it would not be terribly difficult to modify the source to get >>>> GCC to work, but you'd definitely have to spend a bit of time doing so. >>>> >>> Maybe the next logical campaign is to avoid the Sun Studio trap then... :) >>> -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From aph at redhat.com Thu Jun 5 05:57:12 2008 From: aph at redhat.com (Andrew Haley) Date: Thu, 05 Jun 2008 13:57:12 +0100 Subject: OpenJDK on Solaris Dev Express 1/2008? In-Reply-To: <4847DAB4.20008@sun.com> References: <0d1f01c8c491$7a462ae0$6ed280a0$@com> <4844151D.8030309@sun.com> <1212477453.18514.3.camel@imac523d.theobroma-systems.com> <48456304.5060302@sun.com> <4845CAE0.8000605@sun.com> <17c6771e0806040635o4711184er1a9e9c1eb0972d4b@mail.gmail.com> <4846B907.4010608@sun.com> <17c6771e0806050409g2ceab10fj35902f0d78cd5f04@mail.gmail.com> <4847DAB4.20008@sun.com> Message-ID: <4847E2A8.7030102@redhat.com> Erik Trimble wrote: > Andrew John Hughes wrote: >> 2008/6/4 Kelly O'Hair : >> >>> Not sure what you mean by the Sun Studio trap. >> >> I'm referring back to the Java trap - before Sun released their JDK >> under the GPL, it was possible to have applications under a Free >> Software license written in Java which couldn't be run in a Free >> environment because they would only work under the proprietary JDK. >> GNU Classpath was the community's attempt to free Java from this >> trap. >> Only being able to build the OpenJDK using the proprietary Sun >> Studio compiler on Solaris creates a similar issue, though the >> scope of the problem is fortunately more restricted. I'm not sure >> OpenSolaris itself can even be built with GCC, which is an even >> worse issue - it's not truly Free Software if it can only be built >> with proprietary tools. > This is NOT a trap. This is a CHOICE OF PREFERENCE made by the FS > Community. It is no more a trap than using GPL'd programs in > conjunction with the Apache http server is. Just because we don't play > exactly in your world doesn't mean there is a trap. Traps are when you > cannot replace a whole component layer easily with something else. So, > if your GPL'd Java program had to run on a Sun JDK under Solaris, that > would certainly be true. However, you can run your Java program on one > of about 4 major JDKs now, under over a dozen OSes, so that hardly > qualifies as a trap. > > Remember, not everyone wants everything in one particular format (or, > license). We've got end-users who can't stand the GPL, for some _very_ > good reasons. We've got other folks who are sore at us for not using an > MPL-style license. So, I take license-criticism extremely poorly. I don't think he was, actually: he was just talking about not wanting to depend on unfree software; Apache is free software, as is gcc, as is OpenSolaris, as is OpenJDK. He didn't mention the GPL at all; you did. Andrew. From mark at klomp.org Thu Jun 5 06:23:59 2008 From: mark at klomp.org (Mark Wielaard) Date: Thu, 05 Jun 2008 15:23:59 +0200 Subject: OpenJDK on Solaris Dev Express 1/2008? In-Reply-To: <4847DAB4.20008@sun.com> References: <0d1f01c8c491$7a462ae0$6ed280a0$@com> <4844151D.8030309@sun.com> <1212477453.18514.3.camel@imac523d.theobroma-systems.com> <48456304.5060302@sun.com> <4845CAE0.8000605@sun.com> <17c6771e0806040635o4711184er1a9e9c1eb0972d4b@mail.gmail.com> <4846B907.4010608@sun.com> <17c6771e0806050409g2ceab10fj35902f0d78cd5f04@mail.gmail.com> <4847DAB4.20008@sun.com> Message-ID: <1212672239.3138.22.camel@dijkstra.wildebeest.org> Hi Erik, On Thu, 2008-06-05 at 05:23 -0700, Erik Trimble wrote: > Andrew John Hughes wrote: > > 2008/6/4 Kelly O'Hair : > > > >> Not sure what you mean by the Sun Studio trap. > > > > I'm referring back to the Java trap - before Sun released their JDK > > under the GPL, > > it was possible to have applications under a Free Software license > > written in Java > > which couldn't be run in a Free environment because they would only work under > > the proprietary JDK. GNU Classpath was the community's attempt to free Java > > from this trap. > > > > Only being able to build the OpenJDK using the proprietary Sun Studio > > compiler on Solaris creates > > a similar issue, though the scope of the problem is fortunately more > > restricted. I'm not sure OpenSolaris > > itself can even be built with GCC, which is an even worse issue - it's > > not truly Free Software if it can only > > be built with proprietary tools. > > > > > This is NOT a trap. This is a CHOICE OF PREFERENCE made by the FS > Community. It is no more a trap than using GPL'd programs in > conjunction with the Apache http server is. I don't think the point was about different free software licenses at all. That is as you say just a choice of preference of which free software license a community choices to use as default. In general free software hackers seem pretty open minded about these things in my experience. > Just because we don't play > exactly in your world doesn't mean there is a trap. Traps are when you > cannot replace a whole component layer easily with something else. Where that something else is also free software of course. > So, > if your GPL'd Java program had to run on a Sun JDK under Solaris, that > would certainly be true. However, you can run your Java program on one > of about 4 major JDKs now, under over a dozen OSes, so that hardly > qualifies as a trap. It certainly seems a lesser trap, since it only impacts users of systems like solaris and windows that are already non-free. But we now do have OpenJDK and we do want it to be truly free for all users. It is questionable whether Windows will ever be completely liberated (but it might happen ultimately trough Wine and cygwin/mingw). But for OpenSolaris it seems within reach right now, if we wouldn't be relying on a proprietary toolchain on that platfrom. I agree with Andrew that using a proprietary compiler instead of a free one (whether that is distributed under a BSD, GPL or Apache style license) seems like trouble in the long run. It is ultimately the same kind of trap if you are relying on extensions of a proprietary toolchain, then you are not giving your users real freedom. If at all possible, and if we can find volunteers to do it of course, it would be beneficial to use a free toolchain on all platforms that OpenJDK support imho. Cheers, Mark From Joel.Feraud at Sun.COM Thu Jun 5 07:01:51 2008 From: Joel.Feraud at Sun.COM (=?ISO-8859-1?Q?Jo=EBl_F=C9RAUD?=) Date: Thu, 05 Jun 2008 16:01:51 +0200 Subject: Target "gnumake images" broken in jdk7/tl/jdk Message-ID: <4847F1CF.7040506@Sun.COM> Hi, I sync nightly my jdk7/tl/jdk repository with http://hg.openjdk.java.net/jdk7/tl/jdk and build it nightly (gnumake all images). The target "images" is broken since I pulled 2 days ago this changeset: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f494f33398f1 "6708729: update jdk Makefiles for new javap" The build error is: [...] /jmgt/mirror/jdk/6_05/promoted/latest/binaries/solaris-sparcv9/bin/jar c0f /jmgt/user/hg/repositories/jdk7/tl-local/jdk/build/solaris-sparc/lib/tools.jar -C [...] \ -J-client -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m /jmgt/user/hg/repositories/jdk7/tl-local/jdk/build/solaris-sparc/classes/com/sun/tools/classfile : no such file or directory /jmgt/user/hg/repositories/jdk7/tl-local/jdk/build/solaris-sparc/classes/com/sun/tools/javap : no such file or directory gnumake: *** [initial-image-jdk] Error 1 Anybody else having noticed this problem? Thanks, Joel From Kelly.Ohair at Sun.COM Thu Jun 5 07:58:00 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 05 Jun 2008 07:58:00 -0700 Subject: OpenJDK Build error on Ubuntu 8.04 In-Reply-To: References: <1212433143.7870.6.camel@samkraju> <484445CD.7050700@sun.com> <4844FF4F.1060108@redhat.com> <1ccfd1c10806030955j4f71b37eua2bd60df5e887c8b@mail.gmail.com> <48457ABD.3000506@redhat.com> <4845852E.6090508@sun.com> Message-ID: <4847FEF8.7040501@sun.com> I suspect (a long time ago) they did it this way for a reason, and in fact as I think about it, they probably wanted the version baked into a string constant rather than reading it from a file at startup, for performance reasons. That concern may still exist. The whole 'generated source' situation is a bit hectic if you ask me. I would like to see a consistent way that generated java sources are handled, and maybe this one should just be another one of those generated files that ends up in the tmp/gensrc area. I completely agree than anything ending in .java should be a valid java source file. -kto Jesse Glick wrote: > Kelly O'Hair wrote: >> these sh scripts used in the build process should be changed to be >> something else, maybe small Java apps. > > Would also be nice to not name the version-controlled input files *.java > when they are not in fact valid Java source. I am referring to the > output of > > hg -R jdk loc -r tip '**/*-*.java' | fgrep -v package-info.java > > BTW the two Version-template.java's seem gratuitous; could just as > easily put the version number into a .properties file loaded at runtime > by the class, rather than running a preprocessor. > From gnu_andrew at member.fsf.org Thu Jun 5 08:24:49 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 5 Jun 2008 16:24:49 +0100 Subject: OpenJDK on Solaris Dev Express 1/2008? In-Reply-To: <4847DAB4.20008@sun.com> References: <0d1f01c8c491$7a462ae0$6ed280a0$@com> <4844151D.8030309@sun.com> <1212477453.18514.3.camel@imac523d.theobroma-systems.com> <48456304.5060302@sun.com> <4845CAE0.8000605@sun.com> <17c6771e0806040635o4711184er1a9e9c1eb0972d4b@mail.gmail.com> <4846B907.4010608@sun.com> <17c6771e0806050409g2ceab10fj35902f0d78cd5f04@mail.gmail.com> <4847DAB4.20008@sun.com> Message-ID: <17c6771e0806050824r1e6a7a84m80e883d54b3c41fe@mail.gmail.com> 2008/6/5 Erik Trimble : > Andrew John Hughes wrote: >> >> 2008/6/4 Kelly O'Hair : >> >>> >>> Not sure what you mean by the Sun Studio trap. >>> >>> >> >> I'm referring back to the Java trap - before Sun released their JDK >> under the GPL, >> it was possible to have applications under a Free Software license >> written in Java >> which couldn't be run in a Free environment because they would only work >> under >> the proprietary JDK. GNU Classpath was the community's attempt to free >> Java >> from this trap. >> >> Only being able to build the OpenJDK using the proprietary Sun Studio >> compiler on Solaris creates >> a similar issue, though the scope of the problem is fortunately more >> restricted. I'm not sure OpenSolaris >> itself can even be built with GCC, which is an even worse issue - it's >> not truly Free Software if it can only >> be built with proprietary tools. >> >> > > This is NOT a trap. This is a CHOICE OF PREFERENCE made by the FS > Community. It is no more a trap than using GPL'd programs in conjunction > with the Apache http server is. Just because we don't play exactly in your > world doesn't mean there is a trap. Traps are when you cannot replace a > whole component layer easily with something else. So, if your GPL'd Java > program had to run on a Sun JDK under Solaris, that would certainly be true. > However, you can run your Java program on one of about 4 major JDKs now, > under over a dozen OSes, so that hardly qualifies as a trap. > > Remember, not everyone wants everything in one particular format (or, > license). We've got end-users who can't stand the GPL, for some _very_ good > reasons. We've got other folks who are sore at us for not using an MPL-style > license. So, I take license-criticism extremely poorly. > Andrew Haley already made the point very succinctly. I wasn't discussing specific licenses or Java applications, but the specific issue of building the OpenJDK on OpenSolaris. It's a different and more specific trap, but one nonetheless. On the bright side, I think fixing it is much more tenable. >>> Each release of a compiler requires some kind of work to the Makefiles, >>> happened with gcc4, and will happen with SS12 and VS2008. >>> >> >> While I can understand some changes being necessary for major releases >> (e.g. the move from GCC 3 to 4), >> every single release shouldn't need work; this suggest an issue with >> the build system itself. >> > > Sadly, no, this is an issue with the COMPILERS, not the make system. GCC, > SS, and all other compilers has a nasty tendency to subtly break all sorts > of things without rev-ing the major version number. In GCCs case, this is > often directly related to changes in GLIBC, particularly on Linux. GCC has > some bad (recent) history, as major changes were implemented without obvious > notice, with no major version bump, and occasionally with no minor version > bump either. gcc 3.2 is considerably different than 3.3 or 3.4. And, in > Microsoft's case, their myriad of different compiler 'distros' within the > same general release (i.e. Visual Studio vs Express vs VS Professional) is > even worse, as they support very different library sets and compiler flags. > So, every time we want to support a new compiler, there's some work to be > done to discover these differences, and adjust the makefiles to compensate. > > It would certainly be nice for the JDK to be able to build with more than > one compiler on any given platform. But that's what a community is for - > people interested in using a specific compiler should certainly not be > prevented from doing so. Our (Sun's) interest is primarily in supporting > our own compilers. > > That said, the make system could use some serious streamlining, and the code > itself could _really_ do a much better job of disentangling itself, so that > it could be built in a more modular form. > Exactly; the reason for highlighting such issues openly on a mailing list is so problems can be worked on by the community. I don't think it's Sun's job alone to go and fix it, and likewise I would see Sun as part of the community not a distinct entity from it. >>> Andrew John Hughes wrote: >>> >>>>> >>>>> GCC will NOT work under Solaris/SPARC, and I'm pretty darned sure it >>>>> won't >>>>> work under Solaris/x86 or Solaris/x64. There are some significant >>>>> GCC-isms >>>>> which the JDK does not currently support. >>>>> >>>>> That said, it would not be terribly difficult to modify the source to >>>>> get >>>>> GCC to work, but you'd definitely have to spend a bit of time doing so. >>>>> >>>> >>>> Maybe the next logical campaign is to avoid the Sun Studio trap then... >>>> :) >>>> > > > -- > Erik Trimble > Java System Support > Mailstop: usca22-123 > Phone: x17195 > Santa Clara, CA > Timezone: US/Pacific (GMT-0800) > > -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Kelly.Ohair at Sun.COM Thu Jun 5 11:37:31 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 05 Jun 2008 11:37:31 -0700 Subject: OpenJDK on Solaris Dev Express 1/2008? In-Reply-To: <17c6771e0806050409g2ceab10fj35902f0d78cd5f04@mail.gmail.com> References: <0d1f01c8c491$7a462ae0$6ed280a0$@com> <4844151D.8030309@sun.com> <1212477453.18514.3.camel@imac523d.theobroma-systems.com> <48456304.5060302@sun.com> <4845CAE0.8000605@sun.com> <17c6771e0806040635o4711184er1a9e9c1eb0972d4b@mail.gmail.com> <4846B907.4010608@sun.com> <17c6771e0806050409g2ceab10fj35902f0d78cd5f04@mail.gmail.com> Message-ID: <4848326B.70607@sun.com> Andrew John Hughes wrote: > 2008/6/4 Kelly O'Hair : >> Not sure what you mean by the Sun Studio trap. >> > > I'm referring back to the Java trap - before Sun released their JDK > under the GPL, > it was possible to have applications under a Free Software license > written in Java > which couldn't be run in a Free environment because they would only work under > the proprietary JDK. GNU Classpath was the community's attempt to free Java > from this trap. > > Only being able to build the OpenJDK using the proprietary Sun Studio > compiler on Solaris creates > a similar issue, though the scope of the problem is fortunately more > restricted. I'm not sure OpenSolaris > itself can even be built with GCC, which is an even worse issue - it's > not truly Free Software if it can only > be built with proprietary tools. Ah... the pure "open source" trap. Now I understand. The Sun Studio compilers are free, not yet open source, but they are free. Not sure what their schedule is for open sourcing. So this situation is not as bad as Windows. :^( > >> Each release of a compiler requires some kind of work to the Makefiles, >> happened with gcc4, and will happen with SS12 and VS2008. >> > > While I can understand some changes being necessary for major releases > (e.g. the move from GCC 3 to 4), > every single release shouldn't need work; this suggest an issue with > the build system itself. Well, when they get to the point where a native compiler release can be done without a single bug or compiler option change, I'll probably be dead, and well decomposed. :^{ The Hotspot C++ code in particular pushes the native compilers hard, using very high optimization levels, and is itself a test of a C++ compiler. Even if you get past the build, strange runtime interactions between the Hotspot generated code and the C++ generated code will test all the assumptions made by both the optimization teams working on these very disjoint products. It's often not a question of quality of code of one or the other, but the complex interactions between the two. -kto > >> -kto >> >> Andrew John Hughes wrote: >>>> GCC will NOT work under Solaris/SPARC, and I'm pretty darned sure it >>>> won't >>>> work under Solaris/x86 or Solaris/x64. There are some significant >>>> GCC-isms >>>> which the JDK does not currently support. >>>> >>>> That said, it would not be terribly difficult to modify the source to get >>>> GCC to work, but you'd definitely have to spend a bit of time doing so. >>> Maybe the next logical campaign is to avoid the Sun Studio trap then... :) > > > From Tim.Bell at Sun.COM Thu Jun 5 11:42:52 2008 From: Tim.Bell at Sun.COM (Tim Bell) Date: Thu, 05 Jun 2008 11:42:52 -0700 Subject: Target "gnumake images" broken in jdk7/tl/jdk In-Reply-To: <4847F1CF.7040506@Sun.COM> References: <4847F1CF.7040506@Sun.COM> Message-ID: <484833AC.2070602@sun.com> Hi Jo?l: > I sync nightly my jdk7/tl/jdk repository with > http://hg.openjdk.java.net/jdk7/tl/jdk and build it nightly (gnumake all > images). I created a disposable tree by cloning http://hg.openjdk.java.net/jdk7/tl/jdk, and I am checking on this. Note that this will not affect my b29 integration tomorrow because this push is not part of that batch of changes. 6708729 is targeted for b30. Tim > The target "images" is broken since I pulled 2 days ago this changeset: > http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f494f33398f1 "6708729: update > jdk Makefiles for new javap" > > The build error is: > [...] > /jmgt/mirror/jdk/6_05/promoted/latest/binaries/solaris-sparcv9/bin/jar > c0f > /jmgt/user/hg/repositories/jdk7/tl-local/jdk/build/solaris-sparc/lib/tools.jar > -C [...] \ > -J-client -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m > -J-XX:MaxPermSize=160m > /jmgt/user/hg/repositories/jdk7/tl-local/jdk/build/solaris-sparc/classes/com/sun/tools/classfile > : no such file or directory > /jmgt/user/hg/repositories/jdk7/tl-local/jdk/build/solaris-sparc/classes/com/sun/tools/javap > : no such file or directory > gnumake: *** [initial-image-jdk] Error 1 > > Anybody else having noticed this problem? > > Thanks, > Joel From rob.ross at gmail.com Thu Jun 5 14:20:24 2008 From: rob.ross at gmail.com (Rob Ross) Date: Thu, 5 Jun 2008 14:20:24 -0700 Subject: Building OpenJDK 7 on Windows XP In-Reply-To: <08b201c8bc94$d411fef0$7c35fcd0$@com> References: <4831A048.2070201@sun.com> <40CBB608-257A-4B9C-B903-4CC513B985DB@gmail.com> <08b201c8bc94$d411fef0$7c35fcd0$@com> Message-ID: <48492DD9-90A8-46AE-AB34-B3128E41B688@gmail.com> I don't know if I responded to you already, so if I did, sorry for the duplicate. I think your site covers the process pretty well. I think it would be nice if you could include a link to the binaries for Freetype2 in- line in your description, since most of us don't have a nice friend Igor to do this for us :) Building Freetype2 in the way that the build process and runtime environment expected was one of the harder things for me to figure out, and although I did eventually, it's soooo unrelated to the rest of the OpenJDK build process which is already chock-full of pitfalls. I expect this code will eventually make its way into the native build process so it will be just another native lib built when you run make. (If you do include the binaries make sure they've been compiled in an unencumbered way - there are flags you can set for TrueType font processing that use proprietary technology.) Also, even though you discuss the variable path syntax issues, the only way I was able to debug these issues was one variable at a time until I understood what that variable was being used for, and by what environment (Java, cygwin, Windows, etc). Other than these things I think your description covers everything. Although, I did have some kind of deadlocking problem when running gmake. It spawns multiple gmake processes, and at some point this caused my build to come to a halt until I killed one, then the rest of the processes were able to continue. Of course, the process I killed did not complete its make tasks, so ultimately the build would fail. After repeated attempts at doing a make all, I was finally able to get all build targets to complete successfully and end up with a build. I tried to pass in the gmake flag for limiting the number of jobs gmake can spawn but it seems to be completely ignored by cygwin gmake (v3.80). Rob Ross, Lead Software Engineer E! Networks --------------------------------------------------- "Beware of he who would deny you access to information, for in his heart he dreams himself your master." -- Commissioner Pravin Lal On May 22, 2008, at 10:21 PM, Ted Neward wrote: > Now.... check out > http://blogs.tedneward.com/2007/12/15/Let+The+JDK+Hacking > +Begin.aspx (sorry > I didn't see your email sooner, but I've been AFK for a while), and > tell me > if I left anything out of the process. > > Ted Neward > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.tedneward.com > > >> -----Original Message----- >> From: build-dev-bounces at openjdk.java.net [mailto:build-dev- >> bounces at openjdk.java.net] On Behalf Of Rob Ross >> Sent: Tuesday, May 20, 2008 3:43 AM >> To: Kelly O'Hair >> Cc: build-dev >> Subject: Re: Building OpenJDK 7 on Windows XP >> >> Well I'm happy to report I finally got the full build to work, >> although it took another 15 hours or so. >> >> The last two big issues I encountered: >> >> 1. Unfamiliarity with the freetype project, so had to figure out what >> needed to be built. This project is rather complicated. It supports >> building on at least 11 platforms, and allows for multiple compilers/ >> environments on many of these platforms. There are 14 different build >> systems supported on Windows alone! >> >> Also, this project is highly configurable, and you can build it with >> support for many optional features. So someone from the OpenJDK >> architecture team will have to decide what is officially included in >> this library when it is built for the OpenJDK project. And the build >> code for it will have to be included in the jdk7 Makefile system. >> >> I was able to build it by tweaking the VC 8 file included, and >> opening in VS .Net 2003. I compiled from within VS, then ran the link >> script I found via a link in this list's archive to create the >> freetype.dll and freetype.lib. The "aha" moment was when I realized >> there were actually TWO .lib files being created, a large static one >> aroung 800K, and a smaller one around 40K. I needed to use the >> smaller one along with the dll. >> >> 2. This is most likely a cygwin issue, but I continually experienced >> deadlocks/starvation of the spawned gmake processes. cygwin's gmake >> seems to ignore the -j option. At any one time I could have a bash >> process, a few shell processes, and up to 9 gmake processes running. >> I could easily tell when a deadlock occurred - my computer would go >> from sounding like a jet engine to being totally quiet. Then I tried >> to guess what gmake process was the oldest (not sure if window's task >> manager sorts them by process ID or creation time, so this is just a >> guess) and killed that one, and then the build would continue, but >> obviously with errors as some task was not completed. >> >> I had to try to rebuild more than 5 times before it finally got >> through it all. But in the end it completed with no errors. >> >> java -version worked! Good start >> >> java HelloWorld worked! Getting better. >> >> Going for it, I tried SwingSet2 and Java2D demos from the 1.6 JDK.. >> AND THEY WORKED! >> >> I did get an error in the Java2D demo complaining about missing a >> JPEG decoder, but I was too happy the build had worked to really >> worry about that right now. >> >> So add another success story to this list. >> >> >> Rob Ross, Lead Software Engineer >> E! Networks >> >> --------------------------------------------------- >> "Beware of he who would deny you access to information, for in his >> heart he dreams himself your master." -- Commissioner Pravin Lal >> >> >> >> On May 19, 2008, at 8:44 AM, Kelly O'Hair wrote: >> >>> >>> >>> Rob Ross wrote: >>>> Hi there everyone. >>>> This will officially be my first email to the OpenJDK project. >>> >>> Welcome. I actually appreciate the email, some comments below. >>> >>>> I got to attend a couple of sessions/BOFs at JavaOne2008 about >>>> OpenJDK and my interest was piqued. I've been playing with the >>>> build for the last week. (A more accurate description would be, >>>> "yanking my hair out and cursing my computer quite often", but I >>>> supposed it's part of the learning curve.) >>> >>> You did pick the most difficult platform you know. ;^) >>> >>> These are the notes and action items I see from your comments: >>> >>> 1. assembling the prerequisite software >>> - VS .Net 2003 - Will be changing soon to a newer VC compiler, >>> and if >>> at all possible the free one. >>> - Ant is a requirement, I'll fix the Build README, findbugs is >>> not strictly >>> a requirement, it's under discussion, I had hoped to use it as >>> part of the build. >>> I may be removing the sanity check on findbugs. >>> - Cygwin is a bit of a challenge, it changes/updates rather >>> often, I'll >>> try and correct the references to the packages you mention, but >>> it's like the different Linux packages, sometimes all I can >>> give is hints. >>> - The Build README should have some references to the older >>> cygwin 'make' >>> now, but I'll double check. I kind of hoped it would fix itself >>> someday. :^( >>> - Freetype is new to many of us, I use a freetype that someone >>> else built >>> so I have never experienced building it myself. >>> I will try and look into this and see if I can document it >> better. >>> >>> 2. Mercurial >>> - CVS/Subversion users seem to have trouble understanding the >>> distributed >>> nature of Mercurial. I'd recommend looking at the first few >>> chapters >>> of the Mercurial book: http://hgbook.red-bean.com/hgbook.html >>> >>> 3. Setting up the ALT_* environment variables >>> - If I didn't document this I should have, my apologies, but I >>> encourage >>> all ALT_* variables to use the C:/ style of paths, not C:\ and >>> definitely >>> not the /cygdrive/ style paths. >>> The makefiles try and turn the C:\ paths into C:/, but using >>> the cygwin >>> paths are more difficult to deal with. >>> The problem is that some of the exe's we use understand these >>> paths and >>> some don't, almost everything understands C:/, and avoiding the >>> use of >>> \ characters in shell scripts and Makefiles is a very sane >>> thing to do. >>> Making matters worse, the cygwin 'make' that stopped working >>> with C: >>> paths for a while, hopefully this gets fixed someday. >>> Of course cygwin PATH must use ':' characters to separate >>> paths, so >>> you have to use /cygdrive/ paths in PATH. >>> The LIB and INCLUDE env variables belong to the VS2003 compiler >>> and >>> they use a ';' separator and need the C:/ paths. >>> See my blog: >>> http://blogs.sun.com/kto/entry/windows_cygwin_mks_java_and >>> >>> I suspect that your experience with MacOS X will not be the same as >>> Windows. >>> >>> Thanks for taking the time to make the comments. >>> >>> -kto >>> >>>> I was finally able to get "make sanity" to pass this evening, and >>>> I felt quite pleased with myself. However, I have no expectations >>>> that this will actually build now - but I still consider this a >>>> milestone victory. >>>> Some of the difficulties I encountered were >>>> 1. Just assembling the prerequisite software >>>> The jdk7/README-builds.html actually does a fairly good job of >>>> listing everything needed. But I'm not a Windows developer, so >>>> finding a copy of VS .Net 2003 was a little challenging. Luckily >>>> that install process was pretty simple. The build generates a >>>> warning if Ant and FindBugs aren't locatable; those were easy to >>>> install but perhaps you should add these programs to the list of >>>> requirements in the README. Cygwin was also >>>> pretty easy to install after spending a little time reading up on >>>> it. Finding an earlier version of make (gmake) was a little hard, >>>> but I see now there are links in the mailing list archive so that >>>> would be useful to add a link to the README as well. Some of the >>>> Categories/package names you gave for the particular cygwin >>>> utilities needed may be out of date. Zip and Unzip are found in >>>> the Archive category, not Utils as described in the README. "Free" >>>> is listed as being in Utils but it's actually part of the "procps" >>>> package, under the System category. And there isn't an "awk" >>>> implementation, but there is a gawk. Freetype was the bane of my >>>> existence for 3 days. I never could get the "stock" build scripts >>>> to work with the version you stated was needed (2.3.0), and what >>>> was available to be downloaded (2.3.5). I could not figure out how >>>> to build it from source either via DOS/windows or cygwin. So I >>>> ended up downloading the binary setup executable, which contained >>>> freetype.lib, freetype6.dll, and zlib1.dll, and a freetype.dll.a >>>> that was a red herring. I modified the Makefile for the >>>> freetypecheck tool to change the name of the expected dll from >>>> "freetype.dll" to "freetype6.dll", and added its dependent >>>> "zlib1.dll" to the copy command. Not a very portable solution I >>>> know, but I just wanted to get this thing to work! How is everyone >>>> else getting this to compile? >>>> 2. Mercurial - well, it's new, and a little more complicated than >>>> CVS/SVN, but I think I'll get the hang of it. I fcloned from the >>>> jdk7 master forest, (using the forest extension) yesterday, so I >>>> have the latest code (baring any changes in the last day). It will >>>> be a while before I even have to worry about wanting to submit >>>> anything back upstream, so I should be more comfortable with how >>>> it all works by then. >>>> 3. Setting up the ALT_* environment variables >>>> The hardest part, and mostly trial-and-error, was determining what >>>> variables needed to use the cygwin path syntax, and what needed to >>>> use the normal Windows path syntax, and what needed to be >>>> "shortcutted" by using the cygpath utility. This was mind >>>> numbingly frustrating!!!! I found an email from Tim Bell that >>>> included his sample script that was quite helpful in getting the >>>> right directories from the VS .Net 2003 install into the PATH, >>>> LIB, and INCLUDE variables, with the right syntax. As I was >>>> writing this email my initial "gmake all" build failed, due to >>>> javac not being able to find the binary plugins I had specified in >>>> ALT_BINARY_PLUGINS_PATH. It seems THAT one needs to be a java IO >>>> file path! So now there are THREE different path syntaxes in use >>>> in this script file :) >>>> Anyway, I just wanted to share my experiences building the OpenJDK >>>> 7 on Windows. >>>> Ironically, I'm only doing this to get some practice on the >>>> existing build process. My ultimate goal is to port the OpenJDK 7 >>>> to Mac OS X, as a full native app. I'm doing some preliminary >>>> analysis on the existing code base to determine all calls to >>>> native methods, to get a sense of the scope. For example, there >>>> are currently about 421 native method calls in the jdk/src/share >>>> classes. The Windows implementation classes make 210 native calls, >>>> and the Solaris implementation makes 299. But the first task would >>>> be to integrate Mac OS build targets into the OpenJDK 7 project, >>>> so it can be built on that platform. (Of course, it won't actually >>>> run without any native implementation - that's step #2.) But I'll >>>> be making a more formal presentation/declaration/request for >>>> sponsorship/ at a later time. >>>> Rob Ross >> >> No virus found in this incoming message. >> Checked by AVG. >> Version: 7.5.524 / Virus Database: 269.23.21/1454 - Release Date: >> 5/19/2008 7:44 AM >> > > No virus found in this outgoing message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.24.0/1460 - Release Date: > 5/22/2008 > 7:06 AM > > From rob.ross at gmail.com Thu Jun 5 14:54:51 2008 From: rob.ross at gmail.com (Rob Ross) Date: Thu, 5 Jun 2008 14:54:51 -0700 Subject: OpenJDK Build error on Ubuntu 8.04 In-Reply-To: <484593E7.4000308@sun.com> References: <1212433143.7870.6.camel@samkraju> <484445CD.7050700@sun.com> <4844FF4F.1060108@redhat.com> <1ccfd1c10806030955j4f71b37eua2bd60df5e887c8b@mail.gmail.com> <48457ABD.3000506@redhat.com> <4845852E.6090508@sun.com> <17c6771e0806031115m49ea3aces6175e0872da91b0f@mail.gmail.com> <484593E7.4000308@sun.com> Message-ID: <432F5771-9855-47EE-ABF7-128FD305DEA6@gmail.com> Is there any documentation of the build architecture, in terms of what needs to be built first, and how those build products are then used to build the rest of the system? Sorry if these are FAQ-type questions, I'm still trying to figure out how this all works. Is the requirement for an existing JDK an architectural requirement, or is that just how the dependencies of the build system have evolved over time? *Could* the build system be designed in such a way that the early generated native tools can be built completely from native sources, which are then used to start building the Java portions? I can see the benefits/pitfalls of the two different philosophies. 1. Assume an existing JDK, which is used early in the process. This allows the build process to leverage existing Java tools and libraries (from an earlier version of the JDK) and could make it easier to develop cross-platform build processes, as well as easier to port new versions of the JDK to existing JDK platforms. 2. Assume no existing JDK, build the smallest native kernel required, then through a combination of further native compilation and javac compilation, bootstrap itself to the point where it can then build the rest of the JDK. Point 2 is probably harder to engineer, but would make it easier to port to new platforms. Point 1 would make the build process for new versions of OpenJDK simpler to implement in a cross platform way, but would make porting to brand new platforms very difficult. Actually, you'd have to have some special build process for bootstrapping to a new platform. But this is basically the situation you have right now, isn't it? Also, would it be correct to think about this build process as having exactly two types of build trees - a native portion (built with native compiler tools) and a Java portion, built with javac and JDK tools, that have been built from the native step? On the native part, I'll just assume the status quo make files and such are the best way of handling this. But for all the Java tasks and packaging and Java code generation, wouldn't an all-Java build process be simpler to implement and maintain? I don't have a lot of experience with make, but it seems very archaic and inefficient. I use Ant on a daily basis, and I'm not very enthusiastic about that either. I don't think a declarative programming style lends itself well to writing build systems. I think a scripting language would make it much easier, something like Groovy perhaps. I'm just asking these questions in the context of what would be ideal. I understand there is a lot of work invested in the current build system and it would not be trivial to re-implement it. But I'm thinking of this specifically for a Mac OS X port, and how this would fit in with the OpenJDK project, and whether it would be better to just start with a new build system for this port, that might then evolve enough to be useful for the general OpenJDK case. Again, just high-level pie-in-the-sky thinking for the moment. Rob Ross, Lead Software Engineer E! Networks --------------------------------------------------- "Beware of he who would deny you access to information, for in his heart he dreams himself your master." -- Commissioner Pravin Lal On Jun 3, 2008, at 11:56 AM, Kelly O'Hair wrote: > Java (BOOTJDK) is and will always be a requirement to build the JDK, > can't see that ever going away. > > Many build tools are already written in Java (see jdk/make/tools) > so I don't see how changing sh scripts to Java changes the build > dependencies. > > As far as Ant goes, I have mixed feelings about it. But I'm becoming > convinced that it has some big benefits when building Java code, and > integrates better with the various IDEs. > > Just so I understand the issues, exactly how has the shift to Ant made > the build more tricky for you? > > -kto > > Andrew John Hughes wrote: >> 2008/6/3 Kelly O'Hair : >>> As far as I know, only Ubuntu (and only 8.04?) depends on bash. >>> No other OS seems to have a problem using plain old antique sh. >>> >>> --- >>> >>> Ideally, these sh scripts used in the build process should be >>> changed >>> to be something else, maybe small Java apps. Someday. >>> >>> -kto >>> >> The shift to using Ant already made the build more tricky IMO. >> Relying on Java for building Java even more just seems prone to >> problems, >> especially when it comes to bootstrapping. From Tim.Bell at Sun.COM Fri Jun 6 10:27:33 2008 From: Tim.Bell at Sun.COM (Tim Bell) Date: Fri, 06 Jun 2008 10:27:33 -0700 Subject: Target "gnumake images" broken in jdk7/tl/jdk In-Reply-To: <484833AC.2070602@sun.com> References: <4847F1CF.7040506@Sun.COM> <484833AC.2070602@sun.com> Message-ID: <48497385.6080806@sun.com> Jo?l wrote: >> The target "images" is broken since I pulled 2 days ago this changeset: >> http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f494f33398f1 "6708729: >> update jdk Makefiles for new javap" >> >> The build error is: >> [...] >> /jmgt/mirror/jdk/6_05/promoted/latest/binaries/solaris-sparcv9/bin/jar >> c0f >> /jmgt/user/hg/repositories/jdk7/tl-local/jdk/build/solaris-sparc/lib/tools.jar >> -C [...] \ >> -J-client -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m >> -J-XX:MaxPermSize=160m >> /jmgt/user/hg/repositories/jdk7/tl-local/jdk/build/solaris-sparc/classes/com/sun/tools/classfile >> : no such file or directory >> /jmgt/user/hg/repositories/jdk7/tl-local/jdk/build/solaris-sparc/classes/com/sun/tools/javap >> : no such file or directory >> gnumake: *** [initial-image-jdk] Error 1 >> >> Anybody else having noticed this problem? After sleeping on this issue I believe I understand what is happening. When you build only tl/jdk the other pieces are assembled from the latest promoted JDK. The new classes Jon added for 6708729/6439940 are not there yet, so they are not pulled over. The build fails later when trying to assemble tools.jar. The following statement applies only to the jdk7/tl forest: until b30 is promoted, you _must_ build (at least) langtools plus jdk to get the new classes added. You may build the rest (corba hotspot jaxp jaxws etc...) if you wish. Tim From Jonathan.Gibbons at Sun.COM Fri Jun 6 10:36:51 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Fri, 06 Jun 2008 10:36:51 -0700 Subject: Target "gnumake images" broken in jdk7/tl/jdk In-Reply-To: <48497385.6080806@sun.com> References: <4847F1CF.7040506@Sun.COM> <484833AC.2070602@sun.com> <48497385.6080806@sun.com> Message-ID: <7EFD5D87-0C47-49D5-AFF2-7BFAD6C5A9F4@sun.com> Tim, That looks like a reasonable analysis. I've been thinking if there is any better way we could have staged the bits here, but this really does seem like a chicken and egg problem. The only thing that would have avoided this problem is to weaken the requirement that all the imported packages exist, but for the most part, that sounds like a good check to have. Fortunately, we don't get to add packages too often! -- Jon On Jun 6, 2008, at 10:27 AM, Tim Bell wrote: > Jo?l wrote: > >>> The target "images" is broken since I pulled 2 days ago this >>> changeset: >>> http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f494f33398f1 "6708729: >>> update jdk Makefiles for new javap" >>> >>> The build error is: >>> [...] >>> /jmgt/mirror/jdk/6_05/promoted/latest/binaries/solaris-sparcv9/bin/ >>> jar c0f /jmgt/user/hg/repositories/jdk7/tl-local/jdk/build/solaris- >>> sparc/lib/tools.jar -C [...] \ >>> -J-client -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J- >>> XX:MaxPermSize=160m >>> /jmgt/user/hg/repositories/jdk7/tl-local/jdk/build/solaris-sparc/ >>> classes/com/sun/tools/classfile : no such file or directory >>> /jmgt/user/hg/repositories/jdk7/tl-local/jdk/build/solaris-sparc/ >>> classes/com/sun/tools/javap : no such file or directory >>> gnumake: *** [initial-image-jdk] Error 1 >>> >>> Anybody else having noticed this problem? > > After sleeping on this issue I believe I understand what is happening. > > When you build only tl/jdk the other pieces are assembled from the > latest promoted JDK. > The new classes Jon added for 6708729/6439940 are not there yet, so > they are not pulled > over. The build fails later when trying to assemble tools.jar. > > The following statement applies only to the jdk7/tl forest: until > b30 is promoted, you _must_ > build (at least) langtools plus jdk to get the new classes added. > > You may build the rest (corba hotspot jaxp jaxws etc...) if you wish. > > Tim > From Joel.Feraud at Sun.COM Mon Jun 9 06:39:58 2008 From: Joel.Feraud at Sun.COM (=?ISO-8859-1?Q?Jo=EBl_F=C9RAUD?=) Date: Mon, 09 Jun 2008 15:39:58 +0200 Subject: Target "gnumake images" broken in jdk7/tl/jdk In-Reply-To: <48497385.6080806@sun.com> References: <4847F1CF.7040506@Sun.COM> <484833AC.2070602@sun.com> <48497385.6080806@sun.com> Message-ID: <484D32AE.3030202@Sun.COM> Makes sense! Thanks Tim. Joel Tim Bell wrote: > Jo?l wrote: > >>> The target "images" is broken since I pulled 2 days ago this changeset: >>> http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f494f33398f1 "6708729: >>> update jdk Makefiles for new javap" >>> >>> The build error is: >>> [...] >>> /jmgt/mirror/jdk/6_05/promoted/latest/binaries/solaris-sparcv9/bin/jar >>> c0f >>> /jmgt/user/hg/repositories/jdk7/tl-local/jdk/build/solaris-sparc/lib/tools.jar >>> -C [...] \ >>> -J-client -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m >>> -J-XX:MaxPermSize=160m >>> /jmgt/user/hg/repositories/jdk7/tl-local/jdk/build/solaris-sparc/classes/com/sun/tools/classfile >>> : no such file or directory >>> /jmgt/user/hg/repositories/jdk7/tl-local/jdk/build/solaris-sparc/classes/com/sun/tools/javap >>> : no such file or directory >>> gnumake: *** [initial-image-jdk] Error 1 >>> >>> Anybody else having noticed this problem? > > After sleeping on this issue I believe I understand what is happening. > > When you build only tl/jdk the other pieces are assembled from the > latest promoted JDK. > The new classes Jon added for 6708729/6439940 are not there yet, so they > are not pulled > over. The build fails later when trying to assemble tools.jar. > > The following statement applies only to the jdk7/tl forest: until b30 is > promoted, you _must_ > build (at least) langtools plus jdk to get the new classes added. > > You may build the rest (corba hotspot jaxp jaxws etc...) if you wish. > > Tim > From dgrove at google.com Tue Jun 10 14:46:10 2008 From: dgrove at google.com (Dan Grove) Date: Tue, 10 Jun 2008 14:46:10 -0700 Subject: openjdk b28 changes Message-ID: Hi- In the b28 drop, I see that the directory structure of the tarball changed to have everything under openjdk. In previous releases, hotspot & friends were all at the top level of the zip file, and now they're under openjdk. Will future releases maintain this new structure? In addition, it seems that there's some new stuff that's been left in the tarball like this: openjdk/langtools/.hgignore#1 - add default change (text) openjdk//langtools/.hgtags#1 - add default change (text) openjdk//langtools/.jcheck/conf#1 - add default change (text) Do you happen to know if this stuff was left in the zip file on purpose? Thanks! Dan From Kelly.Ohair at Sun.COM Tue Jun 10 16:15:13 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 10 Jun 2008 16:15:13 -0700 Subject: openjdk b28 changes In-Reply-To: References: Message-ID: <484F0B01.4050402@sun.com> Dan Grove wrote: > Hi- > > In the b28 drop, I see that the directory structure of the tarball > changed to have everything under openjdk. In previous releases, > hotspot & friends were all at the top level of the zip file, and now > they're under openjdk. Will future releases maintain this new > structure? Hopefully yes. This bundle logic is now baked into the build process. Sorry about the change. > > In addition, it seems that there's some new stuff that's been left in > the tarball like this: > > openjdk/langtools/.hgignore#1 - add default change (text) > openjdk//langtools/.hgtags#1 - add default change (text) > openjdk//langtools/.jcheck/conf#1 - add default change (text) Humm.. probably should not be there, but harmless. I'll CC Jonathan maybe he will do something here, or comment. > > Do you happen to know if this stuff was left in the zip file on purpose? > No not on purpose that I know of, the creation of the openjdk source bundles from the Mercurial repositories is pretty simple. The clones are created, the ".hg" directory is deleted, and the source is bundled up. No filtering is done, any file managed by Mercurial will be in the source bundle. Figured that was the best way to go. -kto > Thanks! > Dan From Jonathan.Gibbons at Sun.COM Tue Jun 10 16:30:38 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 10 Jun 2008 16:30:38 -0700 Subject: openjdk b28 changes In-Reply-To: <484F0B01.4050402@sun.com> References: <484F0B01.4050402@sun.com> Message-ID: <484F0E9E.5030002@sun.com> Kelly O'Hair wrote: > > > Dan Grove wrote: > >> >> In addition, it seems that there's some new stuff that's been left in >> the tarball like this: >> >> openjdk/langtools/.hgignore#1 - add default change (text) >> openjdk//langtools/.hgtags#1 - add default change (text) >> openjdk//langtools/.jcheck/conf#1 - add default change (text) > > Humm.. probably should not be there, but harmless. I'll CC Jonathan > maybe he will do something here, or comment. > I've no idea what these files are or where they've come from. I've just tried a fresh clean pull from tl/langtools and do not see any files like these. -- Jon From dgrove at google.com Tue Jun 10 16:35:22 2008 From: dgrove at google.com (Dan Grove) Date: Tue, 10 Jun 2008 16:35:22 -0700 Subject: openjdk b28 changes In-Reply-To: <484F0E9E.5030002@sun.com> References: <484F0B01.4050402@sun.com> <484F0E9E.5030002@sun.com> Message-ID: Hi Jon- Here's what I get when I unzip the b28 build: find . -name .hg\* ./openjdk/.hgignore ./openjdk/.hgtags ./openjdk/corba/.hgignore ./openjdk/corba/.hgtags ./openjdk/hotspot/.hgignore ./openjdk/hotspot/.hgtags ./openjdk/jaxp/.hgignore ./openjdk/jaxp/.hgtags ./openjdk/jaxws/.hgignore ./openjdk/jaxws/.hgtags ./openjdk/jdk/.hgignore ./openjdk/jdk/.hgtags ./openjdk/langtools/.hgignore ./openjdk/langtools/.hgtags On Tue, Jun 10, 2008 at 4:30 PM, Jonathan Gibbons wrote: > Kelly O'Hair wrote: >> >> >> Dan Grove wrote: >> >>> >>> In addition, it seems that there's some new stuff that's been left in >>> the tarball like this: >>> >>> openjdk/langtools/.hgignore#1 - add default change (text) >>> openjdk//langtools/.hgtags#1 - add default change (text) >>> openjdk//langtools/.jcheck/conf#1 - add default change (text) >> >> Humm.. probably should not be there, but harmless. I'll CC Jonathan >> maybe he will do something here, or comment. >> > > I've no idea what these files are or where they've come from. I've just > tried a fresh clean pull from tl/langtools and do not see any files like > these. > > -- Jon > From Jonathan.Gibbons at Sun.COM Tue Jun 10 17:37:42 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 10 Jun 2008 17:37:42 -0700 Subject: openjdk b28 changes In-Reply-To: References: <484F0B01.4050402@sun.com> <484F0E9E.5030002@sun.com> Message-ID: <484F1E56.6080108@sun.com> Dan, Those files look reasonable, from a Mercurial perspective. I thought we were worried about files with weird names in the langtools repository, such as openjdk/langtools/.hgignore#1 - add default change (text) openjdk//langtools/.hgtags#1 - add default change (text) Arguably, these files you are seeing should be removed from the source bundle as well. Kelly? -- Jon Dan Grove wrote: > Hi Jon- > > Here's what I get when I unzip the b28 build: > > find . -name .hg\* > > ./openjdk/.hgignore > ./openjdk/.hgtags > ./openjdk/corba/.hgignore > ./openjdk/corba/.hgtags > ./openjdk/hotspot/.hgignore > ./openjdk/hotspot/.hgtags > ./openjdk/jaxp/.hgignore > ./openjdk/jaxp/.hgtags > ./openjdk/jaxws/.hgignore > ./openjdk/jaxws/.hgtags > ./openjdk/jdk/.hgignore > ./openjdk/jdk/.hgtags > ./openjdk/langtools/.hgignore > ./openjdk/langtools/.hgtags > > > On Tue, Jun 10, 2008 at 4:30 PM, Jonathan Gibbons > wrote: > >> Kelly O'Hair wrote: >> >>> Dan Grove wrote: >>> >>> >>>> In addition, it seems that there's some new stuff that's been left in >>>> the tarball like this: >>>> >>>> openjdk/langtools/.hgignore#1 - add default change (text) >>>> openjdk//langtools/.hgtags#1 - add default change (text) >>>> openjdk//langtools/.jcheck/conf#1 - add default change (text) >>>> >>> Humm.. probably should not be there, but harmless. I'll CC Jonathan >>> maybe he will do something here, or comment. >>> >>> >> I've no idea what these files are or where they've come from. I've just >> tried a fresh clean pull from tl/langtools and do not see any files like >> these. >> >> -- Jon >> >> From Kelly.Ohair at Sun.COM Tue Jun 10 17:45:44 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 10 Jun 2008 17:45:44 -0700 Subject: openjdk b28 changes In-Reply-To: References: <484F0B01.4050402@sun.com> <484F0E9E.5030002@sun.com> Message-ID: <484F2038.5020007@sun.com> Those are files used by Mercurial, and are actually managed files in the repositories. I could exclude them, but then I have to go down that slippery slope of dealing with what files get filtered from the open source bundles and which don't. So unless these files are extremely objectionable, I'd rather leave the source bundling logic pretty simple, including all managed Mercurial files in the bundles. Let me know if that's ok. -kto P.S. .hgignore is an exclusion list of files and directories that Mercurial should never manage. And .hgtags contains the Mercurial tag->changset mappings. Dan Grove wrote: > Hi Jon- > > Here's what I get when I unzip the b28 build: > > find . -name .hg\* > > ./openjdk/.hgignore > ./openjdk/.hgtags > ./openjdk/corba/.hgignore > ./openjdk/corba/.hgtags > ./openjdk/hotspot/.hgignore > ./openjdk/hotspot/.hgtags > ./openjdk/jaxp/.hgignore > ./openjdk/jaxp/.hgtags > ./openjdk/jaxws/.hgignore > ./openjdk/jaxws/.hgtags > ./openjdk/jdk/.hgignore > ./openjdk/jdk/.hgtags > ./openjdk/langtools/.hgignore > ./openjdk/langtools/.hgtags > > > On Tue, Jun 10, 2008 at 4:30 PM, Jonathan Gibbons > wrote: >> Kelly O'Hair wrote: >>> >>> Dan Grove wrote: >>> >>>> In addition, it seems that there's some new stuff that's been left in >>>> the tarball like this: >>>> >>>> openjdk/langtools/.hgignore#1 - add default change (text) >>>> openjdk//langtools/.hgtags#1 - add default change (text) >>>> openjdk//langtools/.jcheck/conf#1 - add default change (text) >>> Humm.. probably should not be there, but harmless. I'll CC Jonathan >>> maybe he will do something here, or comment. >>> >> I've no idea what these files are or where they've come from. I've just >> tried a fresh clean pull from tl/langtools and do not see any files like >> these. >> >> -- Jon >> From martin at xemacs.org Tue Jun 10 17:09:21 2008 From: martin at xemacs.org (martin at xemacs.org) Date: Wed, 11 Jun 2008 00:09:21 +0000 Subject: hg: jdk7/build: 6710904: COMMON_BUILD_ARGUMENTS needs PREVIOUS_..._VERSION settings Message-ID: <20080611000922.02D9F28852@hg.openjdk.java.net> Changeset: bf6ee1d9127e Author: martin Date: 2008-06-10 16:30 -0700 URL: http://hg.openjdk.java.net/jdk7/build/rev/bf6ee1d9127e 6710904: COMMON_BUILD_ARGUMENTS needs PREVIOUS_..._VERSION settings Reviewed-by: ohair, tbell ! make/Defs-internal.gmk From martin at xemacs.org Tue Jun 10 17:11:58 2008 From: martin at xemacs.org (martin at xemacs.org) Date: Wed, 11 Jun 2008 00:11:58 +0000 Subject: hg: jdk7/build/jdk: 2 new changesets Message-ID: <20080611001237.1483828859@hg.openjdk.java.net> Changeset: a5c908deb70f Author: martin Date: 2008-06-10 16:31 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/a5c908deb70f 6710907: vestigial MOTIF references from Makefiles Reviewed-by: ohair, tbell ! make/sun/jawt/Makefile Changeset: a0d703b249f0 Author: martin Date: 2008-06-10 16:31 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/a0d703b249f0 6704165: JDK_DEBUG_IMAGE_DIR used in jdk/make/common/Release.gmk but not defined Reviewed-by: ohair, tbell ! make/common/Release.gmk From martinrb at google.com Tue Jun 10 18:09:10 2008 From: martinrb at google.com (Martin Buchholz) Date: Tue, 10 Jun 2008 18:09:10 -0700 Subject: hg: jdk7/build/jdk: 2 new changesets In-Reply-To: <20080611001237.1483828859@hg.openjdk.java.net> References: <20080611001237.1483828859@hg.openjdk.java.net> Message-ID: <1ccfd1c10806101809n62b9fa67w4c740eb0bc677eab@mail.gmail.com> Hi OpenJDK administrators, I did my last hg push from a Google machine. I have no idea why mercurial notification thinks I am martin at xemacs.org. I'd like to have control over my identity, and these days I'd like to be known as "Martin Buchholz ". Martin On Tue, Jun 10, 2008 at 5:11 PM, wrote: From dgrove at google.com Tue Jun 10 18:39:07 2008 From: dgrove at google.com (Dan Grove) Date: Tue, 10 Jun 2008 18:39:07 -0700 Subject: openjdk b28 changes In-Reply-To: <484F2038.5020007@sun.com> References: <484F0B01.4050402@sun.com> <484F0E9E.5030002@sun.com> <484F2038.5020007@sun.com> Message-ID: Hi Kelly and Jon- It's fine with me to have those left in there - I just wanted to be sure that they weren't a sign of some other badness in the zip file. Thanks for your help! Dan On Tue, Jun 10, 2008 at 5:45 PM, Kelly O'Hair wrote: > Those are files used by Mercurial, and are actually managed files > in the repositories. > > I could exclude them, but then I have to go down that slippery > slope of dealing with what files get filtered from the open source > bundles and which don't. > So unless these files are extremely objectionable, I'd rather leave > the source bundling logic pretty simple, including all managed Mercurial > files in the bundles. > > Let me know if that's ok. > > -kto > > P.S. .hgignore is an exclusion list of files and directories that Mercurial > should never manage. > And .hgtags contains the Mercurial tag->changset mappings. > > Dan Grove wrote: >> >> Hi Jon- >> >> Here's what I get when I unzip the b28 build: >> >> find . -name .hg\* >> >> ./openjdk/.hgignore >> ./openjdk/.hgtags >> ./openjdk/corba/.hgignore >> ./openjdk/corba/.hgtags >> ./openjdk/hotspot/.hgignore >> ./openjdk/hotspot/.hgtags >> ./openjdk/jaxp/.hgignore >> ./openjdk/jaxp/.hgtags >> ./openjdk/jaxws/.hgignore >> ./openjdk/jaxws/.hgtags >> ./openjdk/jdk/.hgignore >> ./openjdk/jdk/.hgtags >> ./openjdk/langtools/.hgignore >> ./openjdk/langtools/.hgtags >> >> >> On Tue, Jun 10, 2008 at 4:30 PM, Jonathan Gibbons >> wrote: >>> >>> Kelly O'Hair wrote: >>>> >>>> Dan Grove wrote: >>>> >>>>> In addition, it seems that there's some new stuff that's been left in >>>>> the tarball like this: >>>>> >>>>> openjdk/langtools/.hgignore#1 - add default change (text) >>>>> openjdk//langtools/.hgtags#1 - add default change (text) >>>>> openjdk//langtools/.jcheck/conf#1 - add default change (text) >>>> >>>> Humm.. probably should not be there, but harmless. I'll CC Jonathan >>>> maybe he will do something here, or comment. >>>> >>> I've no idea what these files are or where they've come from. I've just >>> tried a fresh clean pull from tl/langtools and do not see any files like >>> these. >>> >>> -- Jon >>> > From mr at sun.com Wed Jun 11 14:53:28 2008 From: mr at sun.com (Mark Reinhold) Date: Wed, 11 Jun 2008 14:53:28 -0700 Subject: hg: jdk7/build/jdk: 2 new changesets In-Reply-To: martinrb@google.com; Tue, 10 Jun 2008 18:09:10 PDT; <1ccfd1c10806101809n62b9fa67w4c740eb0bc677eab@mail.gmail.com> Message-ID: <20080611215328.D818E5FD5@eggemoggin.niobe.net> > Date: Tue, 10 Jun 2008 18:09:10 -0700 > From: Martin Buchholz > I did my last hg push from a Google machine. > I have no idea why mercurial notification thinks I am martin at xemacs.org. Because that's the address you entered when you originally registered. > I'd like to have control over my identity, and these days > I'd like to be known as "Martin Buchholz ". In the long run we'll have a web interface which will allow you to update such information. For now I've updated the database manually. - Mark From martinrb at google.com Wed Jun 11 15:09:04 2008 From: martinrb at google.com (Martin Buchholz) Date: Wed, 11 Jun 2008 15:09:04 -0700 Subject: hg: jdk7/build/jdk: 2 new changesets In-Reply-To: <20080611215328.D818E5FD5@eggemoggin.niobe.net> References: <1ccfd1c10806101809n62b9fa67w4c740eb0bc677eab@mail.gmail.com> <20080611215328.D818E5FD5@eggemoggin.niobe.net> Message-ID: <1ccfd1c10806111509i77044cf0ked96571915f49f46@mail.gmail.com> On Wed, Jun 11, 2008 at 2:53 PM, Mark Reinhold wrote: >> Date: Tue, 10 Jun 2008 18:09:10 -0700 >> From: Martin Buchholz > >> I did my last hg push from a Google machine. >> I have no idea why mercurial notification thinks I am martin at xemacs.org. > > Because that's the address you entered when you originally registered. Ah. I guess my memory is not what it used to be. The mailing addresses are presumably not available on http://db.openjdk.java.net/people for spam/privacy reasons. Thanks for updating my entry. Martin From mr at sun.com Wed Jun 11 15:10:50 2008 From: mr at sun.com (Mark Reinhold) Date: Wed, 11 Jun 2008 15:10:50 -0700 Subject: hg: jdk7/build/jdk: 2 new changesets In-Reply-To: martinrb@google.com; Wed, 11 Jun 2008 15:09:04 PDT; <1ccfd1c10806111509i77044cf0ked96571915f49f46@mail.gmail.com> Message-ID: <20080611221050.8A5355FD5@eggemoggin.niobe.net> > Date: Wed, 11 Jun 2008 15:09:04 -0700 > From: Martin Buchholz > On Wed, Jun 11, 2008 at 2:53 PM, Mark Reinhold wrote: >>> Date: Tue, 10 Jun 2008 18:09:10 -0700 >>> From: Martin Buchholz >> >>> I did my last hg push from a Google machine. >>> I have no idea why mercurial notification thinks I am martin at xemacs.org. >> >> Because that's the address you entered when you originally registered. > > Ah. I guess my memory is not what it used to be. > The mailing addresses are presumably not available on > http://db.openjdk.java.net/people > for spam/privacy reasons. Exactly. > Thanks for updating my entry. No problem. - Mark From xiomara.jayasena at sun.com Thu Jun 12 11:52:23 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Thu, 12 Jun 2008 18:52:23 +0000 Subject: hg: jdk7/build: 2 new changesets Message-ID: <20080612185223.EE3BC2891E@hg.openjdk.java.net> Changeset: 8fc9d057bd12 Author: xdono Date: 2008-06-10 10:16 -0700 URL: http://hg.openjdk.java.net/jdk7/build/rev/8fc9d057bd12 Added tag jdk7-b28 for changeset 56652b46f328 ! .hgtags Changeset: 31e08f70e88d Author: xdono Date: 2008-06-12 11:46 -0700 URL: http://hg.openjdk.java.net/jdk7/build/rev/31e08f70e88d Merge From xiomara.jayasena at sun.com Thu Jun 12 11:53:23 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Thu, 12 Jun 2008 18:53:23 +0000 Subject: hg: jdk7/build/corba: 2 new changesets Message-ID: <20080612185325.541E628923@hg.openjdk.java.net> Changeset: c4dd5b7198b0 Author: xdono Date: 2008-06-10 10:17 -0700 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/c4dd5b7198b0 Added tag jdk7-b28 for changeset 27509b7d21ed ! .hgtags Changeset: 8b71960f79ce Author: xdono Date: 2008-06-12 11:46 -0700 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/8b71960f79ce Merge From xiomara.jayasena at sun.com Thu Jun 12 11:55:14 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Thu, 12 Jun 2008 18:55:14 +0000 Subject: hg: jdk7/build/hotspot: Added tag jdk7-b28 for changeset c14dab40ed9b Message-ID: <20080612185518.110CF28928@hg.openjdk.java.net> Changeset: abe7181cbe8a Author: xdono Date: 2008-06-10 10:22 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/abe7181cbe8a Added tag jdk7-b28 for changeset c14dab40ed9b ! .hgtags From xiomara.jayasena at sun.com Thu Jun 12 11:57:07 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Thu, 12 Jun 2008 18:57:07 +0000 Subject: hg: jdk7/build/jaxp: Added tag jdk7-b28 for changeset b996318955c0 Message-ID: <20080612185709.521FA2892D@hg.openjdk.java.net> Changeset: 617ee8607cfd Author: xdono Date: 2008-06-10 10:27 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jaxp/rev/617ee8607cfd Added tag jdk7-b28 for changeset b996318955c0 ! .hgtags From xiomara.jayasena at sun.com Thu Jun 12 11:58:08 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Thu, 12 Jun 2008 18:58:08 +0000 Subject: hg: jdk7/build/jaxws: Added tag jdk7-b28 for changeset eefcd5204500 Message-ID: <20080612185810.EBEE628932@hg.openjdk.java.net> Changeset: 836c55713aba Author: xdono Date: 2008-06-10 10:28 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jaxws/rev/836c55713aba Added tag jdk7-b28 for changeset eefcd5204500 ! .hgtags From xiomara.jayasena at sun.com Thu Jun 12 12:01:28 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Thu, 12 Jun 2008 19:01:28 +0000 Subject: hg: jdk7/build/jdk: 52 new changesets Message-ID: <20080612191158.B855E28937@hg.openjdk.java.net> Changeset: 52f4ad84d5f0 Author: prr Date: 2008-03-07 12:13 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/52f4ad84d5f0 6640532: Graphics.getFontMetrics() throws NullPointerException Summary: NIO usage needs to be robust against Thread.interrupt() Reviewed-by: tdv ! src/share/classes/sun/font/FontManager.java + test/java/awt/font/Threads/FontThread.java Changeset: 73d443d6c863 Author: prr Date: 2008-04-09 13:11 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/73d443d6c863 6683472: Incorrect handling of translation component of font transform. Reviewed-by: igor, campbell ! src/share/classes/sun/font/AttributeValues.java + test/java/awt/Graphics2D/DrawString/RotTransText.java Changeset: cae9799d0810 Author: prr Date: 2008-04-10 09:05 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/cae9799d0810 6684056: SUPERSCRIPT TextAttribute on font needs to trigger layout. Reviewed-by: igor, campbell ! src/share/classes/java/awt/Font.java + test/java/awt/Graphics2D/DrawString/DrawStrSuper.java Changeset: e4abdd4c2303 Author: jgodinez Date: 2008-04-09 15:16 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/e4abdd4c2303 6633656: Cross platform print dialog doesn't check for orientation being unsupported. Reviewed-by: prr, tdv ! src/share/classes/sun/print/ServiceDialog.java ! src/solaris/classes/sun/print/AttributeClass.java ! src/solaris/classes/sun/print/IPPPrintService.java Changeset: 929bf1062f64 Author: jgodinez Date: 2008-04-10 10:23 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/929bf1062f64 Merge Changeset: 9785a8218fd2 Author: prr Date: 2008-04-10 10:31 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/9785a8218fd2 6638477: Two external URLS referenced in 2D documentation are no longer functioning. Reviewed-by: jgodinez ! src/share/classes/java/awt/font/OpenType.java ! src/share/classes/javax/print/attribute/standard/ReferenceUriSchemesSupported.java Changeset: bda7549ac1d0 Author: prr Date: 2008-04-10 10:32 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/bda7549ac1d0 Merge Changeset: 91087975bff7 Author: prr Date: 2008-04-10 16:28 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/91087975bff7 6662775: Move imaging and color classes from closed to open Reviewed-by: tdv, campbell ! make/common/internal/BinaryPlugs.gmk ! make/java/awt/Makefile + src/share/classes/java/awt/color/CMMException.java + src/share/classes/java/awt/color/ColorSpace.java + src/share/classes/java/awt/color/ICC_ColorSpace.java + src/share/classes/java/awt/color/ICC_Profile.java + src/share/classes/java/awt/color/ICC_ProfileGray.java + src/share/classes/java/awt/color/ICC_ProfileRGB.java + src/share/classes/java/awt/image/BandedSampleModel.java + src/share/classes/java/awt/image/ColorConvertOp.java + src/share/classes/java/awt/image/ComponentSampleModel.java + src/share/classes/java/awt/image/DataBuffer.java + src/share/classes/java/awt/image/DataBufferByte.java + src/share/classes/java/awt/image/DataBufferInt.java + src/share/classes/java/awt/image/DataBufferShort.java + src/share/classes/java/awt/image/DataBufferUShort.java + src/share/classes/java/awt/image/MultiPixelPackedSampleModel.java + src/share/classes/java/awt/image/Raster.java + src/share/classes/java/awt/image/RenderedImage.java + src/share/classes/java/awt/image/SampleModel.java + src/share/classes/java/awt/image/SinglePixelPackedSampleModel.java + src/share/classes/java/awt/image/WritableRaster.java + src/share/classes/java/awt/image/WritableRenderedImage.java + src/share/classes/java/awt/image/renderable/ContextualRenderedImageFactory.java + src/share/classes/java/awt/image/renderable/RenderContext.java + src/share/classes/java/awt/image/renderable/RenderableImage.java + src/share/classes/java/awt/image/renderable/RenderableImageOp.java + src/share/classes/java/awt/image/renderable/RenderableImageProducer.java + src/share/classes/java/awt/image/renderable/RenderedImageFactory.java Changeset: 7148e1f2d7c7 Author: lana Date: 2008-04-10 15:50 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/7148e1f2d7c7 Merge Changeset: aaa5637a841d Author: lana Date: 2008-04-10 18:31 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/aaa5637a841d Merge Changeset: 99f3a382f574 Author: jgodinez Date: 2008-04-10 13:57 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/99f3a382f574 6678161: Printing to remote non-Postscript printer does not work in Linux Reviewed-by: prr, tdv ! src/solaris/classes/sun/print/CUPSPrinter.java ! src/solaris/classes/sun/print/IPPPrintService.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java Changeset: 90e1f09ce553 Author: jgodinez Date: 2008-04-14 11:34 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/90e1f09ce553 Merge Changeset: 804b0757d801 Author: prr Date: 2008-04-24 11:58 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/804b0757d801 6523403: Need to provide lcms library with PYCC and LINEAR_RGB OS ICC profiles Summary: Add two contributed profiles and a fix to GRAY.pf, all from Redhat, keiths at redhat.com contributed the GRAY.pf fix. Reviewed-by: jgodinez, avu, prr Contributed-by: aph at redhat.com ! make/sun/cmm/Makefile ! src/share/lib/cmm/lcms/GRAY.pf + src/share/lib/cmm/lcms/LINEAR_RGB.pf + src/share/lib/cmm/lcms/PYCC.pf ! test/sun/java2d/cmm/ProfileOp/ReadProfileTest.java Changeset: ff8302a9936b Author: prr Date: 2008-04-25 10:37 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/ff8302a9936b 6687298: Reg testcase java/awt/Graphics2D/DrawString/RotTransText.java fails on windows Reviewed-by: igor, tdv ! test/java/awt/Graphics2D/DrawString/RotTransText.java Changeset: 94d65e427402 Author: prr Date: 2008-04-25 10:40 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/94d65e427402 6692979: VM Crash when shearing text + rect over a range of values Reviewed-by: igor, tdv ! src/share/classes/sun/font/FileFontStrike.java + test/java/awt/font/Rotate/Shear.java Changeset: 48b7638b8e69 Author: prr Date: 2008-04-28 09:59 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/48b7638b8e69 6694480: Two small inefficiencies in getting font strikes for transformed fonts Reviewed-by: igor, tdv ! src/share/classes/java/awt/Font.java ! src/share/classes/sun/font/Font2D.java Changeset: f50304904b8f Author: prr Date: 2008-04-28 11:06 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/f50304904b8f 6664915: SecurityException using javax.print APIs when queuePrintJob permission is granted. Reviewed-by: tdv, jgodinez ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java + test/javax/print/PrintSE/PrintSE.java + test/javax/print/PrintSE/PrintSE.sh Changeset: d7accc312aec Author: prr Date: 2008-04-28 15:57 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/d7accc312aec 6679308: Poor text rendering on translucent image. Reviewed-by: flar, campbell ! src/share/native/sun/java2d/loops/AlphaMacros.h ! src/share/native/sun/java2d/loops/ByteGray.h ! src/share/native/sun/java2d/loops/FourByteAbgr.h ! src/share/native/sun/java2d/loops/FourByteAbgrPre.h ! src/share/native/sun/java2d/loops/Index12Gray.h ! src/share/native/sun/java2d/loops/Index8Gray.h ! src/share/native/sun/java2d/loops/IntArgb.h ! src/share/native/sun/java2d/loops/IntArgbBm.h ! src/share/native/sun/java2d/loops/IntArgbPre.h ! src/share/native/sun/java2d/loops/IntBgr.h ! src/share/native/sun/java2d/loops/IntRgb.h ! src/share/native/sun/java2d/loops/IntRgbx.h ! src/share/native/sun/java2d/loops/LoopMacros.h ! src/share/native/sun/java2d/loops/ThreeByteBgr.h ! src/share/native/sun/java2d/loops/Ushort4444Argb.h ! src/share/native/sun/java2d/loops/Ushort555Rgb.h ! src/share/native/sun/java2d/loops/Ushort555Rgbx.h ! src/share/native/sun/java2d/loops/Ushort565Rgb.h ! src/share/native/sun/java2d/loops/UshortGray.h ! src/solaris/native/sun/java2d/loops/vis_FourByteAbgr.c ! src/solaris/native/sun/java2d/loops/vis_FourByteAbgrPre.c ! src/solaris/native/sun/java2d/loops/vis_IntArgb.c ! src/solaris/native/sun/java2d/loops/vis_IntArgbPre.c + test/java/awt/Graphics2D/DrawString/AlphaSurfaceText.java Changeset: 55e6548451df Author: prr Date: 2008-04-30 13:10 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/55e6548451df 6656651: Windows Look and Feel LCD glyph images have some differences from native applications. Reviewed-by: igor, tdv ! make/sun/font/FILES_c.gmk ! make/sun/font/Makefile ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontManager.java ! src/share/classes/sun/font/TrueTypeFont.java ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java + src/windows/native/sun/font/lcdglyph.c + test/java/awt/Graphics2D/DrawString/ScaledLCDTextMetrics.java Changeset: fb61ff1cc5fd Author: prr Date: 2008-05-13 16:18 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/fb61ff1cc5fd 6699843: IllegalArgumentException when using Graphics.drawString( "", 0, 0 ) Reviewed-by: igor, tdv ! src/share/classes/sun/java2d/SunGraphics2D.java + test/java/awt/Graphics2D/DrawString/EmptyAttrString.java Changeset: 11a35970b90e Author: tdv Date: 2008-05-13 16:46 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/11a35970b90e 6636469: Java Fullscreen Exclusive Mode not working with Xorg server 1.3.0 and above Summary: improve the check for full exclusive screen support by analyzing RANDR extension version Reviewed-by: tdv, prr Contributed-by: Dan Munckton ! src/solaris/native/sun/awt/awt_GraphicsEnv.c Changeset: 57bcfeb3d8d8 Author: prr Date: 2008-05-13 16:49 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/57bcfeb3d8d8 6696292: Printing transformed images accuracy problems Reviewed-by: jgodinez, igor ! src/share/classes/sun/print/PSPathGraphics.java ! src/windows/classes/sun/awt/windows/WPathGraphics.java Changeset: 4092c04aeae7 Author: prr Date: 2008-05-13 16:56 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/4092c04aeae7 6697721: OpenJDK: rotated text baseline different between TextLayout and drawString Reviewed-by: prr, igor Contributed-by: dougfelt at yahoo.com ! src/share/native/sun/font/freetypeScaler.c ! test/java/awt/Graphics2D/DrawString/RotTransText.java Changeset: be7daefad89f Author: prr Date: 2008-05-13 16:57 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/be7daefad89f Merge Changeset: ed68352f7e42 Author: tdv Date: 2008-05-14 09:16 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/ed68352f7e42 6604044: java crashes talking to second X screen Reviewed-by: prr ! src/solaris/native/sun/awt/awt_GraphicsEnv.c Changeset: 4af4867ed787 Author: tdv Date: 2008-05-14 16:05 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/4af4867ed787 6675596: SurfaceManagerFactory should allow plugging in different implementations Reviewed-by: tdv, campbell Contributed-by: Roman Kennke ! src/share/classes/sun/awt/image/SunVolatileImage.java + src/share/classes/sun/java2d/SurfaceManagerFactory.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java - src/solaris/classes/sun/java2d/SurfaceManagerFactory.java + src/solaris/classes/sun/java2d/UnixSurfaceManagerFactory.java ! src/windows/classes/sun/awt/Win32GraphicsEnvironment.java - src/windows/classes/sun/java2d/SurfaceManagerFactory.java + src/windows/classes/sun/java2d/WindowsSurfaceManagerFactory.java Changeset: bf2c66511d1b Author: igor Date: 2008-05-16 03:10 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/bf2c66511d1b 6630501: CRASH: JCK test eats much memory and jvm crashes Reviewed-by: bae, prr ! src/share/classes/sun/font/Type1Font.java Changeset: 075152aa892e Author: prr Date: 2008-05-19 11:25 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/075152aa892e 6611637: NullPointerException in sun.font.GlyphLayout$EngineRecord.init Reviewed-by: tdv, jgodinez ! src/share/classes/sun/font/GlyphLayout.java Changeset: 41470017e42f Author: prr Date: 2008-05-19 15:33 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/41470017e42f Merge ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontManager.java ! src/share/classes/sun/java2d/SunGraphics2D.java Changeset: 7fba83f5f5e0 Author: igor Date: 2008-05-21 10:59 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/7fba83f5f5e0 6703377: freetype: glyph vector outline is not translated correctly Reviewed-by: bae, prr ! src/share/native/sun/font/freetypeScaler.c + test/java/awt/font/Rotate/TranslatedOutlineTest.java Changeset: 02e4c5348592 Author: lana Date: 2008-06-03 11:18 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/02e4c5348592 Merge Changeset: b64e68bf6b0b Author: dfuchs Date: 2008-05-29 15:33 +0200 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/b64e68bf6b0b 6673853: LegacyIntrospectorTest is testing an old deprecated com.sun API not present in OpenJDK. Summary: Removed test from open test suite - the corresponding deprecated legacy API is not in open source tree Reviewed-by: emcmanus - test/javax/management/Introspector/LegacyIntrospectorTest.java Changeset: 6ca4564520e7 Author: dfuchs Date: 2008-05-30 14:35 +0200 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/6ca4564520e7 6592586: RequiredModelMBean prints a WARNING message when calling getAttributes() for a non-existing attr Summary: Switched traces to FINER - except when logging fails - in which cases the traces are logged to FINE Reviewed-by: emcmanus ! src/share/classes/javax/management/modelmbean/RequiredModelMBean.java Changeset: ca48d7cc3579 Author: chegar Date: 2008-05-15 10:26 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/ca48d7cc3579 6670408: testcase panics 1.5.0_12&_14 JVM when java.net.PlainSocketImpl trying to throw an exception Summary: Replace select with poll Reviewed-by: alanb, jccollet ! src/solaris/native/java/net/PlainSocketImpl.c Changeset: 2ebefcea77a5 Author: vinnie Date: 2008-05-14 18:59 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/2ebefcea77a5 6383078: OCSP checking does not work on end-entity certificate Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/OCSPChecker.java Changeset: 49f02cbe27b1 Author: vinnie Date: 2008-05-15 10:55 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/49f02cbe27b1 Merge Changeset: d3dfeb4295b3 Author: wetmore Date: 2008-05-17 00:27 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/d3dfeb4295b3 Merge Changeset: f8049c6ff629 Author: wetmore Date: 2008-05-22 14:20 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/f8049c6ff629 6706358: jdk/test/sun/security/pkcs11/Cipher/TestSymmCiphers.java has the wrong copyright notice. Reviewed-by: valeriep ! test/sun/security/pkcs11/Cipher/TestSymmCiphers.java Changeset: ead7a5f601d5 Author: weijun Date: 2008-05-27 14:29 +0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/ead7a5f601d5 6705313: Incorrect exit $? in keytool's autotest.sh Reviewed-by: valeriep ! test/sun/security/tools/keytool/autotest.sh Changeset: 827f9f3d1031 Author: wetmore Date: 2008-06-02 10:16 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/827f9f3d1031 Merge Changeset: 2d5d4282d0fa Author: tbell Date: 2008-06-02 22:33 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/2d5d4282d0fa Merge Changeset: 49c3399ca7b8 Author: tbell Date: 2008-06-05 17:43 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/49c3399ca7b8 Merge - src/solaris/classes/sun/java2d/SurfaceManagerFactory.java - src/windows/classes/sun/java2d/SurfaceManagerFactory.java Changeset: 45e53cb21dad Author: xdono Date: 2008-06-10 10:33 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/45e53cb21dad Added tag jdk7-b28 for changeset 02e4c5348592 ! .hgtags Changeset: 5a6c318329f2 Author: son Date: 2008-05-15 11:34 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/5a6c318329f2 6644301: lightweight components can repaint outside request bounds Summary: repaint() needs to adjust width and height if it receives negative x or y. Reviewed-by: art ! src/share/classes/java/awt/Component.java Changeset: abb08b9028f4 Author: yan Date: 2008-05-16 04:37 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/abb08b9028f4 Merge ! src/share/classes/java/awt/Component.java Changeset: 5e39937cf4ce Author: yan Date: 2008-05-21 10:28 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/5e39937cf4ce 6253172: Some key characters on none US keyboard cannot be typed since JDK 1.4 Summary: Windows-only problem fixed by applying 4737679/4623376 fix to navigation keys only. Reviewed-by: son ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h Changeset: addb8a23ad24 Author: yan Date: 2008-05-23 02:29 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/addb8a23ad24 Merge Changeset: d8f9efc21477 Author: dav Date: 2008-05-29 13:48 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/d8f9efc21477 6691328: DragSourceContext returns unexpected cursor Summary: make the code to be executed if other options don't suit Reviewed-by: dcherepanov ! src/share/classes/java/awt/dnd/DragSourceContext.java Changeset: bb99fb855bdc Author: yan Date: 2008-05-30 03:02 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/bb99fb855bdc Merge Changeset: 9ab7e41b205b Author: yan Date: 2008-06-09 06:31 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/9ab7e41b205b Merge - src/solaris/classes/sun/java2d/SurfaceManagerFactory.java - src/windows/classes/sun/java2d/SurfaceManagerFactory.java - test/javax/management/Introspector/LegacyIntrospectorTest.java Changeset: 906a396bff74 Author: yan Date: 2008-06-10 13:42 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/906a396bff74 Merge Changeset: e21f4266466c Author: xdono Date: 2008-06-12 11:46 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/e21f4266466c Merge - src/solaris/classes/sun/java2d/SurfaceManagerFactory.java - src/windows/classes/sun/java2d/SurfaceManagerFactory.java - test/javax/management/Introspector/LegacyIntrospectorTest.java From xiomara.jayasena at sun.com Thu Jun 12 12:18:45 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Thu, 12 Jun 2008 19:18:45 +0000 Subject: hg: jdk7/build/langtools: 9 new changesets Message-ID: <20080612191900.526E428945@hg.openjdk.java.net> Changeset: 58e352559a41 Author: jjg Date: 2008-05-22 15:51 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/58e352559a41 6705945: com.sun.tools.javac.zip files do not have valid copyright Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/zip/ZipFileIndex.java ! src/share/classes/com/sun/tools/javac/zip/ZipFileIndexEntry.java Changeset: b8c8259e0d2b Author: jjg Date: 2008-05-22 16:06 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/b8c8259e0d2b 6657909: javap has unchecked compilation warnings Reviewed-by: mcimadamore ! src/share/classes/sun/tools/javap/ClassData.java ! src/share/classes/sun/tools/javap/FieldData.java ! src/share/classes/sun/tools/javap/InnerClassData.java ! src/share/classes/sun/tools/javap/JavapPrinter.java ! src/share/classes/sun/tools/javap/Main.java ! src/share/classes/sun/tools/javap/MethodData.java ! src/share/classes/sun/tools/javap/Tables.java ! src/share/classes/sun/tools/javap/TypeSignature.java Changeset: 65a447c75d4b Author: jjg Date: 2008-05-22 17:40 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/65a447c75d4b 6705935: javac reports path name of entry in ZipFileIndex incorectly Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/util/JavacFileManager.java ! test/tools/javac/6589361/T6589361.java + test/tools/javac/T6705935.java Changeset: ff3d4fdf9c63 Author: tbell Date: 2008-05-28 00:02 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/ff3d4fdf9c63 Merge Changeset: 8852d96b593b Author: mcimadamore Date: 2008-05-30 10:29 +0100 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/8852d96b593b 6665223: Static import of inherited protected method causes compiler exception Summary: Buggy accessibility check causes NPE during resolution of imported static methods Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/staticImport/6665223/T6665223.java + test/tools/javac/staticImport/6665223/pkg/A.java + test/tools/javac/staticImport/6665223/pkg/B.java Changeset: 6e9a43815df7 Author: mcimadamore Date: 2008-05-30 10:42 +0100 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/6e9a43815df7 6507024: casting an array to a generic type results in a 'capture#69 of ?' type error Summary: Types.isSubtypeUnchecked() should handle type-variables subtyping properly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/generics/T6507024.java Changeset: f7e64b33d5a4 Author: mcimadamore Date: 2008-05-30 11:08 +0100 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/f7e64b33d5a4 6677785: REGRESSION: StackOverFlowError with Cyclic Class level Type Parameters when used in constructors Summary: This regression has been caused by previous fix of 6660289 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/6677785/T6677785.java + test/tools/javac/generics/6677785/T6677785.out Changeset: fc780e96a16a Author: tbell Date: 2008-06-02 22:35 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/fc780e96a16a Merge Changeset: dec081837b01 Author: xdono Date: 2008-06-10 10:37 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/dec081837b01 Added tag jdk7-b28 for changeset 4ef4bd318569 ! .hgtags From gnu_andrew at member.fsf.org Thu Jun 19 08:46:18 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 19 Jun 2008 16:46:18 +0100 Subject: [PATCH] Remove dependency on JScheme for generating CORBA exceptions Message-ID: <17c6771e0806190846n39ceb6d1mf63083bcfc298e1a@mail.gmail.com> At present, a number of exceptions for CORBA are generated using a script written in JScheme. JScheme is thus included in the CORBA tree as a binary 'blob' called jscheme.jar. The utility Java files are also included in binary form in jschemelogutil.jar, as well as the original source code. This has arisen as an issue when packaging OpenJDK (in the form of OpenJDK6/IcedTea6) for Debian: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=140 The attached patches avoids this issue by replacing the single JScheme script used, mc.scm, with a Java-based equivalent. This generates identical source code and resource files, barring a few appropriate changes in the comments. We've already included this in IcedTea as a patch against OpenJDK6, but ideally would like to also see it included upstream. The attached patches were created against a checkout of the latest CORBA forest (http://hg.openjdk.java.net/jdk7/corba/). I couldn't see a way to create a whole forest diff, so I instead create one against the forest root and one against the CORBA tree. The patches are as follows: * jscheme-root.diff: Removes the JScheme notice from the root README file. * jscheme-corba.diff: The main patch; adds the new code and Makefile, and adds this to the build process. * jscheme-rm.diff: Removes jscheme.jar, jschemelogutil.jar and the JScheme scripts from the repository. The second two could be made into one patch if necessary. I did notice that there seems to be no mailing list or active development for the CORBA tree, hence this mail to build-dev instead of a corba-dev alias (the same seems to be true of jaxws and jaxp too). Are these not actively maintained or are they maintained outside the OpenJDK process? Thanks, -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jscheme-corba.diff Url: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20080619/6e339c26/attachment.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jscheme-root.diff Url: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20080619/6e339c26/attachment-0001.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jscheme-rm.diff Url: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20080619/6e339c26/attachment-0002.ksh From mr at sun.com Thu Jun 19 10:16:25 2008 From: mr at sun.com (Mark Reinhold) Date: Thu, 19 Jun 2008 10:16:25 -0700 Subject: [PATCH] Remove dependency on JScheme for generating CORBA exceptions In-Reply-To: gnu_andrew@member.fsf.org; Thu, 19 Jun 2008 16:46:18 BST; <17c6771e0806190846n39ceb6d1mf63083bcfc298e1a@mail.gmail.com> Message-ID: <20080619171625.9A86F5D06@eggemoggin.niobe.net> Andrew: Thanks for the patch! The CORBA code isn't maintained directly in OpenJDK, but rather in a sub-project of GlassFish (https://glassfish-corba.dev.java.net/). That's why there's no CORBA Group. (The same goes for JAXWS and JAXP.) Ken Cavanaugh owns the glassfish-corba project ... Ken: What's the best way to handle this? It'd take longer if OpenJDK waits for these patches to be applied to the upstream glassfish-corba. Could we apply them directly in OpenJDK for now, and then sync things up later? - Mark -------------- next part -------------- An embedded message was scrubbed... From: Andrew John Hughes Subject: [PATCH] Remove dependency on JScheme for generating CORBA exceptions Date: Thu, 19 Jun 2008 16:46:18 +0100 Size: 77517 Url: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20080619/933fab7d/attachment.mht From Tim.Bell at Sun.COM Thu Jun 19 10:27:42 2008 From: Tim.Bell at Sun.COM (Tim Bell) Date: Thu, 19 Jun 2008 10:27:42 -0700 Subject: [PATCH] Remove dependency on JScheme for generating CORBA exceptions In-Reply-To: <20080619171625.9A86F5D06@eggemoggin.niobe.net> References: <20080619171625.9A86F5D06@eggemoggin.niobe.net> Message-ID: <485A970E.2050704@sun.com> Mark Reinhold wrote: > Andrew: Thanks for the patch! > > The CORBA code isn't maintained directly in OpenJDK, but rather in a > sub-project of GlassFish (https://glassfish-corba.dev.java.net/). > > That's why there's no CORBA Group. (The same goes for JAXWS and JAXP.) > > Ken Cavanaugh owns the glassfish-corba project ... > > Ken: What's the best way to handle this? It'd take longer if OpenJDK > waits for these patches to be applied to the upstream glassfish-corba. > Could we apply them directly in OpenJDK for now, and then sync things > up later? FYI: In JDK7, this issue is java:build bug-ID 6695776 "corba jscheme jar files in repository could be built from source" http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6695776 Tim From Ken.Cavanaugh at Sun.COM Thu Jun 19 10:35:12 2008 From: Ken.Cavanaugh at Sun.COM (Ken Cavanaugh) Date: Thu, 19 Jun 2008 10:35:12 -0700 Subject: [PATCH] Remove dependency on JScheme for generating CORBA exceptions In-Reply-To: <20080619171625.9A86F5D06@eggemoggin.niobe.net> References: <20080619171625.9A86F5D06@eggemoggin.niobe.net> Message-ID: <485A98D0.3090602@sun.com> Mark Reinhold wrote: > Andrew: Thanks for the patch! > > The CORBA code isn't maintained directly in OpenJDK, but rather in a > sub-project of GlassFish (https://glassfish-corba.dev.java.net/). > > That's why there's no CORBA Group. (The same goes for JAXWS and JAXP.) > > Ken Cavanaugh owns the glassfish-corba project ... > > Ken: What's the best way to handle this? It'd take longer if OpenJDK > waits for these patches to be applied to the upstream glassfish-corba. > Could we apply them directly in OpenJDK for now, and then sync things > up later? > Yes, you should apply the patch now to the OpenJDK workspaces. I'll take it as a requirement to remove Jscheme from the CORBA master before we integrate with JDK 7. I'll take a closer look at the code from the patch and adapt/replace it as needed. Some work will be needed because I changed the code generation for exception wrappers in the later versions of CORBA Thanks, Ken. From iris at sun.com Thu Jun 19 11:14:57 2008 From: iris at sun.com (iris clark) Date: Thu, 19 Jun 2008 11:14:57 -0700 (PDT) Subject: [PATCH] Remove dependency on JScheme for generating CORBA exceptions In-Reply-To: <20080619171625.9A86F5D06@eggemoggin.niobe.net> (message from Mark Reinhold on Thu, 19 Jun 2008 10:16:25 -0700) Message-ID: <200806191814.m5JIEvvi016368@ribbit.SFBay.Sun.COM> Hi. > The CORBA code isn't maintained directly in OpenJDK, but rather in a > sub-project of GlassFish (https://glassfish-corba.dev.java.net/). > > That's why there's no CORBA Group. (The same goes for JAXWS and JAXP.) For a list of projects and their associated mailing lists (including contact info for portions of the not maintained directly in OpenJDK, see this table in the Developers' Guide: http://openjdk.java.net/guide/repositories.html#projects Thanks, iris From neugens at limasoftware.net Thu Jun 19 12:14:31 2008 From: neugens at limasoftware.net (Mario Torre) Date: Thu, 19 Jun 2008 21:14:31 +0200 Subject: Recommended GCC version? In-Reply-To: <194f62550803310937g2a1b2a7ci337b9093facb354c@mail.gmail.com> References: <194f62550803310937g2a1b2a7ci337b9093facb354c@mail.gmail.com> Message-ID: <1213902871.1712.7.camel@nirvana> Il giorno lun, 31/03/2008 alle 18.37 +0200, Clemens Eisserer ha scritto: > Hello, > > I wonder which version of GCC is recommended for building OpenJDK? > 4.3 will probably not work out-of-the-box, should I downgrade to 4.2 or 4.1? > > Some time ago I developed using the closed java-source, and I had to > install gcc-3.3.6 in order to be able to build the motif-stuff, > however using such an old version of gcc, linking hotspot failed with > some obscure messages. (I solved it by copying an already compiled > library into the build-dirs, so the process thought hotspot was > already build ;) ). > Is it possible to not build the motif stuff at all? > > Thanks a lot, lg Clemens I had to "steal" a couple of patches from icedtea to be able to build hotspot with gcc 4-3, works fine otherwise. Mario From John.Coomes at sun.com Thu Jun 19 13:54:13 2008 From: John.Coomes at sun.com (John Coomes) Date: Thu, 19 Jun 2008 13:54:13 -0700 Subject: Recommended GCC version? In-Reply-To: <1213902871.1712.7.camel@nirvana> References: <194f62550803310937g2a1b2a7ci337b9093facb354c@mail.gmail.com> <1213902871.1712.7.camel@nirvana> Message-ID: <18522.51061.694662.235387@sun.com> Mario Torre (neugens at limasoftware.net) wrote: > Il giorno lun, 31/03/2008 alle 18.37 +0200, Clemens Eisserer ha scritto: > > Hello, > > > > I wonder which version of GCC is recommended for building OpenJDK? > > 4.3 will probably not work out-of-the-box, should I downgrade to 4.2 or 4.1? > > ... > > Thanks a lot, lg Clemens > > I had to "steal" a couple of patches from icedtea to be able to build > hotspot with gcc 4-3, works fine otherwise. FWIW, the fix for 6681796: hotspot build failure on gcc 4.2.x (ubuntu 8.04) w/ openjdk 6 went into the hotspot runtime repository a few days ago: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f139919897d2 It should make its way up to jdk7/jdk7/hotspot fairly soon for jdk7 build 30 or 31. I expect that will allow hotspot to build on current linux distros, but I haven't tried yet. -John From mark at klomp.org Thu Jun 19 14:05:39 2008 From: mark at klomp.org (Mark Wielaard) Date: Thu, 19 Jun 2008 23:05:39 +0200 Subject: [PATCH] Remove dependency on JScheme for generating CORBA exceptions In-Reply-To: <485A98D0.3090602@sun.com> References: <20080619171625.9A86F5D06@eggemoggin.niobe.net> <485A98D0.3090602@sun.com> Message-ID: <1213909539.3160.2.camel@dijkstra.wildebeest.org> Hi Ken, On Thu, 2008-06-19 at 10:35 -0700, Ken Cavanaugh wrote: > Mark Reinhold wrote: > > Andrew: Thanks for the patch! > > > > The CORBA code isn't maintained directly in OpenJDK, but rather in a > > sub-project of GlassFish (https://glassfish-corba.dev.java.net/). > > > > That's why there's no CORBA Group. (The same goes for JAXWS and JAXP.) > > > > Ken Cavanaugh owns the glassfish-corba project ... > > > > Ken: What's the best way to handle this? It'd take longer if OpenJDK > > waits for these patches to be applied to the upstream glassfish-corba. > > Could we apply them directly in OpenJDK for now, and then sync things > > up later? > > > Yes, you should apply the patch now to the OpenJDK workspaces. > I'll take it as a requirement to remove Jscheme from the CORBA master > before we integrate with JDK 7. I'll take a closer look at the > code from the patch and adapt/replace it as needed. > Some work will be needed because I changed the code > generation for exception wrappers in the later versions of CORBA Aha! That is where the corba master is :) According to that page the mercurial page is at http://mercurial2.foundry.sun.com/corba/corba-master but that seems unreachable. Is there another way to view the current corba master code? Thanks, Mark From Ken.Cavanaugh at Sun.COM Thu Jun 19 14:12:50 2008 From: Ken.Cavanaugh at Sun.COM (Ken Cavanaugh) Date: Thu, 19 Jun 2008 14:12:50 -0700 Subject: [PATCH] Remove dependency on JScheme for generating CORBA exceptions In-Reply-To: <1213909539.3160.2.camel@dijkstra.wildebeest.org> References: <20080619171625.9A86F5D06@eggemoggin.niobe.net> <485A98D0.3090602@sun.com> <1213909539.3160.2.camel@dijkstra.wildebeest.org> Message-ID: <485ACBD2.9090305@sun.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20080619/f1ab377c/attachment.html From gnu_andrew at member.fsf.org Thu Jun 19 16:11:38 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 20 Jun 2008 00:11:38 +0100 Subject: [PATCH] Remove dependency on JScheme for generating CORBA exceptions In-Reply-To: <485A970E.2050704@sun.com> References: <20080619171625.9A86F5D06@eggemoggin.niobe.net> <485A970E.2050704@sun.com> Message-ID: <17c6771e0806191611w66122854n2f29c0223d282146@mail.gmail.com> On 19/06/2008, Tim Bell wrote: > Mark Reinhold wrote: > > > Andrew: Thanks for the patch! > > > > The CORBA code isn't maintained directly in OpenJDK, but rather in a > > sub-project of GlassFish > (https://glassfish-corba.dev.java.net/). > > > > That's why there's no CORBA Group. (The same goes for JAXWS and JAXP.) > > > > Ken Cavanaugh owns the glassfish-corba project ... > > > > Ken: What's the best way to handle this? It'd take longer if OpenJDK > > waits for these patches to be applied to the upstream glassfish-corba. > > Could we apply them directly in OpenJDK for now, and then sync things > > up later? > > > > FYI: In JDK7, this issue is java:build bug-ID 6695776 "corba jscheme jar > files in repository could be built from source" > > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6695776 > > Tim > This bug only focuses on the more minor problem that a binary (jschemelogutil.jar) is included which could be built from the two source files listed. The bigger problem is jscheme.jar, which is binary only and also isn't owned by Sun. I added a note to this effect on the bug too. The patch here fixes both issues, handling the expanded sources for 'logutil' in the same manner as the stripproperties and idl tools. Thanks, -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From David.Holmes at Sun.COM Thu Jun 19 16:30:54 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Fri, 20 Jun 2008 09:30:54 +1000 Subject: Recommended GCC version? In-Reply-To: <18522.51061.694662.235387@sun.com> References: <194f62550803310937g2a1b2a7ci337b9093facb354c@mail.gmail.com> <1213902871.1712.7.camel@nirvana> <18522.51061.694662.235387@sun.com> Message-ID: <485AEC2E.6030806@sun.com> Do we need to be careful about the word "recommended" here? There is a big difference between "compiles fine" and "works fine". Anyone using alternate compilers to build the JDK (Hotspot in particular) may encounter compiler specific bugs at runtime. Do we have a big disclaimer/warning somewhere about this? Any bug reports would need to include which compiler was used. David Holmes John Coomes said the following on 06/20/08 06:54: > Mario Torre (neugens at limasoftware.net) wrote: >> Il giorno lun, 31/03/2008 alle 18.37 +0200, Clemens Eisserer ha scritto: >>> Hello, >>> >>> I wonder which version of GCC is recommended for building OpenJDK? >>> 4.3 will probably not work out-of-the-box, should I downgrade to 4.2 or 4.1? >>> ... >>> Thanks a lot, lg Clemens >> I had to "steal" a couple of patches from icedtea to be able to build >> hotspot with gcc 4-3, works fine otherwise. > > FWIW, the fix for > > 6681796: hotspot build failure on gcc 4.2.x (ubuntu 8.04) w/ openjdk 6 > > went into the hotspot runtime repository a few days ago: > > http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f139919897d2 > > It should make its way up to jdk7/jdk7/hotspot fairly soon for jdk7 > build 30 or 31. I expect that will allow hotspot to build on current > linux distros, but I haven't tried yet. > > -John > From gnu_andrew at member.fsf.org Thu Jun 19 16:35:20 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 20 Jun 2008 00:35:20 +0100 Subject: Recommended GCC version? In-Reply-To: <485AEC2E.6030806@sun.com> References: <194f62550803310937g2a1b2a7ci337b9093facb354c@mail.gmail.com> <1213902871.1712.7.camel@nirvana> <18522.51061.694662.235387@sun.com> <485AEC2E.6030806@sun.com> Message-ID: <17c6771e0806191635i782a0aa2u6c3b2c59e051ed61@mail.gmail.com> On 20/06/2008, David Holmes - Sun Microsystems wrote: > Do we need to be careful about the word "recommended" here? There is a big > difference between "compiles fine" and "works fine". Anyone using alternate > compilers to build the JDK (Hotspot in particular) may encounter compiler > specific bugs at runtime. > > Do we have a big disclaimer/warning somewhere about this? Any bug reports > would need to include which compiler was used. > > David Holmes > I would hope one of the side effects of moving the JDK from a proprietary to a community-based Free Software model would be that it gets built, run and tested on a much wider range of platforms and compilers. This has already started to happen. The reality is that people aren't going to download and build a specific copy of GCC just for OpenJDK, and distros will certainly want it to build with the GCC they use for everything else. As I say, the advantage of this now being a community project is that this burden is no longer just in Sun's hands, everyone can help out. -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Erik.Trimble at Sun.COM Thu Jun 19 16:57:45 2008 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Thu, 19 Jun 2008 16:57:45 -0700 Subject: Recommended GCC version? In-Reply-To: <485AEC2E.6030806@sun.com> References: <194f62550803310937g2a1b2a7ci337b9093facb354c@mail.gmail.com> <1213902871.1712.7.camel@nirvana> <18522.51061.694662.235387@sun.com> <485AEC2E.6030806@sun.com> Message-ID: <485AF279.7070606@sun.com> David Holmes - Sun Microsystems wrote: > Do we need to be careful about the word "recommended" here? There is a > big difference between "compiles fine" and "works fine". Anyone using > alternate compilers to build the JDK (Hotspot in particular) may > encounter compiler specific bugs at runtime. > > Do we have a big disclaimer/warning somewhere about this? Any bug > reports would need to include which compiler was used. > > David Holmes > > John Coomes said the following on 06/20/08 06:54: >> Mario Torre (neugens at limasoftware.net) wrote: >>> Il giorno lun, 31/03/2008 alle 18.37 +0200, Clemens Eisserer ha >>> scritto: >>>> Hello, >>>> >>>> I wonder which version of GCC is recommended for building OpenJDK? >>>> 4.3 will probably not work out-of-the-box, should I downgrade to >>>> 4.2 or 4.1? >>>> ... >>>> Thanks a lot, lg Clemens >>> I had to "steal" a couple of patches from icedtea to be able to build >>> hotspot with gcc 4-3, works fine otherwise. >> >> FWIW, the fix for >> >> 6681796: hotspot build failure on gcc 4.2.x (ubuntu 8.04) w/ >> openjdk 6 >> >> went into the hotspot runtime repository a few days ago: >> >> http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/f139919897d2 >> >> It should make its way up to jdk7/jdk7/hotspot fairly soon for jdk7 >> build 30 or 31. I expect that will allow hotspot to build on current >> linux distros, but I haven't tried yet. >> >> -John >> Honestly, I think David has a really good point here. While it's certainly a good idea to support a couple of different compilers on each platform, I think we should be particular to chose a specific version of each compiler, and declare that an "official" compiler. That is, we really shouldn't try to support all the versions of GCC, SunStudio, or Visual Studio. People should be encouraged to pick a specific version, and then go with that for some time. If we don't do this, then we end up having to support (and keep track of) all sorts of workarounds for all the various sub-versions. e.g. gcc4.0, gcc4.2, Visual Studio 2008, Visual Studio Express 2005, etc. Which, is a complete waste of time. I realize this a pain with the various Linux distros, since they all tend to ship with a different gcc version as the default one. HOWEVER, it isn't such a problem, as getting a "standard" gcc version is usually simple, since the various Linux repositories now contain a wide selection of them. Maybe we need to update the READMEs and such with more explicit instructions as to using specific versions of compilers. And, speaking to the community as a whole, I think it would benefit everyone if we could agree on single compiler versions to concentrate effort on, to avoid duplication of effort and needless waste of time. These standardized versions should be periodically reviewed of course for consideration of being updated, but I'd think no more often than yearly, if that. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From David.Holmes at Sun.COM Thu Jun 19 17:20:56 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Fri, 20 Jun 2008 10:20:56 +1000 Subject: Recommended GCC version? In-Reply-To: <17c6771e0806191635i782a0aa2u6c3b2c59e051ed61@mail.gmail.com> References: <194f62550803310937g2a1b2a7ci337b9093facb354c@mail.gmail.com> <1213902871.1712.7.camel@nirvana> <18522.51061.694662.235387@sun.com> <485AEC2E.6030806@sun.com> <17c6771e0806191635i782a0aa2u6c3b2c59e051ed61@mail.gmail.com> Message-ID: <485AF7E8.6080305@sun.com> Andrew, Andrew John Hughes said the following on 06/20/08 09:35: > I would hope one of the side effects of moving the JDK from a > proprietary to a community-based Free Software model would be that it > gets built, run and tested on a much wider range of platforms and > compilers. This has already started to happen. Agreed - this is a good end goal. Meanwhile there are some practicalities to address. > The reality is that people aren't going to download and build a > specific copy of GCC just for OpenJDK, and distros will certainly want > it to build with the GCC they use for everything else. But are the Distros expecting/assuming that everything will work fine with their version of GCC? Who is expected to have done the testing? If something goes wrong who would be expected to fix it? Would the Distros patch the OpenJDK code with a workaround for their GCC version? Or would they grab a known working GCC version and rebuild using that? Right now the reality is that these alternate compiler versions have not undergone extensive testing for the OpenJDK. Over time that will hopefully change, but for now - caveat emptor! Cheers, David Holmes From Erik.Trimble at Sun.COM Thu Jun 19 17:29:10 2008 From: Erik.Trimble at Sun.COM (Erik Trimble) Date: Thu, 19 Jun 2008 17:29:10 -0700 Subject: Recommended GCC version? In-Reply-To: <485AF7E8.6080305@sun.com> References: <194f62550803310937g2a1b2a7ci337b9093facb354c@mail.gmail.com> <1213902871.1712.7.camel@nirvana> <18522.51061.694662.235387@sun.com> <485AEC2E.6030806@sun.com> <17c6771e0806191635i782a0aa2u6c3b2c59e051ed61@mail.gmail.com> <485AF7E8.6080305@sun.com> Message-ID: <485AF9D6.2090102@sun.com> David Holmes - Sun Microsystems wrote: > Andrew, > > Andrew John Hughes said the following on 06/20/08 09:35: >> I would hope one of the side effects of moving the JDK from a >> proprietary to a community-based Free Software model would be that it >> gets built, run and tested on a much wider range of platforms and >> compilers. This has already started to happen. > > Agreed - this is a good end goal. Meanwhile there are some > practicalities to address. > >> The reality is that people aren't going to download and build a >> specific copy of GCC just for OpenJDK, and distros will certainly want >> it to build with the GCC they use for everything else. > > But are the Distros expecting/assuming that everything will work fine > with their version of GCC? Who is expected to have done the testing? > If something goes wrong who would be expected to fix it? Would the > Distros patch the OpenJDK code with a workaround for their GCC > version? Or would they grab a known working GCC version and rebuild > using that? > > Right now the reality is that these alternate compiler versions have > not undergone extensive testing for the OpenJDK. Over time that will > hopefully change, but for now - caveat emptor! > > Cheers, > David Holmes > While what Andrew says is true to a certain extent, I think it behooves us to act as guides. Hotspot in particular is a _very_ complex piece of code, and exercises (let's be honest, _stresses) a compiler far more than virtually any other piece of software commonly available (the Xorg stuff is probably the only comparable one in a standard Linux distro). Consequently, it is very sensitive to bugs and changes in a compiler. For large organizations (such as those managing a distro), it may make sense to put in the effort to make sure their "standard" compiler works with OpenJDK. It is none too difficult for even such an org to use a different compiler, though. For smaller companies and individuals, I think we (i.e. the community, not just Sun), should _strongly_ encourage them to pick one of the handful of "official" compilers, which are specified in the source documentation. Downloading the appropriate compiler is trivial these days (via Yum or apt-get), and it avoids a whole rash of problems. Otherwise, folks get bogged down in trivial build problems (which, may turn out to be non-trivial), rather than doing what they were intending to do with the OpenJDK (which, is almost certainly not "adding support for compiler X.Y.Z"). Certainly, we should pick compiler versions which are easily available, and will remain so for several years. While I love free software (in all its incarnations), one of the problems with running a large project is trying to "herd cats" - that is, setting appropriate boundaries and encouraging everyone to work within those boundaries, rather than just a willy-nilly free-for-all. In areas where it fruitful to push a boundary, the community should encourage it. However, there needs to be some social pressure in a community to discourage people from doing what I call the "look-at-me-I'm-cool" hack - that is, something that looks neat and may have been technically difficult or challenging, but really isn't useful (and, in many cases, carries a burden of support by the community). There is a non-zero cost to adding support to a codebase for any new feature. What the community needs to do is say that "Doing XYZ costs more than it is worth to community, so we will NOT accept XYZ". While this originally started out as a discussion around GCC, it applies to the other primary compilers currently used, i.e. SunStudio and Visual Studio. I've run in considerable problems by applying a new Service pack to a Visual Studio 2003 (or, previously, VC 6), as not only bugfixes but behavior modifications are installed. Running down those differences is a HUGE timesink. One which I think we should avoid if at all possible. Sometimes Freedom means you need to give up something to get something else. In this case, I think the tradeoff is unlimited flexibility (use whatever compiler you want) for maintainability. As I don't see any real benefit not easily obtainable otherwise by allowing many different compiler versions, I vote for maintainability as the more important feature. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) From David.Herron at Sun.COM Thu Jun 19 17:41:23 2008 From: David.Herron at Sun.COM (David Herron) Date: Thu, 19 Jun 2008 17:41:23 -0700 Subject: Recommended GCC version? In-Reply-To: <485AF7E8.6080305@sun.com> References: <194f62550803310937g2a1b2a7ci337b9093facb354c@mail.gmail.com> <1213902871.1712.7.camel@nirvana> <18522.51061.694662.235387@sun.com> <485AEC2E.6030806@sun.com> <17c6771e0806191635i782a0aa2u6c3b2c59e051ed61@mail.gmail.com> <485AF7E8.6080305@sun.com> Message-ID: <485AFCB3.9040105@sun.com> David Holmes - Sun Microsystems wrote: > Andrew, > > Andrew John Hughes said the following on 06/20/08 09:35: >> I would hope one of the side effects of moving the JDK from a >> proprietary to a community-based Free Software model would be that it >> gets built, run and tested on a much wider range of platforms and >> compilers. This has already started to happen. > > Agreed - this is a good end goal. Meanwhile there are some > practicalities to address. > >> The reality is that people aren't going to download and build a >> specific copy of GCC just for OpenJDK, and distros will certainly want >> it to build with the GCC they use for everything else. > > But are the Distros expecting/assuming that everything will work fine > with their version of GCC? Who is expected to have done the testing? > If something goes wrong who would be expected to fix it? Would the > Distros patch the OpenJDK code with a workaround for their GCC > version? Or would they grab a known working GCC version and rebuild > using that? > > Right now the reality is that these alternate compiler versions have > not undergone extensive testing for the OpenJDK. Over time that will > hopefully change, but for now - caveat emptor! > > Cheers, > David Holmes > Ubuntu ships with a default GCC but you can also install other GCC's /usr/bin/gcc versus /usr/bin/gcc-4.2 versus /usr/bin/gcc-3.4 etc It doesn't seem very onerous (on Ubuntu) for the end user to do this. I'd think other distros also do this. I have no idea how onerous it is for the distros to provide this service. -- David Herron From gnu_andrew at member.fsf.org Thu Jun 19 18:17:31 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Fri, 20 Jun 2008 02:17:31 +0100 Subject: Recommended GCC version? In-Reply-To: <485AF7E8.6080305@sun.com> References: <194f62550803310937g2a1b2a7ci337b9093facb354c@mail.gmail.com> <1213902871.1712.7.camel@nirvana> <18522.51061.694662.235387@sun.com> <485AEC2E.6030806@sun.com> <17c6771e0806191635i782a0aa2u6c3b2c59e051ed61@mail.gmail.com> <485AF7E8.6080305@sun.com> Message-ID: <17c6771e0806191817x395b140fu2b73d03652f5e47@mail.gmail.com> > > > The reality is that people aren't going to download and build a > > specific copy of GCC just for OpenJDK, and distros will certainly want > > it to build with the GCC they use for everything else. > > > > But are the Distros expecting/assuming that everything will work fine with > their version of GCC? Who is expected to have done the testing? If something > goes wrong who would be expected to fix it? Would the Distros patch the > OpenJDK code with a workaround for their GCC version? Or would they grab a > known working GCC version and rebuild using that? > Patching is already being done; I believe IcedTea includes patches to allow builds to be done on newer versions of GCC. In the near future, I guess most distros will ship with 4.3. Fedora, I believe, has already moved towards this. Tests are being run using the jtreg test cases and the Mauve test suite. The version shipped with Fedora has also just passed the TCK (congratulations to them, btw.) > Right now the reality is that these alternate compiler versions have not > undergone extensive testing for the OpenJDK. Over time that will hopefully > change, but for now - caveat emptor! > I agree it would be simpler to aim towards a minimum set of supported compilers, but we should work together to decide what this is. The reason I replied to begin with is I occasionally get the implicit feeling from some mails (if not intentional) that there is still a separation between 'us' (sun) and 'them' (the community). Clearly Sun has made decisions about which compiler to support internally in the past, but such decisions now need to involve the major players that such support will affect. I believe this is the distros; you will always get individual users who try some bizarre configuration. That's life ... A final note should also be made that of course new architectures and platforms, being targeted by the porting project, may require further compiler versions. > Cheers, > David Holmes > > -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Jonathan.Gibbons at Sun.COM Thu Jun 19 22:03:04 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Thu, 19 Jun 2008 22:03:04 -0700 Subject: Recommended GCC version? In-Reply-To: <485AFCB3.9040105@sun.com> References: <194f62550803310937g2a1b2a7ci337b9093facb354c@mail.gmail.com> <1213902871.1712.7.camel@nirvana> <18522.51061.694662.235387@sun.com> <485AEC2E.6030806@sun.com> <17c6771e0806191635i782a0aa2u6c3b2c59e051ed61@mail.gmail.com> <485AF7E8.6080305@sun.com> <485AFCB3.9040105@sun.com> Message-ID: <116FE2D5-4DFF-4CB6-BDC8-D09D356F3E0F@sun.com> It makes me wonder whether there should be a .deb/.rpm for *building* OpenJDK that causes all the right versions of all the necessary software to be installed. -- Jon On Jun 19, 2008, at 5:41 PM, David Herron wrote: > David Holmes - Sun Microsystems wrote: >> Andrew, >> >> Andrew John Hughes said the following on 06/20/08 09:35: >>> I would hope one of the side effects of moving the JDK from a >>> proprietary to a community-based Free Software model would be that >>> it >>> gets built, run and tested on a much wider range of platforms and >>> compilers. This has already started to happen. >> >> Agreed - this is a good end goal. Meanwhile there are some >> practicalities to address. >> >>> The reality is that people aren't going to download and build a >>> specific copy of GCC just for OpenJDK, and distros will certainly >>> want >>> it to build with the GCC they use for everything else. >> >> But are the Distros expecting/assuming that everything will work >> fine with their version of GCC? Who is expected to have done the >> testing? If something goes wrong who would be expected to fix it? >> Would the Distros patch the OpenJDK code with a workaround for >> their GCC version? Or would they grab a known working GCC version >> and rebuild using that? >> >> Right now the reality is that these alternate compiler versions >> have not undergone extensive testing for the OpenJDK. Over time >> that will hopefully change, but for now - caveat emptor! >> >> Cheers, >> David Holmes >> > Ubuntu ships with a default GCC but you can also install other GCC's > > /usr/bin/gcc versus /usr/bin/gcc-4.2 versus /usr/bin/gcc-3.4 etc > > It doesn't seem very onerous (on Ubuntu) for the end user to do > this. I'd think other distros also do this. I have no idea how > onerous it is for the distros to provide this service. > > -- David Herron > > From martinrb at google.com Thu Jun 19 22:12:10 2008 From: martinrb at google.com (Martin Buchholz) Date: Thu, 19 Jun 2008 22:12:10 -0700 Subject: Recommended GCC version? In-Reply-To: <485AF9D6.2090102@sun.com> References: <194f62550803310937g2a1b2a7ci337b9093facb354c@mail.gmail.com> <1213902871.1712.7.camel@nirvana> <18522.51061.694662.235387@sun.com> <485AEC2E.6030806@sun.com> <17c6771e0806191635i782a0aa2u6c3b2c59e051ed61@mail.gmail.com> <485AF7E8.6080305@sun.com> <485AF9D6.2090102@sun.com> Message-ID: <1ccfd1c10806192212i6e7940fax881d36b6db1b4675@mail.gmail.com> When I worked on XEmacs, I acquired many systems and compilers and used them to test XEmacs. Quite aside from creating new ports that are actually useful to users, each successful port is a Quality Improvement exercise. Each new port typically finds new bugs. I recall one particularly insidious bug found only using the 64-bit Irix compiler. So I'm a big fan of at least porting to many compilers. But the culture of JDK development is not quite right to reap maximal Quality benefits from this activity. Martin From aph at redhat.com Fri Jun 20 03:23:50 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 20 Jun 2008 11:23:50 +0100 Subject: Recommended GCC version? In-Reply-To: <485AF7E8.6080305@sun.com> References: <194f62550803310937g2a1b2a7ci337b9093facb354c@mail.gmail.com> <1213902871.1712.7.camel@nirvana> <18522.51061.694662.235387@sun.com> <485AEC2E.6030806@sun.com> <17c6771e0806191635i782a0aa2u6c3b2c59e051ed61@mail.gmail.com> <485AF7E8.6080305@sun.com> Message-ID: <485B8536.50208@redhat.com> David Holmes - Sun Microsystems wrote: > Andrew John Hughes said the following on 06/20/08 09:35: >> I would hope one of the side effects of moving the JDK from a >> proprietary to a community-based Free Software model would be that it >> gets built, run and tested on a much wider range of platforms and >> compilers. This has already started to happen. > > Agreed - this is a good end goal. Meanwhile there are some > practicalities to address. > >> The reality is that people aren't going to download and build a >> specific copy of GCC just for OpenJDK, and distros will certainly want >> it to build with the GCC they use for everything else. > > But are the Distros expecting/assuming that everything will work fine > with their version of GCC? Yes, of course, and if it doesn't then we'll either fix GCC or OpenJDK. > Who is expected to have done the testing? There are two levels of testing here: that of the core package as written, and that of a specific build, for which we need to do regression testing. There is nothing special about Java in this regard: every package has the same problem. The packagers of the distros have been doing this stuff for many years. > If something goes wrong who would be expected to fix it? Would the > Distros patch the OpenJDK code with a workaround for their GCC > version? Or would they grab a known working GCC version and rebuild > using that? We'll patch OpenJDK or GCC, depending on which is at fault. We will not build a special GCC in order to build OpenJDK; that would be a pain and contrary to packaging guidelines. > Right now the reality is that these alternate compiler versions have > not undergone extensive testing for the OpenJDK. I guess it all depends on what you mean by "extensive". We've run all the test suites to which we have access and a good deal of application testing too. > Over time that will hopefully change, but for now - caveat emptor! Of course. One of the problems here is that the distro packagers need access to regression tests, some of which (AIUI) are still Sun confidential. Andrew. From aph at redhat.com Fri Jun 20 03:55:56 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 20 Jun 2008 11:55:56 +0100 Subject: Recommended GCC version? In-Reply-To: <485AF9D6.2090102@sun.com> References: <194f62550803310937g2a1b2a7ci337b9093facb354c@mail.gmail.com> <1213902871.1712.7.camel@nirvana> <18522.51061.694662.235387@sun.com> <485AEC2E.6030806@sun.com> <17c6771e0806191635i782a0aa2u6c3b2c59e051ed61@mail.gmail.com> <485AF7E8.6080305@sun.com> <485AF9D6.2090102@sun.com> Message-ID: <485B8CBC.6040606@redhat.com> Erik Trimble wrote: > Consequently, it is very sensitive to bugs and changes in a compiler. > For large organizations (such as those managing a distro), it may make > sense to put in the effort to make sure their "standard" compiler works > with OpenJDK. It is none too difficult for even such an org to use a > different compiler, though. I have a very bad feeling about this. In the Bad Old Days when I worked in proprietary software, it was not uncommon that a code base would only compile correctly with a "blessed" compiler. Eventually, that compiler would be withdrawn from support or we'd need to use a new compiler for some other reason, and we'd have to fix the bugs in our code base to work with the new compiler. I now regard such antediluvian habits as grossly unprofessional, and I have no desire to go back to them. > For smaller companies and individuals, I think we (i.e. the community, > not just Sun), should _strongly_ encourage them to pick one of the > handful of "official" compilers, which are specified in the source > documentation. Quite a few Linux distros are downstream of Red Hat, and start with a compiler built from the Red Hat branch. The RH compiler has built an entire Linux distro, after all. The changes we had to make to build OpenJDK with gcc 4.3 were to fix nonstandard C++ code and to turn off -Werror because gcc 4.3 is much more fulsome in its warnings. Rather than insist on using an older compiler, we would probably be better off fixing the code that generates the warnings. > Certainly, we should pick compiler versions which are easily > available, and will remain so for several years. One of the great things about pushing HotSpot into the open is that it will be useful as a test for compilers. If, as you say, it is so much harder to compile than virtually any other piece of software, it will be a great test. Andrew. From martinrb at google.com Fri Jun 20 10:39:19 2008 From: martinrb at google.com (Martin Buchholz) Date: Fri, 20 Jun 2008 10:39:19 -0700 Subject: Recommended GCC version? In-Reply-To: <485B8CBC.6040606@redhat.com> References: <194f62550803310937g2a1b2a7ci337b9093facb354c@mail.gmail.com> <1213902871.1712.7.camel@nirvana> <18522.51061.694662.235387@sun.com> <485AEC2E.6030806@sun.com> <17c6771e0806191635i782a0aa2u6c3b2c59e051ed61@mail.gmail.com> <485AF7E8.6080305@sun.com> <485AF9D6.2090102@sun.com> <485B8CBC.6040606@redhat.com> Message-ID: <1ccfd1c10806201039p4d58df74k215dc4140a73a254@mail.gmail.com> Many code bases qualify as "compiler stress tests". I once recommended that the gcc team use XEmacs as a stress test because the source code's unusual C/C++/Lisp style tended to tickle gcc bugs. I fondly remember the old "C preprocessor fails when a macro call contains a comment longer than 128 lines" gcc bug. Hotspot is an even better compiler stress test. Again I recommend that the gcc team use it as part of their testing cycle. Martin On Fri, Jun 20, 2008 at 3:55 AM, Andrew Haley wrote: > Erik Trimble wrote: > >> Consequently, it is very sensitive to bugs and changes in a compiler. >> For large organizations (such as those managing a distro), it may make >> sense to put in the effort to make sure their "standard" compiler works >> with OpenJDK. It is none too difficult for even such an org to use a >> different compiler, though. > > I have a very bad feeling about this. In the Bad Old Days when I > worked in proprietary software, it was not uncommon that a code base > would only compile correctly with a "blessed" compiler. Eventually, > that compiler would be withdrawn from support or we'd need to use a > new compiler for some other reason, and we'd have to fix the bugs in > our code base to work with the new compiler. I now regard such > antediluvian habits as grossly unprofessional, and I have no desire to > go back to them. > >> For smaller companies and individuals, I think we (i.e. the community, >> not just Sun), should _strongly_ encourage them to pick one of the >> handful of "official" compilers, which are specified in the source >> documentation. > > Quite a few Linux distros are downstream of Red Hat, and start with a > compiler built from the Red Hat branch. The RH compiler has built an > entire Linux distro, after all. > > The changes we had to make to build OpenJDK with gcc 4.3 were to fix > nonstandard C++ code and to turn off -Werror because gcc 4.3 is much > more fulsome in its warnings. Rather than insist on using an older > compiler, we would probably be better off fixing the code that > generates the warnings. > >> Certainly, we should pick compiler versions which are easily >> available, and will remain so for several years. > > One of the great things about pushing HotSpot into the open is that it > will be useful as a test for compilers. If, as you say, it is so much > harder to compile than virtually any other piece of software, it will > be a great test. > > Andrew. > > From Joe.Darcy at Sun.COM Fri Jun 20 15:21:41 2008 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Fri, 20 Jun 2008 15:21:41 -0700 Subject: duplicated sanity check warning In-Reply-To: <1ccfd1c10805310054r48dd5c95obf21123ecd9b7c93@mail.gmail.com> References: <1ccfd1c10805310054r48dd5c95obf21123ecd9b7c93@mail.gmail.com> Message-ID: <485C2D75.6070205@sun.com> Hello. This fix will be reflected in the next OpenJDK 6 source drop, b11. Thanks, -Joe Martin Buchholz wrote: > This is a bug report. > > I was trying to build openjdk6, and make sanity got duplicated > BUILD_JDK = true > lines in the output. > > Looking at control/make/make/sanity-rules.gmk, I see duplicate lines > > ifeq ($(JDK_SRC_AVAILABLE), true) > @$(ECHO) " BUILD_JDK = $(BUILD_JDK) " >> $(MESSAGE_FILE) > endif > ifeq ($(JDK_SRC_AVAILABLE), true) > @$(ECHO) " BUILD_JDK = $(BUILD_JDK) " >> $(MESSAGE_FILE) > endif > > Delete one of the above. > > Martin > From Joe.Darcy at Sun.COM Fri Jun 20 16:06:01 2008 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Fri, 20 Jun 2008 16:06:01 -0700 Subject: [PATCH] Remove dependency on JScheme for generating CORBA exceptions In-Reply-To: <485A98D0.3090602@sun.com> References: <20080619171625.9A86F5D06@eggemoggin.niobe.net> <485A98D0.3090602@sun.com> Message-ID: <485C37D9.908@sun.com> Ken Cavanaugh wrote: > Mark Reinhold wrote: >> Andrew: Thanks for the patch! >> >> The CORBA code isn't maintained directly in OpenJDK, but rather in a >> sub-project of GlassFish (https://glassfish-corba.dev.java.net/). >> >> That's why there's no CORBA Group. (The same goes for JAXWS and JAXP.) >> >> Ken Cavanaugh owns the glassfish-corba project ... >> >> Ken: What's the best way to handle this? It'd take longer if OpenJDK >> waits for these patches to be applied to the upstream glassfish-corba. >> Could we apply them directly in OpenJDK for now, and then sync things >> up later? >> > Yes, you should apply the patch now to the OpenJDK workspaces. > I'll take it as a requirement to remove Jscheme from the CORBA master > before we integrate with JDK 7. I'll take a closer look at the > code from the patch and adapt/replace it as needed. > Some work will be needed because I changed the code > generation for exception wrappers in the later versions of CORBA > Hello. I've successfully applied Andrew's patch to one of my OpenJDK 6 workspaces. Upon successful completion of some testing, I'll put the fix back into the Sun-internal OpenJDK 6 master and the fix should then be reflected in the next OpenJDK 6 source drop, b11. Thanks, -Joe From David.Holmes at Sun.COM Sun Jun 22 16:52:43 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Mon, 23 Jun 2008 09:52:43 +1000 Subject: Recommended GCC version? In-Reply-To: <485B8CBC.6040606@redhat.com> References: <194f62550803310937g2a1b2a7ci337b9093facb354c@mail.gmail.com> <1213902871.1712.7.camel@nirvana> <18522.51061.694662.235387@sun.com> <485AEC2E.6030806@sun.com> <17c6771e0806191635i782a0aa2u6c3b2c59e051ed61@mail.gmail.com> <485AF7E8.6080305@sun.com> <485AF9D6.2090102@sun.com> <485B8CBC.6040606@redhat.com> Message-ID: <485EE5CB.9060701@sun.com> Andrew, Andrew Haley said the following on 06/20/08 20:55: > The changes we had to make to build OpenJDK with gcc 4.3 were to fix > nonstandard C++ code and to turn off -Werror because gcc 4.3 is much > more fulsome in its warnings. Rather than insist on using an older > compiler, we would probably be better off fixing the code that > generates the warnings. It isn't compilation that is the issue (we should certainly fix the OpenJDK code to compile cleanly on a standards-compliant compiler) but the actual runtime behaviour of the compiled code. WE don't "recommend" the old compiler because it allows old sloppy code to get through, but because we've already uncovered the bugs that affect us at runtime, through literally years of use and testing. David Holmes From mark at klomp.org Mon Jun 23 02:29:39 2008 From: mark at klomp.org (Mark Wielaard) Date: Mon, 23 Jun 2008 11:29:39 +0200 Subject: javax.script rhino (javascript) support added Message-ID: <1214213379.32610.44.camel@dijkstra.wildebeest.org> Hi, This patch adds javax.script javascript support through rhino. CCed build-dev since it is mainly build stuff and there doesn't seem to be another list for scripting stuff (not that I am advocating yet another list!) The idea is pretty simple, if configure can detect rhino being installed on the system already (either the rhino.jar from fedora or the js.jar from debian) it uses that instead of the closed and unreleased sun internal classes. The only wrinkle is that the javascript support is written to expect the implementation on the bootclasspath, I would have liked it to be possible to just add it to the extension dir. This is solved by patching the hardcoded hotspot boostrap path and creating the correct symlink in the jre lib dir. Maybe the modules project and/or the extension/plugin ideas from icedtea can help a bit in the future to rewrite these kind of things a little cleaner: http://icedtea.classpath.org/wiki/PackagingExtensions 2008-06-22 Mark Wielaard * patches/icedtea-rhino.patch: New patch. * Makefile.am: Add RHINO_JAR to environment variable lists. (ICEDTEA_PATHCES): Add patches/icedtea-rhino.patch. * Makefile.in: Regenerated. * acinclude.m4 (FIND_RHINO_JAR): New. * configure.ac: Use FIND_RHINO_JAR. * configure: Regenerated. Committed to icedtea6. With this patch the jrunscript works perfectly, and the javax.script and sun.tools.jscript jtreg tests all pass except for one. The sun/tools/jrunscript/jrunscriptTest.sh test insists that 2 + 5 = 7.0, while our current implementation says it is 7 (without the .0). The tests references two bugs (6265810,6705893) which might help analyze this, unfortunately they are closed to the public (is there anybody who could see what these bugs were about?). Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: rhino.patch Type: text/x-patch Size: 8747 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/build-dev/attachments/20080623/86108978/attachment.bin From aph at redhat.com Mon Jun 23 08:38:55 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 23 Jun 2008 16:38:55 +0100 Subject: Recommended GCC version? In-Reply-To: <485EE5CB.9060701@sun.com> References: <194f62550803310937g2a1b2a7ci337b9093facb354c@mail.gmail.com> <1213902871.1712.7.camel@nirvana> <18522.51061.694662.235387@sun.com> <485AEC2E.6030806@sun.com> <17c6771e0806191635i782a0aa2u6c3b2c59e051ed61@mail.gmail.com> <485AF7E8.6080305@sun.com> <485AF9D6.2090102@sun.com> <485B8CBC.6040606@redhat.com> <485EE5CB.9060701@sun.com> Message-ID: <485FC38F.3030607@redhat.com> David Holmes - Sun Microsystems wrote: > Andrew, > > Andrew Haley said the following on 06/20/08 20:55: >> The changes we had to make to build OpenJDK with gcc 4.3 were to fix >> nonstandard C++ code and to turn off -Werror because gcc 4.3 is much >> more fulsome in its warnings. Rather than insist on using an older >> compiler, we would probably be better off fixing the code that >> generates the warnings. > > It isn't compilation that is the issue (we should certainly fix the > OpenJDK code to compile cleanly on a standards-compliant compiler) but > the actual runtime behaviour of the compiled code. WE don't "recommend" > the old compiler because it allows old sloppy code to get through, but > because we've already uncovered the bugs that affect us at runtime, > through literally years of use and testing. Sure. I was counselling against the (oft-seen) practice of using an old compiler because the code doesn't run on the new one. Andrew. From Dalibor.Topic at Sun.COM Mon Jun 23 08:49:25 2008 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Mon, 23 Jun 2008 17:49:25 +0200 Subject: javax.script rhino (javascript) support added In-Reply-To: <1214213379.32610.44.camel@dijkstra.wildebeest.org> References: <1214213379.32610.44.camel@dijkstra.wildebeest.org> Message-ID: <485FC605.9030002@Sun.COM> Mark Wielaard wrote: > With this patch the jrunscript works perfectly, and the javax.script and > sun.tools.jscript jtreg tests all pass except for one. The > sun/tools/jrunscript/jrunscriptTest.sh test insists that 2 + 5 = 7.0, > while our current implementation says it is 7 (without the .0). The > tests references two bugs (6265810,6705893) which might help analyze > this, unfortunately they are closed to the public (is there anybody who > could see what these bugs were about?). > Hi Mark, They don't seem to be related, one is about the name of the tool, and the other is about enabling the scripting engine tests conditionally in OpenJDK, see http://article.gmane.org/gmane.comp.java.openjdk.distro-packaging.devel/1951 cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer Vorsitzender des Aufsichtsrates: Martin H?ring From David.Herron at Sun.COM Mon Jun 23 11:43:15 2008 From: David.Herron at Sun.COM (David Herron) Date: Mon, 23 Jun 2008 11:43:15 -0700 Subject: javax.script rhino (javascript) support added In-Reply-To: <1214213379.32610.44.camel@dijkstra.wildebeest.org> References: <1214213379.32610.44.camel@dijkstra.wildebeest.org> Message-ID: <485FEEC3.8040102@sun.com> Mark Wielaard wrote: > Hi, > > This patch adds javax.script javascript support through rhino. CCed > build-dev since it is mainly build stuff and there doesn't seem to be > another list for scripting stuff (not that I am advocating yet another > list!) > > The idea is pretty simple, if configure can detect rhino being installed > on the system already (either the rhino.jar from fedora or the js.jar > from debian) it uses that instead of the closed and unreleased sun > internal classes. The only wrinkle is that the javascript support is > written to expect the implementation on the bootclasspath, I would have > liked it to be possible to just add it to the extension dir. This is > solved by patching the hardcoded hotspot boostrap path and creating the > correct symlink in the jre lib dir. > > Maybe the modules project and/or the extension/plugin ideas from icedtea > can help a bit in the future to rewrite these kind of things a little > cleaner: http://icedtea.classpath.org/wiki/PackagingExtensions > > 2008-06-22 Mark Wielaard > > * patches/icedtea-rhino.patch: New patch. > * Makefile.am: Add RHINO_JAR to environment variable lists. > (ICEDTEA_PATHCES): Add patches/icedtea-rhino.patch. > * Makefile.in: Regenerated. > * acinclude.m4 (FIND_RHINO_JAR): New. > * configure.ac: Use FIND_RHINO_JAR. > * configure: Regenerated. > > Committed to icedtea6. > > With this patch the jrunscript works perfectly, and the javax.script and > sun.tools.jscript jtreg tests all pass except for one. The > sun/tools/jrunscript/jrunscriptTest.sh test insists that 2 + 5 = 7.0, > while our current implementation says it is 7 (without the .0). The > tests references two bugs (6265810,6705893) which might help analyze > this, unfortunately they are closed to the public (is there anybody who > could see what these bugs were about?). > > Cheers, > > Mark > Hi Mark, In my JavaOne talk Sandeep and I had worked up a hack with the same purpose. He's been busy enough that he hadn't had a chance to turn the hack into an official proposal like this.. Here's a couple things I see reading through your patch.. This patch puts a hard dependency on having rhino in your environment. Maybe this is okay for IcedTea but in OpenJDK's makefiles I'd rather it be a loose dependency (if RHINO_JAR is in the environment, that should trigger makefile rules to include RHINO support). A lot of the changes are in com/sun/script/javascript files to change imports from sun.org.mozilla.xyzzy to org.mozilla.xyzzy ... we've been following a practice for a long time of munging the package names of imported packages, and this came from issues which arose when we imported Xerces XML code and people started using some of the Xerces API's ... - David From mark at klomp.org Mon Jun 23 14:06:22 2008 From: mark at klomp.org (Mark Wielaard) Date: Mon, 23 Jun 2008 23:06:22 +0200 Subject: javax.script rhino (javascript) support added In-Reply-To: <485FEEC3.8040102@sun.com> References: <1214213379.32610.44.camel@dijkstra.wildebeest.org> <485FEEC3.8040102@sun.com> Message-ID: <1214255183.3308.9.camel@hermans.wildebeest.org> Hi David, On Mon, 2008-06-23 at 11:43 -0700, David Herron wrote: > Mark Wielaard wrote: > In my JavaOne talk Sandeep and I had worked up a hack with the same > purpose. He's been busy enough that he hadn't had a chance to turn the > hack into an official proposal like this.. That is cool, I didn't know that. Is your presentation online somewhere? > This patch puts a hard dependency on having rhino in your environment. > Maybe this is okay for IcedTea but in OpenJDK's makefiles I'd rather it > be a loose dependency (if RHINO_JAR is in the environment, that should > trigger makefile rules to include RHINO support). Yes, we can do that. My thinking was that if it is always included in closedjdk6 we want to also always provide it in the free version. > A lot of the changes are in com/sun/script/javascript files to change > imports from sun.org.mozilla.xyzzy to org.mozilla.xyzzy ... we've been > following a practice for a long time of munging the package names of > imported packages, and this came from issues which arose when we > imported Xerces XML code and people started using some of the Xerces > API's ... hmmm, that seems not the right thing to do for the free version that gets integrated with the various GNU/Linux distros. The patch deliberately makes it so that the code isn't actually imported and emedded , but that it uses the system provided rhino. The idea is that these kind of external dependencies are provided by the distribution. That way a user automatically gets bug fixes or security updates without having to audit every package which might have integrated an old (renamed) library. I would like to find a way to do this cleaner though. But the current code relies on being on the bootclasspath which makes things a little tricky. Cheers, Mark From Dalibor.Topic at Sun.COM Mon Jun 23 15:09:33 2008 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Tue, 24 Jun 2008 00:09:33 +0200 Subject: javax.script rhino (javascript) support added In-Reply-To: <1214255183.3308.9.camel@hermans.wildebeest.org> References: <1214213379.32610.44.camel@dijkstra.wildebeest.org> <485FEEC3.8040102@sun.com> <1214255183.3308.9.camel@hermans.wildebeest.org> Message-ID: <48601F1D.3040604@sun.com> Mark Wielaard wrote: > Hi David, > > On Mon, 2008-06-23 at 11:43 -0700, David Herron wrote: > >> Mark Wielaard wrote: >> In my JavaOne talk Sandeep and I had worked up a hack with the same >> purpose. He's been busy enough that he hadn't had a chance to turn the >> hack into an official proposal like this.. >> > > That is cool, I didn't know that. > Is your presentation online somewhere? > http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-5230.pdf > I would like to find a way to do this cleaner though. But the current > code relies on being on the bootclasspath which makes things a little > tricky. > Landon suggested a while ago exploring https://scripting.dev.java.net/ , which includes a Rhino binding. cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer Vorsitzender des Aufsichtsrates: Martin H?ring From David.Herron at Sun.COM Mon Jun 23 15:17:08 2008 From: David.Herron at Sun.COM (David Herron) Date: Mon, 23 Jun 2008 15:17:08 -0700 Subject: Ability to override compiler from environment Message-ID: <486020E4.1070109@sun.com> I was thinking about this issue of compiling with different gcc's and it seems the normal way to install multiple gcc's is to use suffixes for the version like so:- gcc-4.1 == gcc v4.1.x gcc-3.4 == gcc v3.4.x gcc == gcc v4.2.x I groped around the OpenJDK makefiles and found jdk/make/common/shared/Compiler-gcc.gmk corba/make/common/shared/Compiler-gcc.gmk hotspot/build/linux/makefiles/gcc.make both contain lines which say CC=gcc CPP=g++ According to the GNU make manual .. http://www.gnu.org/software/make/manual/html_node/Setting.html#Setting .. these values could be overridden with a small change in the makefile CC?=gcc CPP?=g++ And then setting CC or CPP in the environment would make it so the variable is already set and these lines in the makefile would have no effect. - David Herron From Jonathan.Gibbons at Sun.COM Mon Jun 23 15:34:15 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Mon, 23 Jun 2008 15:34:15 -0700 Subject: Ability to override compiler from environment In-Reply-To: <486020E4.1070109@sun.com> References: <486020E4.1070109@sun.com> Message-ID: <486024E7.5040503@sun.com> David, Some would say that it is a feature of the current build system that random environment variables don't get used :-) It makes it that much harder to get a predictable build. -- Jon David Herron wrote: > I was thinking about this issue of compiling with different gcc's and > it seems the normal way to install multiple gcc's is to use suffixes > for the version like so:- > > gcc-4.1 == gcc v4.1.x > gcc-3.4 == gcc v3.4.x > gcc == gcc v4.2.x > > I groped around the OpenJDK makefiles and found > > jdk/make/common/shared/Compiler-gcc.gmk > corba/make/common/shared/Compiler-gcc.gmk > hotspot/build/linux/makefiles/gcc.make > > both contain lines which say > > CC=gcc > CPP=g++ > > According to the GNU make manual .. > http://www.gnu.org/software/make/manual/html_node/Setting.html#Setting > .. these values could be overridden with a small change in the makefile > > CC?=gcc > CPP?=g++ > > And then setting CC or CPP in the environment would make it so the > variable is already set and these lines in the makefile would have no > effect. > > > > - David Herron > > From David.Herron at Sun.COM Mon Jun 23 18:32:06 2008 From: David.Herron at Sun.COM (David Herron) Date: Mon, 23 Jun 2008 18:32:06 -0700 Subject: Ability to override compiler from environment In-Reply-To: <486024E7.5040503@sun.com> References: <486020E4.1070109@sun.com> <486024E7.5040503@sun.com> Message-ID: <48604E96.6070307@sun.com> ??? The OpenJDK build process is configured by setting environment variables. I suppose what you mean is build configuration is done by setting variables named ALT_XYZZY rather than XYZZY...??? Some would say the value of setting environment variables to configure the build is you can change build parameters without modifying any of the build files. - David Jonathan Gibbons wrote: > David, > > Some would say that it is a feature of the current build system that > random environment variables don't get used :-) It makes it that much > harder to get a predictable build. > > -- Jon > > > David Herron wrote: >> I was thinking about this issue of compiling with different gcc's and >> it seems the normal way to install multiple gcc's is to use suffixes >> for the version like so:- >> >> gcc-4.1 == gcc v4.1.x >> gcc-3.4 == gcc v3.4.x >> gcc == gcc v4.2.x >> >> I groped around the OpenJDK makefiles and found >> >> jdk/make/common/shared/Compiler-gcc.gmk >> corba/make/common/shared/Compiler-gcc.gmk >> hotspot/build/linux/makefiles/gcc.make >> >> both contain lines which say >> >> CC=gcc >> CPP=g++ >> >> According to the GNU make manual .. >> http://www.gnu.org/software/make/manual/html_node/Setting.html#Setting >> .. these values could be overridden with a small change in the makefile >> >> CC?=gcc >> CPP?=g++ >> >> And then setting CC or CPP in the environment would make it so the >> variable is already set and these lines in the makefile would have no >> effect. >> >> >> >> - David Herron >> >> > From gnu_andrew at member.fsf.org Tue Jun 24 01:01:22 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 24 Jun 2008 09:01:22 +0100 Subject: javax.script rhino (javascript) support added In-Reply-To: <48601F1D.3040604@sun.com> References: <1214213379.32610.44.camel@dijkstra.wildebeest.org> <485FEEC3.8040102@sun.com> <1214255183.3308.9.camel@hermans.wildebeest.org> <48601F1D.3040604@sun.com> Message-ID: <17c6771e0806240101pa0b16d3p8e81b2b0caf8db2b@mail.gmail.com> 2008/6/23 Dalibor Topic : > Mark Wielaard wrote: >> >> Hi David, >> >> On Mon, 2008-06-23 at 11:43 -0700, David Herron wrote: >> >>> >>> Mark Wielaard wrote: >>> In my JavaOne talk Sandeep and I had worked up a hack with the same >>> purpose. He's been busy enough that he hadn't had a chance to turn the hack >>> into an official proposal like this.. >> >> That is cool, I didn't know that. >> Is your presentation online somewhere? >> > > http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-5230.pdf >> >> I would like to find a way to do this cleaner though. But the current >> code relies on being on the bootclasspath which makes things a little >> tricky. >> > Interesting. I think slide 26 should also have 'incllulde ./make/rhino-rules.gmk' to match the previous slide. OT, but the mention of binary plugs in the slides made me question whether they are still relevant given IcedTea passed the JCK without any? For OpenJDK6, is this now just the optional SNMP support? It would be good if someone could make it clear what's still needed for OpenJDK6 and OpenJDK7 (which seem to differ in this respect too). IcedTea probably needs a cleanout in terms of long-dead binary plugs it still tries to provide. > Landon suggested a while ago exploring https://scripting.dev.java.net/ , > which includes a Rhino > binding. > > cheers, > dalibor topic > > -- > ******************************************************************* > Dalibor Topic Tel: (+49 40) 23 646 738 > Java F/OSS Ambassador AIM: robiladonaim > Sun Microsystems GmbH Mobile: (+49 177) 2664 192 > Nagelsweg 55 http://openjdk.java.net > D-20097 Hamburg mailto:Dalibor.Topic at sun.com > Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten > Amtsgericht M?nchen: HRB 161028 > Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer > Vorsitzender des Aufsichtsrates: Martin H?ring > > > -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Tue Jun 24 01:16:10 2008 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Tue, 24 Jun 2008 01:16:10 -0700 Subject: javax.script rhino (javascript) support added In-Reply-To: <17c6771e0806240101pa0b16d3p8e81b2b0caf8db2b@mail.gmail.com> References: <1214213379.32610.44.camel@dijkstra.wildebeest.org> <485FEEC3.8040102@sun.com> <1214255183.3308.9.camel@hermans.wildebeest.org> <48601F1D.3040604@sun.com> <17c6771e0806240101pa0b16d3p8e81b2b0caf8db2b@mail.gmail.com> Message-ID: <4860AD4A.3020301@sun.com> Andrew John Hughes wrote: > 2008/6/23 Dalibor Topic : >> Mark Wielaard wrote: >>> Hi David, >>> >>> On Mon, 2008-06-23 at 11:43 -0700, David Herron wrote: >>> >>>> Mark Wielaard wrote: >>>> In my JavaOne talk Sandeep and I had worked up a hack with the same >>>> purpose. He's been busy enough that he hadn't had a chance to turn the hack >>>> into an official proposal like this.. >>> That is cool, I didn't know that. >>> Is your presentation online somewhere? >>> >> http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-5230.pdf >>> I would like to find a way to do this cleaner though. But the current >>> code relies on being on the bootclasspath which makes things a little >>> tricky. >>> > > Interesting. I think slide 26 should also have 'incllulde > ./make/rhino-rules.gmk' > to match the previous slide. > > OT, but the mention of binary plugs in the slides made me question > whether they are still relevant given IcedTea passed > the JCK without any? For OpenJDK6, is this now just the optional SNMP > support? It would be good if someone could > make it clear what's still needed for OpenJDK6 and OpenJDK7 (which > seem to differ in this respect too). > IcedTea probably needs a cleanout in terms of long-dead binary plugs > it still tries to provide. Yes, since b07 back in March, *no* binary plugs are required to build the OpenJDK 6 sources from Sun. The only remaining plug is for SNMP support, which is not required functionality according to the platform spec and is thus not tested by the JCK. IIRC, JDK 7 may still have a plug for sound since I don't think Gervill has been integrated there yet. -Joe >> Landon suggested a while ago exploring https://scripting.dev.java.net/ , >> which includes a Rhino >> binding. >> >> cheers, >> dalibor topic >> >> -- >> ******************************************************************* >> Dalibor Topic Tel: (+49 40) 23 646 738 >> Java F/OSS Ambassador AIM: robiladonaim >> Sun Microsystems GmbH Mobile: (+49 177) 2664 192 >> Nagelsweg 55 http://openjdk.java.net >> D-20097 Hamburg mailto:Dalibor.Topic at sun.com >> Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten >> Amtsgericht M?nchen: HRB 161028 >> Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer >> Vorsitzender des Aufsichtsrates: Martin H?ring >> >> >> > > > From gnu_andrew at member.fsf.org Tue Jun 24 02:20:41 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 24 Jun 2008 10:20:41 +0100 Subject: javax.script rhino (javascript) support added In-Reply-To: <4860AD4A.3020301@sun.com> References: <1214213379.32610.44.camel@dijkstra.wildebeest.org> <485FEEC3.8040102@sun.com> <1214255183.3308.9.camel@hermans.wildebeest.org> <48601F1D.3040604@sun.com> <17c6771e0806240101pa0b16d3p8e81b2b0caf8db2b@mail.gmail.com> <4860AD4A.3020301@sun.com> Message-ID: <17c6771e0806240220x2436d7b5g20bf44de3a1c5efc@mail.gmail.com> 2008/6/24 Joseph D. Darcy : > Yes, since b07 back in March, *no* binary plugs are required to build the > OpenJDK 6 sources from Sun. The only remaining plug is for SNMP support, > which is not required functionality according to the platform spec and is > thus not tested by the JCK. IIRC, JDK 7 may still have a plug for sound > since I don't think Gervill has been integrated there yet. > > -Joe > Ah great, I thought that was the case. IcedTea6 is still adding SNMP stubs, which should be dropped. OpenJDK7 does still have a sound plug. IcedTea7 patches in Gervill in its place (or should do -- I haven't fully tested this yet). Thanks, -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From mark at klomp.org Tue Jun 24 04:33:48 2008 From: mark at klomp.org (Mark Wielaard) Date: Tue, 24 Jun 2008 13:33:48 +0200 Subject: javax.script rhino (javascript) support added In-Reply-To: <48601F1D.3040604@sun.com> References: <1214213379.32610.44.camel@dijkstra.wildebeest.org> <485FEEC3.8040102@sun.com> <1214255183.3308.9.camel@hermans.wildebeest.org> <48601F1D.3040604@sun.com> Message-ID: <1214307228.3959.1.camel@dijkstra.wildebeest.org> Hi Dalibor, On Tue, 2008-06-24 at 00:09 +0200, Dalibor Topic wrote: > > I would like to find a way to do this cleaner though. But the current > > code relies on being on the bootclasspath which makes things a little > > tricky. > > > Landon suggested a while ago exploring https://scripting.dev.java.net/ , > which includes a Rhino > binding. Yes, I think outsourcing the actual scripting engines and merging them with a project like that would be a cool idea for jdk7. That way you completely get around some of them living in rt.jar on the bootclasspath. And users/distros would be free to add and upgrade them separately. Cheers, Mark From martinrb at google.com Tue Jun 24 10:57:42 2008 From: martinrb at google.com (Martin Buchholz) Date: Tue, 24 Jun 2008 10:57:42 -0700 Subject: Ability to override compiler from environment In-Reply-To: <486020E4.1070109@sun.com> References: <486020E4.1070109@sun.com> Message-ID: <1ccfd1c10806241057n718fc035k9a31017d7668bf54@mail.gmail.com> The JDK's Makefiles are not coherent; they do not look like they were designed using a common architecture. On Mon, Jun 23, 2008 at 3:17 PM, David Herron wrote: > CC?=gcc > CPP?=g++ A particularly egregious example is the use of the make variable CPP. Some Makefiles use CPP to mean "C preprocessor", while some use it to mean "C++ compiler". The latter are non-traditional and should be excised. We should use CXX instead to mean "C++ compiler" --- Yes, users should be able to specifically override the C and C++ compilers used. In practice, users can work around this clumsily by creating a temp directory with symlinks for gcc, g++, etc... and setting ALT_COMPILER_PATH to that. --- I am in favor of the fundamental change to a "configure + make" model, instead of configury stuff being done in the Makefiles as is the current practice. Martin From David.Herron at Sun.COM Tue Jun 24 11:32:54 2008 From: David.Herron at Sun.COM (David Herron) Date: Tue, 24 Jun 2008 11:32:54 -0700 Subject: javax.script rhino (javascript) support added In-Reply-To: <17c6771e0806240101pa0b16d3p8e81b2b0caf8db2b@mail.gmail.com> References: <1214213379.32610.44.camel@dijkstra.wildebeest.org> <485FEEC3.8040102@sun.com> <1214255183.3308.9.camel@hermans.wildebeest.org> <48601F1D.3040604@sun.com> <17c6771e0806240101pa0b16d3p8e81b2b0caf8db2b@mail.gmail.com> Message-ID: <48613DD6.5090402@sun.com> Andrew John Hughes wrote: > 2008/6/23 Dalibor Topic : > >> Mark Wielaard wrote: >> > OT, but the mention of binary plugs in the slides made me question > whether they are still relevant given IcedTea passed > the JCK without any? For OpenJDK6, is this now just the optional SNMP > support? It would be good if someone could > make it clear what's still needed for OpenJDK6 and OpenJDK7 (which > seem to differ in this respect too). > IcedTea probably needs a cleanout in terms of long-dead binary plugs > it still tries to provide. > The slides were originally written in Feb/March back when we still needed the plugs. And at the time of JavaOne none of us had incorporated Gervill. I did say in the session that we were all on the verge of being 100% and that soon the plugs wouldn't be required. Duke is bald and every time I see 'plugs' it makes me think of hair plugs and Duke with hair doesn't make sense. So of course the plugs have to go. - David Herron From xiomara.jayasena at sun.com Tue Jun 24 12:03:12 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Tue, 24 Jun 2008 19:03:12 +0000 Subject: hg: jdk7/build: Added tag jdk7-b29 for changeset 31e08f70e88d Message-ID: <20080624190312.C4D2028219@hg.openjdk.java.net> Changeset: 14c2c623d687 Author: xdono Date: 2008-06-20 08:44 -0700 URL: http://hg.openjdk.java.net/jdk7/build/rev/14c2c623d687 Added tag jdk7-b29 for changeset 31e08f70e88d ! .hgtags From xiomara.jayasena at sun.com Tue Jun 24 12:04:16 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Tue, 24 Jun 2008 19:04:16 +0000 Subject: hg: jdk7/build/corba: Added tag jdk7-b29 for changeset 8b71960f79ce Message-ID: <20080624190417.2DCAB28220@hg.openjdk.java.net> Changeset: 76600bc57421 Author: xdono Date: 2008-06-20 08:44 -0700 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/76600bc57421 Added tag jdk7-b29 for changeset 8b71960f79ce ! .hgtags From xiomara.jayasena at sun.com Tue Jun 24 12:06:08 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Tue, 24 Jun 2008 19:06:08 +0000 Subject: hg: jdk7/build/hotspot: 44 new changesets Message-ID: <20080624190730.1A78C28229@hg.openjdk.java.net> Changeset: c70a245cad3a Author: dcubed Date: 2008-05-09 08:55 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/c70a245cad3a 6670684: 4/5 SA command universe did not print out CMS space information Summary: Forward port of Yumin's fix for 6670684 from HSX-11; Yumin verified the port was correct. Reviewed-by: dcubed ! agent/make/Makefile ! agent/src/share/classes/sun/jvm/hotspot/HSDB.java ! agent/src/share/classes/sun/jvm/hotspot/SALauncherLoader.java ! agent/src/share/classes/sun/jvm/hotspot/bugspot/Main.java ! agent/src/share/classes/sun/jvm/hotspot/jdi/SAJDIClassLoader.java + agent/src/share/classes/sun/jvm/hotspot/memory/BinaryTreeDictionary.java ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java ! agent/src/share/classes/sun/jvm/hotspot/memory/DefNewGeneration.java + agent/src/share/classes/sun/jvm/hotspot/memory/FreeList.java + agent/src/share/classes/sun/jvm/hotspot/memory/LinearAllocBlock.java ! agent/src/share/classes/sun/jvm/hotspot/ui/AnnotatedMemoryPanel.java ! agent/src/share/classes/sun/jvm/hotspot/ui/CommandProcessorPanel.java ! agent/src/share/classes/sun/jvm/hotspot/ui/DebuggerConsolePanel.java ! agent/src/share/classes/sun/jvm/hotspot/ui/HighPrecisionJScrollBar.java ! agent/src/share/classes/sun/jvm/hotspot/ui/JFrameWrapper.java ! agent/src/share/classes/sun/jvm/hotspot/ui/treetable/JTreeTable.java ! src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 6ab92ec09f70 Author: dcubed Date: 2008-05-09 09:11 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/6ab92ec09f70 Merge Changeset: 09c2ba680204 Author: kvn Date: 2008-05-15 22:40 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/09c2ba680204 6700102: c2 assertion "counter_changed,"failed dependencies, but counter didn't change")" with AggressiveOpts Summary: Bytecode Escape Analyzer does not have the check for the case described in 6389127. Reviewed-by: never ! src/share/vm/ci/bcEscapeAnalyzer.cpp Changeset: 723be81c1212 Author: kvn Date: 2008-05-15 22:43 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/723be81c1212 6701887: JDK7 server VM in endless loop in Node::dominates Summary: The method Node::dominates loops in the dead code which does not have a Region node. Reviewed-by: jrose, never ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.cpp Changeset: 5bba3366a9a2 Author: dcubed Date: 2008-05-16 13:42 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/5bba3366a9a2 Merge ! agent/src/share/classes/sun/jvm/hotspot/HSDB.java ! src/share/vm/runtime/vmStructs.cpp Changeset: a3e5744fafda Author: dcubed Date: 2008-05-20 09:47 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/a3e5744fafda Merge Changeset: a49545cab84a Author: ohair Date: 2008-05-27 09:47 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/a49545cab84a 6563752: Build and test JDK7 with Sun Studio 12 Express compilers (prep makefiles) Summary: Allows for building with SS12, no longer requires SS11, warns if not SS11 for now. Once SS12 is validated and performance measurements look ok, SS12 will be the validated compiler. Reviewed-by: sspitsyn, ikrylov ! make/jprt.config ! make/solaris/makefiles/debug.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/jvmg.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! make/solaris/makefiles/sparc.make ! make/solaris/makefiles/sparcWorks.make ! make/solaris/makefiles/sparcv9.make Changeset: af059c49e677 Author: ohair Date: 2008-05-28 10:16 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/af059c49e677 6703308: Fix jprt.properties to allow for jdk6 and jdk7 builds Summary: Allows for jprt submit -release option to select jdk version and proper build targets. Reviewed-by: jcoomes ! make/jprt.properties Changeset: 23a06eca8e83 Author: jmasa Date: 2008-05-27 11:46 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/23a06eca8e83 6706662: Remove workaround introduced in fix for 6624782 Summary: Remove workaround compiler options for instanceKlass.cpp and objArrayKlass.cpp. Reviewed-by: ysr, jcoomes ! make/solaris/makefiles/amd64.make Changeset: 27f13876aef3 Author: iveresov Date: 2008-05-30 03:53 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/27f13876aef3 Merge Changeset: 8aa010f60e0f Author: rasbold Date: 2008-05-20 06:32 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/8aa010f60e0f Merge Changeset: 885ed790ecf0 Author: kvn Date: 2008-05-21 10:45 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/885ed790ecf0 6695810: null oop passed to encode_heap_oop_not_null Summary: fix several problems in C2 related to Escape Analysis and Compressed Oops. Reviewed-by: never, jrose ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp + test/compiler/6689060/Test.java + test/compiler/6695810/Test.java Changeset: c436414a719e Author: kvn Date: 2008-05-21 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/c436414a719e 6703890: Compressed Oops: add LoadNKlass node to generate narrow oops (32-bits) compare instructions Summary: Add LoadNKlass and CMoveN nodes, use CmpN and ConN nodes to generate narrow oops compare instructions. Reviewed-by: never, rasbold ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/sparc/vm/relocInfo_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86_64.cpp ! src/cpu/x86/vm/assembler_x86_64.hpp ! src/cpu/x86/vm/relocInfo_x86.cpp ! src/cpu/x86/vm/relocInfo_x86.hpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/includeDB_core ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/runtime/globals.hpp Changeset: 437d03ea40b1 Author: kvn Date: 2008-05-21 16:31 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/437d03ea40b1 6703888: Compressed Oops: use the 32-bits gap after klass in a object Summary: Use the gap also for a narrow oop field and a boxing object value. Reviewed-by: coleenp, never ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/gc_implementation/includeDB_gc_shared ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/instanceOop.hpp Changeset: aaa1137c5ef4 Author: sgoldman Date: 2008-05-28 12:42 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/aaa1137c5ef4 6707485: bytecodeInterpreterWithChecks.xsl is malformed Summary: xsl output tag not at top level Reviewed-by: never, kvn, rasbold Contributed-by: gnu_andrew at member.fsf.org ! src/share/vm/interpreter/bytecodeInterpreterWithChecks.xml ! src/share/vm/interpreter/bytecodeInterpreterWithChecks.xsl Changeset: feeb96a45707 Author: coleenp Date: 2008-05-28 21:06 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/feeb96a45707 6696264: assert("narrow oop can never be zero") for GCBasher & ParNewGC Summary: decouple set_klass() with zeroing the gap when compressed. Reviewed-by: kvn, ysr, jrose ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86_64.cpp ! src/cpu/x86/vm/assembler_x86_64.hpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/memory/space.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp Changeset: 7793bd37a336 Author: kvn Date: 2008-05-29 12:04 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/7793bd37a336 6705887: Compressed Oops: generate x64 addressing and implicit null checks with narrow oops Summary: Generate addresses and implicit null checks with narrow oops to avoid decoding. Reviewed-by: jrose, never ! src/cpu/x86/vm/assembler_x86_32.hpp ! src/cpu/x86/vm/assembler_x86_64.hpp ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/linux_x86/vm/assembler_linux_x86_32.cpp ! src/os_cpu/linux_x86/vm/assembler_linux_x86_64.cpp ! src/os_cpu/solaris_x86/vm/assembler_solaris_x86_32.cpp ! src/os_cpu/solaris_x86/vm/assembler_solaris_x86_64.cpp ! src/os_cpu/windows_x86/vm/assembler_windows_x86_32.cpp ! src/os_cpu/windows_x86/vm/assembler_windows_x86_64.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.hpp Changeset: 9148c65abefc Author: rasbold Date: 2008-05-29 16:22 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/9148c65abefc 6695049: (coll) Create an x86 intrinsic for Arrays.equals Summary: Intrinsify java/util/Arrays.equals(char[], char[]) Reviewed-by: kvn, never ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 02cc988a9fdc Author: rasbold Date: 2008-05-30 07:22 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/02cc988a9fdc Merge Changeset: 0e13255adcb0 Author: trims Date: 2008-05-30 14:30 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/0e13255adcb0 Merge Changeset: 3e4b7b5b2b4b Author: trims Date: 2008-05-30 14:31 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/3e4b7b5b2b4b Merge Changeset: 9077d695a1b0 Author: trims Date: 2008-05-30 14:50 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/9077d695a1b0 6709213: Update Build number for HS13 b02 Summary: Bump up build number to 02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 510f98a80563 Author: rasbold Date: 2008-06-03 13:14 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/510f98a80563 6709972: runThese failed with assert(false,"bad AD file") Summary: guard AryEqNode construction with has_match_rule() test, set SpecialArraysEquals default off Reviewed-by: kvn, never ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/globals.hpp Changeset: f2759c126e9d Author: rasbold Date: 2008-06-03 15:38 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/f2759c126e9d Merge Changeset: 6b648fefb395 Author: kamg Date: 2008-05-22 13:03 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/6b648fefb395 6705523: Fix for 6695506 will violate spec when used in JDK6 Summary: Make max classfile version number dependent on JDK version Reviewed-by: acorn, never ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/java.hpp Changeset: 2a8ec427fbe1 Author: kamg Date: 2008-05-29 14:06 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/2a8ec427fbe1 6706604: Copyright headers need to be changed to GPL. Summary: Update the copyrights Reviewed-by: ohair ! src/share/vm/interpreter/bytecodeInterpreterWithChecks.xml ! src/share/vm/interpreter/bytecodeInterpreterWithChecks.xsl ! test/compiler/6659207/Test.java ! test/compiler/6661247/Test.java ! test/compiler/6663621/IVTest.java Changeset: 6d172e3548cb Author: coleenp Date: 2008-06-05 17:02 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/6d172e3548cb 6695819: verify_oopx rax: broken oop in decode_heap_oop Summary: Code in gen_subtype_check was encoding rax as an oop on a path where rax was not an oop. Reviewed-by: never, kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/x86/vm/assembler_x86_64.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp Changeset: 1f809e010142 Author: kamg Date: 2008-06-06 13:43 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/1f809e010142 Merge ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/assembler_x86_64.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/interpreter/bytecodeInterpreterWithChecks.xml ! src/share/vm/interpreter/bytecodeInterpreterWithChecks.xsl Changeset: b9ebd46331d2 Author: kvn Date: 2008-06-04 14:03 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/b9ebd46331d2 6710654: SAJDI failures with Compressed Oops Summary: Use correct offset for the java.lang.Class _klass field in SA. Reviewed-by: jrose, never ! agent/src/share/classes/sun/jvm/hotspot/oops/OopUtilities.java Changeset: 823298b11afc Author: never Date: 2008-06-04 21:56 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/823298b11afc 6709165: Tests hang or misbahve with HS 13.0-b01 on solaris-sparcv9 Reviewed-by: kvn, jrose ! src/cpu/sparc/vm/sparc.ad Changeset: 44abbb0d4c18 Author: kvn Date: 2008-06-05 13:02 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/44abbb0d4c18 6709093: Compressed Oops: reduce size of compiled methods Summary: exclude UEP size from nmethod code size and use narrow klass oop to load prototype header. Reviewed-by: jrose, never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86_64.cpp ! src/cpu/x86/vm/assembler_x86_64.hpp ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/opto/compile.cpp Changeset: d4dbd9f91680 Author: never Date: 2008-06-05 15:43 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/d4dbd9f91680 6711083: 64bit JVM crashes with Internal Error (type.cpp:763) - ShouldNotReachHere() with enabled COOPs Summary: Add NarrowOop to various xmeet routines Reviewed-by: kvn, sgoldman, jrose, rasbold ! src/share/vm/opto/type.cpp Changeset: 65fe2bd88839 Author: never Date: 2008-06-05 21:44 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/65fe2bd88839 6614100: EXCEPTION_ACCESS_VIOLATION while running Eclipse with 1.6.0_05-ea Reviewed-by: kvn, jrose, rasbold ! src/share/vm/opto/cfgnode.cpp Changeset: 8759d37f2524 Author: rasbold Date: 2008-06-06 11:47 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/8759d37f2524 6711701: disable compressed oops by default Summary: comment out code that turns on compressed oops Reviewed-by: never, phh ! src/share/vm/runtime/arguments.cpp Changeset: cf1821c649d9 Author: never Date: 2008-06-06 14:34 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/cf1821c649d9 Merge ! src/cpu/x86/vm/assembler_x86_64.cpp Changeset: 790e66e5fbac Author: coleenp Date: 2008-06-09 11:51 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/790e66e5fbac 6687581: Make CMS work with compressed oops Summary: Make FreeChunk read markword instead of LSB in _klass pointer to indicate that it's a FreeChunk for compressed oops. Reviewed-by: ysr, jmasa ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java ! agent/src/share/classes/sun/jvm/hotspot/memory/FreeChunk.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Mark.java ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.cpp + src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/oops/markOop.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: c0ecab83e6f3 Author: never Date: 2008-06-10 09:57 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/c0ecab83e6f3 Merge ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 0b27f3512f9e Author: jmasa Date: 2008-06-04 13:51 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/0b27f3512f9e 6629727: assertion in set_trap_state() in methodDataOop.hpp is too strong. Summary: The assertion can failure due to race conditions. Reviewed-by: never ! src/share/vm/oops/methodDataOop.hpp Changeset: d1635bf93939 Author: iveresov Date: 2008-06-09 07:18 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/d1635bf93939 6711930: NUMA allocator: ParOld can create a hole less than minimal object size in the lgrp chunk Summary: The fix takes care of three issues that can create a hole less a minimal object in the lgrp chunk Reviewed-by: ysr, apetrusenko ! src/share/vm/gc_implementation/shared/immutableSpace.cpp ! src/share/vm/gc_implementation/shared/immutableSpace.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.hpp Changeset: 3ad4bacbcdbe Author: jcoomes Date: 2008-06-10 11:14 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/3ad4bacbcdbe Merge Changeset: 6d13fcb3663f Author: kvn Date: 2008-06-13 14:49 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/6d13fcb3663f 6714404: Add UseStringCache switch to enable String caching under AggressiveOpts Summary: Poke String.stringCacheEnabled during vm initialization Reviewed-by: never ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: 44a553b2809d Author: kvn Date: 2008-06-13 15:08 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/44a553b2809d 6714406: Node::dominates() does not always check for TOP Summary: Add missed checks for TOP and missed checks for non-dominating cases Reviewed-by: rasbold, jrose, never ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/node.cpp Changeset: 4f91c08b3e44 Author: trims Date: 2008-06-17 15:27 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/4f91c08b3e44 Merge Changeset: 93435819dba2 Author: xdono Date: 2008-06-20 08:44 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/93435819dba2 Added tag jdk7-b29 for changeset 4f91c08b3e44 ! .hgtags From xiomara.jayasena at sun.com Tue Jun 24 12:09:27 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Tue, 24 Jun 2008 19:09:27 +0000 Subject: hg: jdk7/build/jaxp: Added tag jdk7-b29 for changeset 617ee8607cfd Message-ID: <20080624190929.749462822E@hg.openjdk.java.net> Changeset: 4d8da2b3c124 Author: xdono Date: 2008-06-20 08:45 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jaxp/rev/4d8da2b3c124 Added tag jdk7-b29 for changeset 617ee8607cfd ! .hgtags From xiomara.jayasena at sun.com Tue Jun 24 12:10:33 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Tue, 24 Jun 2008 19:10:33 +0000 Subject: hg: jdk7/build/jaxws: Added tag jdk7-b29 for changeset 836c55713aba Message-ID: <20080624191035.24A3B28235@hg.openjdk.java.net> Changeset: 2c23d2441366 Author: xdono Date: 2008-06-20 08:45 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jaxws/rev/2c23d2441366 Added tag jdk7-b29 for changeset 836c55713aba ! .hgtags From xiomara.jayasena at sun.com Tue Jun 24 12:11:41 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Tue, 24 Jun 2008 19:11:41 +0000 Subject: hg: jdk7/build/jdk: Added tag jdk7-b29 for changeset e21f4266466c Message-ID: <20080624191153.B6E062823E@hg.openjdk.java.net> Changeset: 0a5b87833562 Author: xdono Date: 2008-06-20 08:45 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/0a5b87833562 Added tag jdk7-b29 for changeset e21f4266466c ! .hgtags From xiomara.jayasena at sun.com Tue Jun 24 12:14:51 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Tue, 24 Jun 2008 19:14:51 +0000 Subject: hg: jdk7/build/langtools: Added tag jdk7-b29 for changeset dec081837b01 Message-ID: <20080624191453.5FB6128251@hg.openjdk.java.net> Changeset: c3f2b8992300 Author: xdono Date: 2008-06-20 08:45 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/c3f2b8992300 Added tag jdk7-b29 for changeset dec081837b01 ! .hgtags From thunderaxiom at gmail.com Tue Jun 24 13:34:25 2008 From: thunderaxiom at gmail.com (=?ISO-8859-1?Q?Thorbj=F8rn_Ravn_Andersen?=) Date: Tue, 24 Jun 2008 22:34:25 +0200 Subject: Trying to build openjdk7 under opensolaris Message-ID: <48615A51.3060404@gmail.com> Hi. I have tried to get an OpenSolaris build environment for OpenJDK7 up and running (just for the fun of it), and have installed ss-dev and updated everything as much as I could. The forrest should be up to date as of the time of writing. My problem right now is that the "gmake" fails with gmake[5]: CC: Command not found (see output below) and I have set both COMPILER_PATH and ALT_COMPILER_PATH (see below). Have I missed a configuration setting? Thanks in advance, /Thorbj?rn --- Output from "export" looks like: -- ravn at bean:~/download/openjdk/jdk7/jdk7$ export declare -x ALT_BINARY_PLUGS_PATH="/export/home/ravn/download/openjdk/jdk7/plugins/openjdk-binary-plugs/" declare -x ALT_COMPILER_PATH="/opt/SunStudioExpress/bin/" declare -x ALT_CUPS_HEADERS_PATH="/export/home/ravn/download/cups-install/include/" declare -x COMPILER_PATH="/opt/SunStudioExpress/bin/" declare -x HOME="/export/home/ravn" declare -x LANG="C" declare -x LOGNAME="ravn" declare -x MAIL="/var/mail/ravn" declare -x MANPATH="/usr/gnu/share/man:/usr/share/man:/usr/X11/share/man" declare -x OLDPWD="/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/make" declare -x PAGER="/usr/bin/less -ins" declare -x PATH="/export/home/ravn/download/findbugs-1.3.4/bin:/export/home/ravn/gnu/bin:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin" declare -x PWD="/export/home/ravn/download/openjdk/jdk7/jdk7" declare -x SHELL="/bin/bash" declare -x SHLVL="1" declare -x SSH_CLIENT="192.168.0.13 2143 22" declare -x SSH_CONNECTION="192.168.0.13 2143 192.168.0.10 22" declare -x SSH_TTY="/dev/pts/3" declare -x TERM="xterm" declare -x TZ="Europe/Copenhagen" declare -x USER="ravn" -- and output just before the failure ----- cd ./hotspot/make && \ gmake JDK_TOPDIR=/export/home/ravn/download/openjdk/jdk7/jdk7/jdk JDK_MAKE_SHARED_DIR=/export/home/ravn/download/openjdk/jdk7/jdk7/jdk/make/common/shared EXTERNALSANITYCONTROL=true TARGET_CLASS_VERSION=5 MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-internal-ravn_2008_06_24_22_20-b00 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=32 COOKED_BUILD_NUMBER=0 ALT_OUTPUTDIR=/export/home/ravn/download/openjdk/jdk7/jdk7/build/solaris-i586/hotspot/outputdir ALT_EXPORT_PATH=/export/home/ravn/download/openjdk/jdk7/jdk7/build/solaris-i586/hotspot/import ALT_SLASH_JAVA=/NOT-SET ALT_BOOTDIR=/usr/jdk/instances/jdk1.6.0 ALT_LANGTOOLS_DIST=/export/home/ravn/download/openjdk/jdk7/jdk7/build/solaris-i586/langtools/dist all_product gmake[1]: Entering directory `/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/make' cd /export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/make; \ gmake VM_TARGET=product generic_build2 ALT_OUTPUTDIR=/export/home/ravn/download/openjdk/jdk7/jdk7/build/solaris-i586/hotspot/outputdir gmake[2]: Entering directory `/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/make' mkdir -p /export/home/ravn/download/openjdk/jdk7/jdk7/build/solaris-i586/hotspot/outputdir cd /export/home/ravn/download/openjdk/jdk7/jdk7/build/solaris-i586/hotspot/outputdir; \ gmake -f /export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/make/solaris/Makefile \ JAVA_HOME=/usr/jdk/instances/jdk1.6.0 GAMMADIR=/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot MAKE_VERBOSE=y HOTSPOT_RELEASE_VERSION=13.0-b02 JRE_RELEASE_VERSION=1.7.0-internal-ravn_2008_06_24_22_20-b00 HOTSPOT_BUILD_VERSION= product gmake[3]: Entering directory `/export/home/ravn/download/openjdk/jdk7/jdk7/build/solaris-i586/hotspot/outputdir' cd solaris_i486_compiler2/product && gmake -w WARNING: You are using CC version /bin/sh: line 1: CC: not found and should be using version 5.8 WARNING: You are using cc version cc: `-V' option must have argument and should be using version 5.8 expr: syntax error expr: syntax error expr: syntax error expr: syntax error expr: syntax error gmake[4]: Entering directory `/export/home/ravn/download/openjdk/jdk7/jdk7/build/solaris-i586/hotspot/outputdir/solaris_i486_compiler2/product' WARNING: You are using CC version /bin/sh: line 1: CC: not found and should be using version 5.8 WARNING: You are using cc version cc: `-V' option must have argument and should be using version 5.8 expr: syntax error expr: syntax error expr: syntax error expr: syntax error expr: syntax error gmake[5]: Entering directory `/export/home/ravn/download/openjdk/jdk7/jdk7/build/solaris-i586/hotspot/outputdir/solaris_i486_compiler2/product' Compiling /export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/adlc/adlparse.cpp rm -f ../generated/adfiles/adlparse.o CC -DSOLARIS -DSPARC_WORKS -DIA32 -DASSERT -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/asm -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/c1 -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/ci -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/classfile -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/code -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/compiler -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/gc_implementation -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/gc_implementation/shared -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/gc_implementation/parallelScavenge -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/gc_implementation/parNew -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/gc_interface -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/interpreter -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/libadt -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/memory -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/oops -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/opto -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/prims -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/runtime -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/services -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/utilities -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/cpu/x86/vm -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/os/solaris/vm -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/os_cpu/solaris_x86/vm -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/adlc -I../generated -DCOMPILER2 -DCOMPILER1 -DSOLARIS_7_OR_LATER -D_REENTRANT -library=Cstd -g -c -o ../generated/adfiles/adlparse.o /export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/adlc/adlparse.cpp gmake[5]: CC: Command not found gmake[5]: *** [../generated/adfiles/adlparse.o] Error 127 From gnu_andrew at member.fsf.org Tue Jun 24 13:33:06 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 24 Jun 2008 21:33:06 +0100 Subject: javax.script rhino (javascript) support added In-Reply-To: <48613DD6.5090402@sun.com> References: <1214213379.32610.44.camel@dijkstra.wildebeest.org> <485FEEC3.8040102@sun.com> <1214255183.3308.9.camel@hermans.wildebeest.org> <48601F1D.3040604@sun.com> <17c6771e0806240101pa0b16d3p8e81b2b0caf8db2b@mail.gmail.com> <48613DD6.5090402@sun.com> Message-ID: <17c6771e0806241333w6476f4f6r4e10baed75201898@mail.gmail.com> On 24/06/2008, David Herron wrote: > Andrew John Hughes wrote: > > > 2008/6/23 Dalibor Topic : > > > > > > > Mark Wielaard wrote: > > > > > > > > OT, but the mention of binary plugs in the slides made me question > > whether they are still relevant given IcedTea passed > > the JCK without any? For OpenJDK6, is this now just the optional SNMP > > support? It would be good if someone could > > make it clear what's still needed for OpenJDK6 and OpenJDK7 (which > > seem to differ in this respect too). > > IcedTea probably needs a cleanout in terms of long-dead binary plugs > > it still tries to provide. > > > > > > The slides were originally written in Feb/March back when we still needed > the plugs. And at the time of JavaOne none of us had incorporated Gervill. > I did say in the session that we were all on the verge of being 100% and > that soon the plugs wouldn't be required. > Well, we've always done it without plugs, but then we're crazy Free Software people... ;) > Duke is bald and every time I see 'plugs' it makes me think of hair plugs > and Duke with hair doesn't make sense. So of course the plugs have to go. > Ha ha, that's just hilarious! I love the image. > - David Herron > > > > -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From thunderaxiom at gmail.com Tue Jun 24 13:39:56 2008 From: thunderaxiom at gmail.com (=?ISO-8859-1?Q?Thorbj=F8rn_Ravn_Andersen?=) Date: Tue, 24 Jun 2008 22:39:56 +0200 Subject: Ability to override compiler from environment In-Reply-To: <1ccfd1c10806241057n718fc035k9a31017d7668bf54@mail.gmail.com> References: <486020E4.1070109@sun.com> <1ccfd1c10806241057n718fc035k9a31017d7668bf54@mail.gmail.com> Message-ID: <48615B9C.7050401@gmail.com> Martin Buchholz skrev den 24-06-2008 19:57: > > --- > > I am in favor of the fundamental change to a "configure + make" model, > instead of configury stuff being done in the Makefiles as is the > current practice. > I agree, but I have understood that this work has been done in IcedTea already. Is there any estimate when these two codebases may converge? -- Thorbj?rn From Dmitri.Trembovetski at Sun.COM Tue Jun 24 14:51:32 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Tue, 24 Jun 2008 14:51:32 -0700 Subject: Ability to override compiler from environment In-Reply-To: <48615B9C.7050401@gmail.com> References: <486020E4.1070109@sun.com> <1ccfd1c10806241057n718fc035k9a31017d7668bf54@mail.gmail.com> <48615B9C.7050401@gmail.com> Message-ID: <48616C64.1080701@Sun.COM> Thorbj?rn Ravn Andersen wrote: > Martin Buchholz skrev den 24-06-2008 19:57: >> >> --- >> >> I am in favor of the fundamental change to a "configure + make" model, >> instead of configury stuff being done in the Makefiles as is the >> current practice. >> > I agree, but I have understood that this work has been done in IcedTea > already. Is there any estimate when these two codebases may converge? Does IcedTea configure+make model work on platforms other than linux? OpenJDK has to be built at least on Solaris and Windows. It's my understanding that Windows is the greatest pain in terms of build environment. Thanks, Dmitri From gnu_andrew at member.fsf.org Tue Jun 24 17:45:18 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 25 Jun 2008 01:45:18 +0100 Subject: javax.script rhino (javascript) support added In-Reply-To: <17c6771e0806240220x2436d7b5g20bf44de3a1c5efc@mail.gmail.com> References: <1214213379.32610.44.camel@dijkstra.wildebeest.org> <485FEEC3.8040102@sun.com> <1214255183.3308.9.camel@hermans.wildebeest.org> <48601F1D.3040604@sun.com> <17c6771e0806240101pa0b16d3p8e81b2b0caf8db2b@mail.gmail.com> <4860AD4A.3020301@sun.com> <17c6771e0806240220x2436d7b5g20bf44de3a1c5efc@mail.gmail.com> Message-ID: <17c6771e0806241745q4187bda8h7bed6d469ba0b1dd@mail.gmail.com> On 24/06/2008, Andrew John Hughes wrote: > 2008/6/24 Joseph D. Darcy : > > > Yes, since b07 back in March, *no* binary plugs are required to build the > > OpenJDK 6 sources from Sun. The only remaining plug is for SNMP support, > > which is not required functionality according to the platform spec and is > > thus not tested by the JCK. IIRC, JDK 7 may still have a plug for sound > > since I don't think Gervill has been integrated there yet. > > > > -Joe > > > > > Ah great, I thought that was the case. IcedTea6 is still adding SNMP > stubs, which > should be dropped. > > OpenJDK7 does still have a sound plug. IcedTea7 patches in Gervill in > its place (or should do -- I haven't fully tested this yet). > > Thanks, > > -- > Andrew :-) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > I've looked a bit further at this this evening. Unfortunately, although we get rid of the spurious .so files we generate pretty easily (libdcpr.so and libjsoundhs.so), the import of the JMX stubs is a little more complicated as we've 'abused' the plugs method for adding NetX. Thus, we need to first make NetX part of the JDK build via the overlays directory. We can then turn on IMPORT_BINARY_PLUGS=false :) -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From mark at klomp.org Wed Jun 25 01:03:52 2008 From: mark at klomp.org (Mark Wielaard) Date: Wed, 25 Jun 2008 10:03:52 +0200 Subject: Ability to override compiler from environment In-Reply-To: <48616C64.1080701@Sun.COM> References: <486020E4.1070109@sun.com> <1ccfd1c10806241057n718fc035k9a31017d7668bf54@mail.gmail.com> <48615B9C.7050401@gmail.com> <48616C64.1080701@Sun.COM> Message-ID: <1214381032.5507.13.camel@dijkstra.wildebeest.org> Hi, On Tue, 2008-06-24 at 14:51 -0700, Dmitri Trembovetski wrote: > Thorbj?rn Ravn Andersen wrote: > > Martin Buchholz skrev den 24-06-2008 19:57: > >> I am in favor of the fundamental change to a "configure + make" model, > >> instead of configury stuff being done in the Makefiles as is the > >> current practice. > >> > > I agree, but I have understood that this work has been done in IcedTea > > already. Is there any estimate when these two codebases may converge? > > Does IcedTea configure+make model work on platforms other than > linux? OpenJDK has to be built at least on Solaris and Windows. > > It's my understanding that Windows is the greatest pain in > terms of build environment. It should work on (open)solaris, but I haven't tried myself. I doubt anybody ever tried it on windows. In theory with cygwin you should be able to get enough of the gnu toolchain to get it working. But icedtea autotools support was also added to make bootstrapping through other libre java implementations like gcj possible. The cygwin gcj port however is, as far as I know, still a version behind the version we really need (including 1.5 language support). That said, there is a --with-openjdk configure flag that should in theory work as soon as you have an pre-existing openjdk build already. But we would indeed need testers for that platform. For some reason it isn't a very popular development platform for Free Software hackers. Cheers, Mark From aph at redhat.com Wed Jun 25 03:06:31 2008 From: aph at redhat.com (Andrew Haley) Date: Wed, 25 Jun 2008 11:06:31 +0100 Subject: Ability to override compiler from environment In-Reply-To: <48615B9C.7050401@gmail.com> References: <486020E4.1070109@sun.com> <1ccfd1c10806241057n718fc035k9a31017d7668bf54@mail.gmail.com> <48615B9C.7050401@gmail.com> Message-ID: <486218A7.1090100@redhat.com> Thorbj?rn Ravn Andersen wrote: > Martin Buchholz skrev den 24-06-2008 19:57: >> >> --- >> >> I am in favor of the fundamental change to a "configure + make" model, >> instead of configury stuff being done in the Makefiles as is the >> current practice. >> > I agree, but I have understood that this work has been done in IcedTea > already. No, it hasn't. We've only made a top-level wrapper script: the rest hasn't changed. Andrew. From Alex.Potanin at mcs.vuw.ac.nz Tue Jun 24 18:51:56 2008 From: Alex.Potanin at mcs.vuw.ac.nz (Alex Potanin) Date: Wed, 25 Jun 2008 13:51:56 +1200 Subject: [NEW BUG] Running jtreg tests on NetBSD Message-ID: <4861A4BC.2090801@mcs.vuw.ac.nz> Hello, I am working on the javac extension and I tried to run the javac tests in the OpenJDK's latest Mercurial repository. I see that a few of them contain the following in the shell scripts: # set platform-dependent variables OS=`uname -s` case "$OS" in SunOS | Linux ) NULL=/dev/null PS=":" FS="/" ;; Windows* ) NULL=NUL PS=";" FS="\\" ;; * ) echo "Unrecognized system!" exit 1; ;; esac Since I use NetBSD, my 'uname -s' returns NetBSD. I had to add "| NetBSD" to the "SunOS | Linux" line to fix the test scripts so that they don't return "Unrecognized system!". Some of the affected scripts are: tools/javac/4846262/Test.sh tools/javac/6302184/T6302184.sh tools/javac/ClassPathTest/ClassPathTest.sh But there are others that I can find if required (I suspect grepping will do a good job). I was wondering if it can please be fixed to take NetBSD into account or whether there is a better way of fixing this? Thanks, Alex. -------------- next part -------------- A non-text attachment was scrubbed... Name: Alex_Potanin.vcf Type: text/x-vcard Size: 374 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/build-dev/attachments/20080625/313e8447/attachment.vcf From Dmitri.Trembovetski at Sun.COM Wed Jun 25 08:45:18 2008 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Wed, 25 Jun 2008 08:45:18 -0700 Subject: Ability to override compiler from environment In-Reply-To: <1214381032.5507.13.camel@dijkstra.wildebeest.org> References: <486020E4.1070109@sun.com> <1ccfd1c10806241057n718fc035k9a31017d7668bf54@mail.gmail.com> <48615B9C.7050401@gmail.com> <48616C64.1080701@Sun.COM> <1214381032.5507.13.camel@dijkstra.wildebeest.org> Message-ID: <4862680E.6010807@Sun.COM> Hi Mark, Mark Wielaard wrote: >>> I agree, but I have understood that this work has been done in IcedTea >>> already. Is there any estimate when these two codebases may converge? >> Does IcedTea configure+make model work on platforms other than >> linux? OpenJDK has to be built at least on Solaris and Windows. >> >> It's my understanding that Windows is the greatest pain in >> terms of build environment. > > It should work on (open)solaris, but I haven't tried myself. I doubt I doubt that it would work out of the box since on solaris we use SunStudio compilers and not gcc so that would need to be addressed by the configure script. I doubt that we'll be switching to gcc for solaris compilation any time soon. > anybody ever tried it on windows. In theory with cygwin you should be > able to get enough of the gnu toolchain to get it working. But icedtea Theories seldom work well when applied to Windows, unfortunately, as Kelly would attest. But I guess we won't know until we try. > autotools support was also added to make bootstrapping through other > libre java implementations like gcj possible. The cygwin gcj port > however is, as far as I know, still a version behind the version we > really need (including 1.5 language support). That said, there is a > --with-openjdk configure flag that should in theory work as soon as you > have an pre-existing openjdk build already. But we would indeed need > testers for that platform. For some reason it isn't a very popular > development platform for Free Software hackers. How the Free Software hackers would ensure that their changes to the shared code in the openjdk don't break Windows if they never build or test there? Unfortunately that could easily happen (and did in the past). Thanks, Dmitri From Jonathan.Gibbons at Sun.COM Wed Jun 25 10:33:35 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Wed, 25 Jun 2008 10:33:35 -0700 Subject: building OpenJDK on Ubuntu 7.10 Message-ID: <4862816F.7060106@sun.com> I'm setting up Ubuntu 7.10 to build JDK, and I'm looking at the info here: http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html There isn't a section for 7.10, but 7.04 comes pretty close. The only issue is the xlibs-dev package. Does anyone have a suggestion on how to fix this? -- Jon $ sudo apt-get install xlibs-dev Reading package lists... Done Building dependency tree Reading state information... Done Package xlibs-dev is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package xlibs-dev has no installation candidate From David.Herron at Sun.COM Wed Jun 25 11:35:18 2008 From: David.Herron at Sun.COM (David Herron) Date: Wed, 25 Jun 2008 11:35:18 -0700 Subject: building OpenJDK on Ubuntu 7.10 In-Reply-To: <4862816F.7060106@sun.com> References: <4862816F.7060106@sun.com> Message-ID: <48628FE6.9060001@sun.com> Jonathan Gibbons wrote: > I'm setting up Ubuntu 7.10 to build JDK, and I'm looking at the info > here: > http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html > > There isn't a section for 7.10, but 7.04 comes pretty close. The only > issue > is the xlibs-dev package. Does anyone have a suggestion on how to fix > this? > > -- Jon > > $ sudo apt-get install xlibs-dev > Reading package lists... Done > Building dependency tree > Reading state information... Done > Package xlibs-dev is not available, but is referred to by another > package. > This may mean that the package is missing, has been obsoleted, or > is only available from another source > E: Package xlibs-dev has no installation candidate > Jon, Compiles on 7.10 work pretty readily but you have to get the right X libraries installed. Compiles on 7.10 is even easier because the GCC version on 7.10 doesn't complain about the string casts in Hotspot which the GCC version on 8.04 complains about. That package existed to cause inclusion of a slew of X libraries & headers. I thought there was still a package for this purpose, but I cannot find it (on 8.04) On 8.04 I have these libraries installed:- libx11-dev libx11-xcb-dev libxau-dev libxcb1-dev libxcb-xlib0-dev libxdmcp-dev libxext-dev The ones with xcb in their name probably do not exist on 7.10 - David Herron From Jonathan.Gibbons at Sun.COM Wed Jun 25 11:48:36 2008 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Wed, 25 Jun 2008 11:48:36 -0700 Subject: building OpenJDK on Ubuntu 7.10 In-Reply-To: <48628FE6.9060001@sun.com> References: <4862816F.7060106@sun.com> <48628FE6.9060001@sun.com> Message-ID: <48629304.4070007@sun.com> Thanks. By trial and error, I determined that I only needed two packages over the list for 7.04. libxtst-dev libxi-dev That's enough to build OpenJDK images; I haven't tried running it yet :-) -- Jon David Herron wrote: > Jonathan Gibbons wrote: >> I'm setting up Ubuntu 7.10 to build JDK, and I'm looking at the info >> here: >> http://hg.openjdk.java.net/jdk7/build/raw-file/tip/README-builds.html >> >> There isn't a section for 7.10, but 7.04 comes pretty close. The only >> issue >> is the xlibs-dev package. Does anyone have a suggestion on how to >> fix this? >> >> -- Jon >> >> $ sudo apt-get install xlibs-dev >> Reading package lists... Done >> Building dependency tree >> Reading state information... Done >> Package xlibs-dev is not available, but is referred to by another >> package. >> This may mean that the package is missing, has been obsoleted, or >> is only available from another source >> E: Package xlibs-dev has no installation candidate >> > > Jon, > > Compiles on 7.10 work pretty readily but you have to get the right X > libraries installed. Compiles on 7.10 is even easier because the GCC > version on 7.10 doesn't complain about the string casts in Hotspot > which the GCC version on 8.04 complains about. > > That package existed to cause inclusion of a slew of X libraries & > headers. > I thought there was still a package for this purpose, but I cannot > find it (on 8.04) > > On 8.04 I have these libraries installed:- > > libx11-dev > libx11-xcb-dev > libxau-dev > libxcb1-dev > libxcb-xlib0-dev > libxdmcp-dev > libxext-dev > > The ones with xcb in their name probably do not exist on 7.10 > > - David Herron > From thunderaxiom at gmail.com Wed Jun 25 12:14:09 2008 From: thunderaxiom at gmail.com (=?UTF-8?B?VGhvcmJqw7hybiBSYXZuIEFuZGVyc2Vu?=) Date: Wed, 25 Jun 2008 21:14:09 +0200 Subject: Ability to override compiler from environment In-Reply-To: <48628460.9010905@Sun.COM> References: <486020E4.1070109@sun.com> <1ccfd1c10806241057n718fc035k9a31017d7668bf54@mail.gmail.com> <48615B9C.7050401@gmail.com> <48616C64.1080701@Sun.COM> <48617135.9060504@gmail.com> <48628460.9010905@Sun.COM> Message-ID: <48629901.6020203@gmail.com> Dmitri Trembovetski skrev den 25-06-2008 19:46: > > Hi, > > did you mean to CC the list in your reply? No, I just wanted to write to the list. Is the "CC list with no reply-to header" the traditional way it's done inside Sun? My fingers just do a Reply so I get it wrong - oh well, I only did it twice today. >> The configure script runs a lot of small code snippets and store the >> results as a single configuration file. Typically you need to >> identify stuff like "what is the name of an awk which has the >> extensions we need?", "is the library X available?", "do we have a >> working compiler toolchain?" etc. You may want to try compiling gcc >> (use "configure; make bootstrap") or Emacs ("configure; make") to see >> how this works in practice. > > I do know how configure works. My question was whether anyone > tried to build icedtea on windows. The answer is apparently not. My apologies. It wasn't clear to me. Are all these Makefiles currently in the tree manually maintained? >>> It's my understanding that Windows is the greatest pain in >>> terms of build environment. >> It appears so. I would appreciate hearing from those familiar with >> that environment how this would be done there? > > You'd have to wait until our build master Kelly comes back from > vacation. Currently jdk build on windows uses either MKS tookit > or cygwin, Microsoft Visual Studio 2003 (soon to be moved to > 2008). The main pain point is the way cygwin/mks handle > windows paths. It's not very consistent and make files > break very easily. We'll take the discussion then, then. Perhaps it is a matter of hardening the cygwin make, or to see if there is a Make implementation in Java that might be usable? I am aware that this is a time tested build environment but it still appears very brittle. I'm looking forward to learning more about the decisions made to where it is today. -- Thorbj?rn From thunderaxiom at gmail.com Wed Jun 25 14:53:19 2008 From: thunderaxiom at gmail.com (=?UTF-8?B?VGhvcmJqw7hybiBSYXZuIEFuZGVyc2Vu?=) Date: Wed, 25 Jun 2008 23:53:19 +0200 Subject: Ability to override compiler from environment In-Reply-To: <1214381032.5507.13.camel@dijkstra.wildebeest.org> References: <486020E4.1070109@sun.com> <1ccfd1c10806241057n718fc035k9a31017d7668bf54@mail.gmail.com> <48615B9C.7050401@gmail.com> <48616C64.1080701@Sun.COM> <1214381032.5507.13.camel@dijkstra.wildebeest.org> Message-ID: <4862BE4F.7010707@gmail.com> Mark Wielaard skrev den 25-06-2008 10:03: > Hi, > > On Tue, 2008-06-24 at 14:51 -0700, Dmitri Trembovetski wrote: > >> Thorbj?rn Ravn Andersen wrote: >> >>> Martin Buchholz skrev den 24-06-2008 19:57: >>> >>>> I am in favor of the fundamental change to a "configure + make" model, >>>> instead of configury stuff being done in the Makefiles as is the >>>> current practice. >>>> >>>> >>> I agree, but I have understood that this work has been done in IcedTea >>> already. Is there any estimate when these two codebases may converge? >>> >> Does IcedTea configure+make model work on platforms other than >> linux? OpenJDK has to be built at least on Solaris and Windows. >> >> It's my understanding that Windows is the greatest pain in >> terms of build environment. >> > > It should work on (open)solaris, but I haven't tried myself. I doubt > > I gave it a try again, just to see what happens. The script first looks for an awk and finds /usr/bin/nawk, and then explicitly later looks for gawk. export GAWK=/usr/bin/nawk got me over that test. It requires both an ecj.jar and a libgcj.jar. Are both necessary? A "-bash-3.2$ ./configure --with-ecj-jar=/export/home/ravn/download/ecj.jar --with-ecj --with-libgcj-jar=/export/home/ravn/download/ecj.jar --with-xalan2-jar=/export/home/ravn/download/ecj.jar --with-xalan2-serializer-jar=/export/home/ravn/download/ecj.jar --with-xerces2-jar=/export/home/ravn/download/ecj.jar" got me to configure: error: "motif headers were not found - try installing lesstif-devel." which I now remember to be the place where I gave up the last time as apparently Motif is not available under OpenSolaris and "pkg search lesstif" did not show any packages. I'll look at building lesstif and see what happens then... /Thorbj?rn From gnu_andrew at member.fsf.org Wed Jun 25 15:14:37 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 25 Jun 2008 23:14:37 +0100 Subject: Ability to override compiler from environment In-Reply-To: <4862680E.6010807@Sun.COM> References: <486020E4.1070109@sun.com> <1ccfd1c10806241057n718fc035k9a31017d7668bf54@mail.gmail.com> <48615B9C.7050401@gmail.com> <48616C64.1080701@Sun.COM> <1214381032.5507.13.camel@dijkstra.wildebeest.org> <4862680E.6010807@Sun.COM> Message-ID: <17c6771e0806251514m612a6e52m47d01ee404b98150@mail.gmail.com> On 25/06/2008, Dmitri Trembovetski wrote: > > > snip.. > > anybody ever tried it on windows. In theory with cygwin you should be > > able to get enough of the gnu toolchain to get it working. But icedtea > > > > Theories seldom work well when applied to Windows, unfortunately, > as Kelly would attest. But I guess we won't know until we try. > > I can guarantee that configure will fail on Windows; it tests for ALSA and fails if it isn't found. I think this is stopping Mac OS X and probably will stop OpenSolaris too so probably should be made optional. twisti, how did you get round this for OpenSolaris? I also think the fact that it tests for X headers and libraries would be a fundamental flaw. They may be present with cygwin but I doubt that the X peers will be built on Microsoft Windows. > > autotools support was also added to make bootstrapping through other > > libre java implementations like gcj possible. The cygwin gcj port > > however is, as far as I know, still a version behind the version we > > really need (including 1.5 language support). That said, there is a > > --with-openjdk configure flag that should in theory work as soon as you > > have an pre-existing openjdk build already. But we would indeed need > > testers for that platform. For some reason it isn't a very popular > > development platform for Free Software hackers. > > > > How the Free Software hackers would ensure that their changes > to the shared code in the openjdk don't break Windows if they > never build or test there? Unfortunately that could easily > happen (and did in the past). > I had this thought when reading the OpenJDK developers guide. I think a continuous build system is needed for OpenJDK in the very near future, if you want to guarantee this. FOSS developers aren't going to use a non-Free platform like Windows, and are unlikely to use a partially non-Free one like OpenSolaris. I don't see any reason IcedTea couldn't be built on other platforms as well. I think it's a generally useful tool while the build system remains as is in OpenJDK: * It remembers the 37 or so environment variables used to configure the OpenJDK build. I'd end up doing something similar myself if it wasn't for IcedTea via a script. * It tests for dependencies *apriori*. Some of this is done by the sanity check in OpenJDK, but I don't believe it checks as much and the checks are nowhere near as easy to create. * As Mark mentioned, it allows the existing Free Java environments to be used to build. This is essential until OpenJDK is ubiquitous, which will take time. For these reasons, I'd use IcedTea even if it wasn't applying patches to fix issues or overlaying additional stuff like javaws, gcjwebplugin, Gervill and Rhino. On a side note, can someone tell me why IMPORT_BINARY_PLUGS is still true by default even though the SNMP plugin is optional now (and thus no plugs are needed). I think the great work in making OpenJDK6 encumbrance free has largely been missed by many people -- it took me a failed build and grep to work out that I needed this option which doesn't seem to be documented. > Thanks, > Dmitri > > -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Wed Jun 25 15:16:28 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 25 Jun 2008 23:16:28 +0100 Subject: Ability to override compiler from environment In-Reply-To: <486024E7.5040503@sun.com> References: <486020E4.1070109@sun.com> <486024E7.5040503@sun.com> Message-ID: <17c6771e0806251516u73987c19g5584c0004fec6843@mail.gmail.com> This does seem to happen with JAVAC. At least, I've had build failures though Gentoo setting JAVAC. The CORBA and JDK builds then use this variable which will never work because not only is the compiler binary name replaced, but options such as the bootclasspath are lost too. This is why IcedTea has JAVAC= now :) On 23/06/2008, Jonathan Gibbons wrote: > David, > > Some would say that it is a feature of the current build system that random > environment variables don't get used :-) It makes it that much harder to > get a predictable build. > > -- Jon > > > > David Herron wrote: > > > I was thinking about this issue of compiling with different gcc's and it > seems the normal way to install multiple gcc's is to use suffixes for the > version like so:- > > > > gcc-4.1 == gcc v4.1.x > > gcc-3.4 == gcc v3.4.x > > gcc == gcc v4.2.x > > > > I groped around the OpenJDK makefiles and found > > > > jdk/make/common/shared/Compiler-gcc.gmk > > corba/make/common/shared/Compiler-gcc.gmk > > hotspot/build/linux/makefiles/gcc.make > > > > both contain lines which say > > > > CC=gcc > > CPP=g++ > > > > According to the GNU make manual .. > http://www.gnu.org/software/make/manual/html_node/Setting.html#Setting > .. these values could be overridden with a small change in the makefile > > > > CC?=gcc > > CPP?=g++ > > > > And then setting CC or CPP in the environment would make it so the > variable is already set and these lines in the makefile would have no > effect. > > > > > > > > - David Herron > > > > > > > > -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From mark at klomp.org Wed Jun 25 23:10:48 2008 From: mark at klomp.org (Mark Wielaard) Date: Thu, 26 Jun 2008 08:10:48 +0200 Subject: Ability to override compiler from environment In-Reply-To: <4862680E.6010807@Sun.COM> References: <486020E4.1070109@sun.com> <1ccfd1c10806241057n718fc035k9a31017d7668bf54@mail.gmail.com> <48615B9C.7050401@gmail.com> <48616C64.1080701@Sun.COM> <1214381032.5507.13.camel@dijkstra.wildebeest.org> <4862680E.6010807@Sun.COM> Message-ID: <1214460648.3062.30.camel@dijkstra.wildebeest.org> Hi Dimitri, On Wed, 2008-06-25 at 08:45 -0700, Dmitri Trembovetski wrote: > Mark Wielaard wrote: > >>> I agree, but I have understood that this work has been done in IcedTea > >>> already. Is there any estimate when these two codebases may converge? > >> Does IcedTea configure+make model work on platforms other than > >> linux? OpenJDK has to be built at least on Solaris and Windows. > >> > >> It's my understanding that Windows is the greatest pain in > >> terms of build environment. > > > > It should work on (open)solaris, but I haven't tried myself. I doubt > > I doubt that it would work out of the box since on solaris we use > SunStudio compilers and not gcc so that would need to be > addressed by the configure script. I doubt that we'll be switching > to gcc for solaris compilation any time soon. O yes, you are right. We should of course first make sure the build only uses free tools. Using the proprietary studio tools would be no fun and kind of defeat the whole purpose of icedtea. > > autotools support was also added to make bootstrapping through other > > libre java implementations like gcj possible. The cygwin gcj port > > however is, as far as I know, still a version behind the version we > > really need (including 1.5 language support). That said, there is a > > --with-openjdk configure flag that should in theory work as soon as you > > have an pre-existing openjdk build already. But we would indeed need > > testers for that platform. For some reason it isn't a very popular > > development platform for Free Software hackers. > > How the Free Software hackers would ensure that their changes > to the shared code in the openjdk don't break Windows if they > never build or test there? Unfortunately that could easily > happen (and did in the past). You post patches and review the code, have various hackers and autobuilders build and run the code and if a regression does slip through you revert it till all primary platforms supported work with a correct patch. Of course it depends on there being enough hackers around for each primary platform to catch any issues for that platform. But that is always the case isn't it? It seems that in the case of OpenJDK and Windows at the moment there are still seem enough people interested and using it as their primary development platform to keep it working. Cheers, Mark From mark at klomp.org Wed Jun 25 23:31:10 2008 From: mark at klomp.org (Mark Wielaard) Date: Thu, 26 Jun 2008 08:31:10 +0200 Subject: Ability to override compiler from environment In-Reply-To: <4862BE4F.7010707@gmail.com> References: <486020E4.1070109@sun.com> <1ccfd1c10806241057n718fc035k9a31017d7668bf54@mail.gmail.com> <48615B9C.7050401@gmail.com> <48616C64.1080701@Sun.COM> <1214381032.5507.13.camel@dijkstra.wildebeest.org> <4862BE4F.7010707@gmail.com> Message-ID: <1214461870.3062.47.camel@dijkstra.wildebeest.org> Hi Thorbj?rn, On Wed, 2008-06-25 at 23:53 +0200, Thorbj?rn Ravn Andersen wrote: > I gave it a try again, just to see what happens. > > The script first looks for an awk and finds /usr/bin/nawk, and then > explicitly later looks for gawk. export GAWK=/usr/bin/nawk got me over > that test. It explicitly tests for gawk since that is what the build says it requires. dnl OpenJDK's README-builds.html lists gawk as a build dependency so we dnl check for it explicitly rather than using AC_PROG_AWK. FIND_TOOL([GAWK], [gawk]) > It requires both an ecj.jar and a libgcj.jar. Are both necessary? Yes, one is a compiler and one is a core class library set. > A "-bash-3.2$ ./configure > --with-ecj-jar=/export/home/ravn/download/ecj.jar --with-ecj > --with-libgcj-jar=/export/home/ravn/download/ecj.jar > --with-xalan2-jar=/export/home/ravn/download/ecj.jar > --with-xalan2-serializer-jar=/export/home/ravn/download/ecj.jar > --with-xerces2-jar=/export/home/ravn/download/ecj.jar" got me to > configure: error: "motif headers were not found - > try installing lesstif-devel." > > which I now remember to be the place where I gave up the last time as > apparently Motif is not available under OpenSolaris and "pkg search > lesstif" did not show any packages. > > I'll look at building lesstif and see what happens then... This really shouldn't be necessary anymore. At least not for icedtea/jdk7, there might still be some header constants used in icedtea6/openjdk6, but if so we should backport the fixes to remove them and remove this check. Cheers, Mark From twisti at complang.tuwien.ac.at Thu Jun 26 02:17:26 2008 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Thu, 26 Jun 2008 11:17:26 +0200 Subject: Ability to override compiler from environment In-Reply-To: <1214461870.3062.47.camel@dijkstra.wildebeest.org> References: <486020E4.1070109@sun.com> <1ccfd1c10806241057n718fc035k9a31017d7668bf54@mail.gmail.com> <48615B9C.7050401@gmail.com> <48616C64.1080701@Sun.COM> <1214381032.5507.13.camel@dijkstra.wildebeest.org> <4862BE4F.7010707@gmail.com> <1214461870.3062.47.camel@dijkstra.wildebeest.org> Message-ID: <1214471846.3774.5.camel@cthalinger> On Thu, 2008-06-26 at 08:31 +0200, Mark Wielaard wrote: > > configure: error: "motif headers were not found - > > try installing lesstif-devel." > > > > which I now remember to be the place where I gave up the last time as > > apparently Motif is not available under OpenSolaris and "pkg search > > lesstif" did not show any packages. > > > > I'll look at building lesstif and see what happens then... > > This really shouldn't be necessary anymore. At least not for > icedtea/jdk7, there might still be some header constants used in > icedtea6/openjdk6, but if so we should backport the fixes to remove them > and remove this check. That would be really nice, as I am currently trying myself to get OpenJDK/IcedTea built on OpenSolaris. I'm currently stuck at finding an appropriate bootstrap JVM, as it seems Boehm-GC has some problems on Solaris. But this may be also a CACAO bug, I'll investigate this further... - twisti From twisti at complang.tuwien.ac.at Thu Jun 26 02:25:34 2008 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Thu, 26 Jun 2008 11:25:34 +0200 Subject: Ability to override compiler from environment In-Reply-To: <17c6771e0806251514m612a6e52m47d01ee404b98150@mail.gmail.com> References: <486020E4.1070109@sun.com> <1ccfd1c10806241057n718fc035k9a31017d7668bf54@mail.gmail.com> <48615B9C.7050401@gmail.com> <48616C64.1080701@Sun.COM> <1214381032.5507.13.camel@dijkstra.wildebeest.org> <4862680E.6010807@Sun.COM> <17c6771e0806251514m612a6e52m47d01ee404b98150@mail.gmail.com> Message-ID: <1214472334.3774.12.camel@cthalinger> On Wed, 2008-06-25 at 23:14 +0100, Andrew John Hughes wrote: > I can guarantee that configure will fail on Windows; it tests for ALSA > and fails if it isn't found. I think this is stopping Mac OS X and > probably will stop OpenSolaris too so probably should be made > optional. twisti, how did you get round this for OpenSolaris? - ,[AC_MSG_ERROR("motif headers were not found - + ,[AC_MSG_WARN("motif headers were not found - - AC_MSG_ERROR([Could not find alsa - \ + AC_MSG_WARN([Could not find alsa - \ :-) Of course I don't know what happens later in the build process, but I will see when I'm finally there. > On a side note, can someone tell me why IMPORT_BINARY_PLUGS is still > true by default even though the SNMP plugin is optional now (and thus > no plugs are needed). I think the great work in making OpenJDK6 > encumbrance free has largely been missed by many people -- it took me > a failed build and grep to work out that I needed this option which > doesn't seem to be documented. Yes, I missed that too. Thanks Andrew you told me that last night. - twisti From thunderaxiom at gmail.com Thu Jun 26 07:54:13 2008 From: thunderaxiom at gmail.com (=?UTF-8?B?VGhvcmJqw7hybiBSYXZuIEFuZGVyc2Vu?=) Date: Thu, 26 Jun 2008 16:54:13 +0200 Subject: Ability to override compiler from environment In-Reply-To: <1214461870.3062.47.camel@dijkstra.wildebeest.org> References: <486020E4.1070109@sun.com> <1ccfd1c10806241057n718fc035k9a31017d7668bf54@mail.gmail.com> <48615B9C.7050401@gmail.com> <48616C64.1080701@Sun.COM> <1214381032.5507.13.camel@dijkstra.wildebeest.org> <4862BE4F.7010707@gmail.com> <1214461870.3062.47.camel@dijkstra.wildebeest.org> Message-ID: <4863AD95.9020907@gmail.com> Mark Wielaard skrev den 26-06-2008 08:31: > >> The script first looks for an awk and finds /usr/bin/nawk, and then >> explicitly later looks for gawk. export GAWK=/usr/bin/nawk got me over >> that test. >> > > It explicitly tests for gawk since that is what the build says it > requires. > > Good reason! > dnl OpenJDK's README-builds.html lists gawk as a build dependency so we > dnl check for it explicitly rather than using AC_PROG_AWK. > FIND_TOOL([GAWK], [gawk]) > > >> It requires both an ecj.jar and a libgcj.jar. Are both necessary? >> > > Yes, one is a compiler and one is a core class library set. > But are they necessary if there is a Java6 JDK available? This IS Solaris :) >> I'll look at building lesstif and see what happens then... >> > > This really shouldn't be necessary anymore. At least not for > icedtea/jdk7, there might still be some header constants used in > icedtea6/openjdk6, but if so we should backport the fixes to remove them > and remove this check. > I think I'll continue this discussion up on the icetea list. My fingers cannot get used to the missing Reply-to header on this list. -- Thorbj?rn From xiomara.jayasena at sun.com Thu Jun 26 13:53:06 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Thu, 26 Jun 2008 20:53:06 +0000 Subject: hg: jdk7/build/jdk: 42 new changesets Message-ID: <20080626210123.B27E6284A1@hg.openjdk.java.net> Changeset: e733eea7d585 Author: peterz Date: 2008-05-22 15:06 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/e733eea7d585 6606443: Infinite loop in FlowView.layout when using HTML tables in JEditorPane Summary: FlowStrategy.damageStart now tracks position changes Reviewed-by: gsm ! src/share/classes/javax/swing/text/FlowView.java Changeset: e0951cd6e7b9 Author: malenkov Date: 2008-05-23 20:14 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/e0951cd6e7b9 6668273: Example given in java.beans.EventHandler shows incorrect order of parameters Summary: Very simple misprint Reviewed-by: peterz, loneid ! src/share/classes/java/beans/EventHandler.java Changeset: 5e0172d58a1c Author: mlapshin Date: 2008-05-26 17:58 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/5e0172d58a1c 6694823: A popup menu can be partially hidden under the task bar in applets Summary: In applets popup menu is shifted above the task bar Reviewed-by: peterz ! src/share/classes/javax/swing/JPopupMenu.java ! src/share/classes/javax/swing/PopupFactory.java + test/javax/swing/JPopupMenu/6694823/bug6694823.java Changeset: be7d7a297c3d Author: rupashka Date: 2008-06-02 19:08 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/be7d7a297c3d 6709530: There are unnecessary code in slider classes, such as in JSlider and SliderUIs Summary: Removed unnecessary code like unused variables, castings, imports etc Reviewed-by: peterz ! src/share/classes/javax/swing/JSlider.java ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java Changeset: af37dad9022d Author: rupashka Date: 2008-06-03 18:00 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/af37dad9022d 4987336: JSlider doesn't show label's animated icon Summary: JSlider registers as an image observer of label's icon Reviewed-by: alexp ! src/share/classes/javax/swing/JSlider.java ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java + test/javax/swing/JSlider/4987336/box.gif + test/javax/swing/JSlider/4987336/bug4987336.html + test/javax/swing/JSlider/4987336/bug4987336.java + test/javax/swing/JSlider/4987336/cupanim.gif Changeset: f36f0f189064 Author: rupashka Date: 2008-06-04 18:48 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/f36f0f189064 6571802: 'Shared Documents' listed in-between C,D drives in the JFileChooser, does not match with native Summary: now sun.awt.shell.ShellFolder#sort uses system sorting instead of alphabetical Reviewed-by: loneid, peterz ! src/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java ! src/share/classes/sun/awt/shell/ShellFolder.java ! src/share/classes/sun/awt/shell/ShellFolderManager.java ! src/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java Changeset: e26917dd7b7c Author: rupashka Date: 2008-06-05 13:30 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/e26917dd7b7c 6688110: JSlider has incorrect javadoc for the setValueIsAdjusting method Summary: The sentence about ChangeEvents generation was removed Reviewed-by: peterz ! src/share/classes/javax/swing/JSlider.java Changeset: 5083f5c15103 Author: rupashka Date: 2008-06-06 13:30 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/5083f5c15103 5035693: "Open" button should be a default one in JFileChooser under Windows XP LAF Summary: The "Open" button was made default button of FileChooser dialog windows Reviewed-by: loneid, peterz ! src/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/share/classes/javax/swing/JFileChooser.java ! src/share/classes/javax/swing/plaf/FileChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java Changeset: ec9c8e73ae53 Author: malenkov Date: 2008-06-18 19:15 +0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/ec9c8e73ae53 6708550: LTP: XMLEncoder does not encode instances of the File class Reviewed-by: peterz, loneid ! src/share/classes/java/io/File.java + test/java/beans/XMLEncoder/java_io_File.java Changeset: 3570562846ef Author: lana Date: 2008-06-18 13:05 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/3570562846ef Merge Changeset: fbb75a5c25ff Author: lana Date: 2008-06-25 08:54 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/fbb75a5c25ff Merge Changeset: f494f33398f1 Author: jjg Date: 2008-06-03 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/f494f33398f1 6708729: update jdk Makefiles for new javap Reviewed-by: ohair ! make/common/Release.gmk ! make/common/internal/Defs-langtools.gmk Changeset: 38a4f11764c0 Author: chegar Date: 2008-06-05 04:08 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/38a4f11764c0 6626677: Error: Unimplemented()/HPI sysMonitorExit is broken on linux Summary: Remove the definition of NEED_DL_LOCK on platforms with GLIBC Reviewed-by: dholmes, psoper ! src/solaris/hpi/src/linker_md.c Changeset: b715e82ef7e1 Author: emcmanus Date: 2008-06-05 13:40 +0200 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/b715e82ef7e1 6701498: Change JMX query language to use * and ? as wildcards rather than % and _ Reviewed-by: dfuchs ! src/share/classes/javax/management/MatchQueryExp.java ! src/share/classes/javax/management/ObjectName.java ! src/share/classes/javax/management/Query.java ! src/share/classes/javax/management/QueryNotificationFilter.java ! src/share/classes/javax/management/QueryParser.java ! test/javax/management/query/QueryExpStringTest.java ! test/javax/management/query/QueryParseTest.java Changeset: af0a68f46dde Author: emcmanus Date: 2008-06-05 13:42 +0200 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/af0a68f46dde 6562936: Support custom type mappings in MXBeans Reviewed-by: dfuchs ! src/share/classes/com/sun/jmx/mbeanserver/ConvertingMethod.java + src/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanAnalyzer.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanSupport.java ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanIntrospector.java ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanLookup.java ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanProxy.java ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanSupport.java ! src/share/classes/com/sun/jmx/mbeanserver/NotificationMBeanSupport.java - src/share/classes/com/sun/jmx/mbeanserver/OpenConverter.java ! src/share/classes/com/sun/jmx/mbeanserver/PerInterface.java ! src/share/classes/com/sun/jmx/mbeanserver/StandardMBeanSupport.java ! src/share/classes/javax/management/JMX.java ! src/share/classes/javax/management/MBeanServerInvocationHandler.java ! src/share/classes/javax/management/MXBean.java ! src/share/classes/javax/management/StandardMBean.java - src/share/classes/javax/management/ToQueryString.java ! src/share/classes/javax/management/openmbean/CompositeDataInvocationHandler.java ! src/share/classes/javax/management/openmbean/CompositeType.java + src/share/classes/javax/management/openmbean/MXBeanMapping.java + src/share/classes/javax/management/openmbean/MXBeanMappingClass.java + src/share/classes/javax/management/openmbean/MXBeanMappingFactory.java + src/share/classes/javax/management/openmbean/MXBeanMappingFactoryClass.java ! src/share/classes/javax/management/openmbean/OpenType.java + test/javax/management/mxbean/CustomTypeTest.java + test/javax/management/mxbean/customtypes/CustomLongMXBean.java + test/javax/management/mxbean/customtypes/CustomMXBean.java + test/javax/management/mxbean/customtypes/IntegerIsLongFactory.java + test/javax/management/mxbean/customtypes/IntegerIsStringFactory.java + test/javax/management/mxbean/customtypes/package-info.java Changeset: 657f24cdfc02 Author: sherman Date: 2008-06-05 16:19 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/657f24cdfc02 6710199: SJIS_0213 does not handle "unmappable" encoding operation correctly 6699038: sun/nio/cs/findencoderBugs.java fails Summary: SJIS_0213 charset updates Reviewed-by: okutsu ! src/share/classes/sun/nio/cs/CharsetMapping.java ! src/share/classes/sun/nio/cs/ext/SJIS_0213.java Changeset: b53b79a164c2 Author: sherman Date: 2008-06-06 14:57 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/b53b79a164c2 6706299: System property java.class.version should be 51 for jdk7 Summary: System property java.class.version should be 51 for jdk7 Reviewed-by: alanb ! src/share/native/java/lang/System.c ! test/java/lang/System/Versions.java Changeset: ffc554348922 Author: tbell Date: 2008-06-06 15:16 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/ffc554348922 Merge - src/share/classes/com/sun/jmx/mbeanserver/OpenConverter.java - src/share/classes/javax/management/ToQueryString.java Changeset: f570cbc8d4ff Author: alanb Date: 2008-06-05 14:44 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/f570cbc8d4ff 4939819: File.canWrite() returns false for the "My Documents" directory (win) Reviewed-by: iris ! src/windows/native/java/io/WinNTFileSystem_md.c ! test/java/io/File/SetReadOnly.java Changeset: eac5c4ead3ca Author: alanb Date: 2008-06-05 14:47 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/eac5c4ead3ca 6652379: File.setLastModified fails on large files (lnx only) Reviewed-by: iris ! src/solaris/native/java/io/UnixFileSystem_md.c ! test/java/io/File/SetLastModified.java Changeset: 28522137c831 Author: alanb Date: 2008-06-05 14:50 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/28522137c831 6596323: (fc) ClosedByInterruptException not thrown by the interrupt method (lnx) Reviewed-by: sherman ! src/share/classes/sun/nio/ch/NativeThreadSet.java ! src/solaris/classes/sun/nio/ch/NativeThread.java ! src/windows/classes/sun/nio/ch/NativeThread.java ! test/java/nio/channels/AsyncCloseAndInterrupt.java Changeset: 8619f18330b5 Author: alanb Date: 2008-06-05 14:57 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/8619f18330b5 6710579: (ch) test/java/nio/channels/AsyncCloseAndInterrupt fails (lnx) Reviewed-by: chegar ! test/java/nio/channels/AsyncCloseAndInterrupt.java Changeset: 21650cc54180 Author: alanb Date: 2008-06-06 11:40 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/21650cc54180 Merge Changeset: 513d733e571d Author: alanb Date: 2008-06-07 16:11 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/513d733e571d Merge Changeset: 7e5e83dfd285 Author: lmalvent Date: 2008-06-10 13:50 +0200 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/7e5e83dfd285 6711106: REGRESSION: Bad usage of SnapshotMBeanServerConnection in MBeans tab and JConsole plugins. Reviewed-by: jfdenise ! src/share/classes/sun/tools/jconsole/MBeansTab.java ! src/share/classes/sun/tools/jconsole/ProxyClient.java ! src/share/classes/sun/tools/jconsole/inspector/XMBean.java ! src/share/classes/sun/tools/jconsole/inspector/XMBeanAttributes.java Changeset: b6c42daa86d5 Author: tbell Date: 2008-06-12 13:18 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/b6c42daa86d5 Merge Changeset: e49bf258e60c Author: lmalvent Date: 2008-06-13 10:45 +0200 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/e49bf258e60c 6714244: Plotters in MBeans tab should use SnapshotMBeanServerConnection too Reviewed-by: jfdenise ! src/share/classes/sun/tools/jconsole/inspector/XPlottingViewer.java Changeset: c06f86e01a44 Author: tbell Date: 2008-06-13 12:16 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/c06f86e01a44 Merge Changeset: edf7cd1ec436 Author: tbell Date: 2008-06-16 22:16 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/edf7cd1ec436 Merge ! make/common/Release.gmk Changeset: ab1bc6850b6e Author: sherman Date: 2008-06-14 09:30 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/ab1bc6850b6e 6501089: test/java/nio/channels/SocketChannel/AsyncCloseChannel.java failing (timeout) on Linux Summary: test/java/nio/channels/SocketChannel/AsyncCloseChannel.java failing (timeout) on Linux Reviewed-by: alanb ! test/java/nio/channels/SocketChannel/AsyncCloseChannel.java Changeset: e8201036fc65 Author: xuelei Date: 2008-06-04 09:56 +0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/e8201036fc65 6690018: RSAClientKeyExchange NullPointerException Summary: checking certificate key length for RSA_EXPORT key exchange Reviewed-by: wetmore, mullan ! src/share/classes/sun/security/ssl/ClientHandshaker.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/RSAExport.java Changeset: da1eb844871c Author: wetmore Date: 2008-06-09 00:29 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/da1eb844871c Merge Changeset: e3de7e7bafcf Author: weijun Date: 2008-06-10 10:51 +0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/e3de7e7bafcf 6711509: PolicyTool is misspelling Runtime permission - 'setSecurityManager' entry in the policy file Reviewed-by: wetmore, mullan ! src/share/classes/sun/security/tools/PolicyTool.java Changeset: 2058f3daec43 Author: weijun Date: 2008-06-10 11:03 +0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/2058f3daec43 6711435: console.sh uses incompatible == Reviewed-by: xuelei ! test/sun/security/tools/keytool/console.sh Changeset: 93dce0e374de Author: chegar Date: 2008-06-12 17:25 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/93dce0e374de 6698625: InetAddress.getLocalHost() failed in returning chinese local host name Summary: Remove unnecessary and incorrect NewStringUTF Reviewed-by: michaelm ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/windows/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c Changeset: 4d1d84792fd0 Author: chegar Date: 2008-06-12 17:26 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/4d1d84792fd0 6630348: Invalid html tags (extra double quote) Summary: Remove extra quote Reviewed-by: michaelm ! src/share/classes/java/net/CookieHandler.java ! src/share/classes/java/net/ResponseCache.java ! src/share/classes/java/net/URI.java ! src/share/classes/java/net/URL.java Changeset: 56993d795f7a Author: chegar Date: 2008-06-12 17:28 +0100 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/56993d795f7a 6628569: api/java_net/MulticastSocket/descriptions.html#setTTL fails is ipv6 configured Summary: failover to IPv6 socket if IPv4 fails Reviewed-by: michaelm ! src/solaris/native/java/net/NetworkInterface.c Changeset: 7c9d632e7323 Author: jccollet Date: 2008-06-13 17:43 +0200 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/7c9d632e7323 6483406: new ServerSocket() sometimes takes more than 3 minutes on Suse Linux Summary: Switch to socketpair() call to create marker fd Reviewed-by: alanb ! src/solaris/native/java/net/PlainSocketImpl.c Changeset: 6471947b1ffc Author: wetmore Date: 2008-06-16 10:46 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/6471947b1ffc Merge Changeset: 584f643321b7 Author: tbell Date: 2008-06-16 22:21 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/584f643321b7 Merge Changeset: a4998b3b7807 Author: tbell Date: 2008-06-20 16:34 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/a4998b3b7807 Merge Changeset: 0e1d82bbcb2c Author: tbell Date: 2008-06-25 16:44 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/0e1d82bbcb2c Merge From xiomara.jayasena at sun.com Thu Jun 26 14:06:59 2008 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Thu, 26 Jun 2008 21:06:59 +0000 Subject: hg: jdk7/build/langtools: 8 new changesets Message-ID: <20080626210713.20CDE284A7@hg.openjdk.java.net> Changeset: 7708bd6d800d Author: jjg Date: 2008-06-03 13:26 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/7708bd6d800d 4075303: Use javap to enquire aboput a specific inner class 4348375: Javap is not internationalized 4459541: "javap -l" shows line numbers as signed short; they should be unsigned 4501660: change diagnostic of -help as 'print this help message and exit' 4776241: unused source file in javap... 4870651: javap should recognize generics, varargs, enum 4876942: javap invoked without args does not print help screen 4880663: javap could output whitespace between class name and opening brace 4975569: javap doesn't print new flag bits 6271787: javap dumps LocalVariableTypeTable attribute in hex, needs to print a table 6305779: javap: support annotations 6439940: Clean up javap implementation 6469569: wrong check of searchpath in JavapEnvironment 6474890: javap does not open .zip files in -classpath 6587786: Javap throws error : "ERROR:Could not find " for JRE classes 6622215: javap ignores certain relevant access flags 6622216: javap names some attributes incorrectly 6622232: javap gets whitespace confused 6622260: javap prints negative bytes incorrectly in hex Reviewed-by: ksrini ! make/build.properties ! make/build.xml ! make/netbeans/common/standard-ide-actions-no-javadoc.ent ! make/netbeans/common/standard-ide-actions.ent + src/share/classes/com/sun/tools/classfile/AccessFlags.java + src/share/classes/com/sun/tools/classfile/Annotation.java + src/share/classes/com/sun/tools/classfile/AnnotationDefault_attribute.java + src/share/classes/com/sun/tools/classfile/Attribute.java + src/share/classes/com/sun/tools/classfile/AttributeException.java + src/share/classes/com/sun/tools/classfile/Attributes.java + src/share/classes/com/sun/tools/classfile/CharacterRangeTable_attribute.java + src/share/classes/com/sun/tools/classfile/ClassFile.java + src/share/classes/com/sun/tools/classfile/ClassReader.java + src/share/classes/com/sun/tools/classfile/ClassTranslator.java + src/share/classes/com/sun/tools/classfile/ClassWriter.java + src/share/classes/com/sun/tools/classfile/Code_attribute.java + src/share/classes/com/sun/tools/classfile/CompilationID_attribute.java + src/share/classes/com/sun/tools/classfile/ConstantPool.java + src/share/classes/com/sun/tools/classfile/ConstantPoolException.java + src/share/classes/com/sun/tools/classfile/ConstantValue_attribute.java + src/share/classes/com/sun/tools/classfile/DefaultAttribute.java + src/share/classes/com/sun/tools/classfile/Deprecated_attribute.java + src/share/classes/com/sun/tools/classfile/Descriptor.java + src/share/classes/com/sun/tools/classfile/DescriptorException.java + src/share/classes/com/sun/tools/classfile/EnclosingMethod_attribute.java + src/share/classes/com/sun/tools/classfile/Exceptions_attribute.java + src/share/classes/com/sun/tools/classfile/Field.java + src/share/classes/com/sun/tools/classfile/InnerClasses_attribute.java + src/share/classes/com/sun/tools/classfile/LineNumberTable_attribute.java + src/share/classes/com/sun/tools/classfile/LocalVariableTable_attribute.java + src/share/classes/com/sun/tools/classfile/LocalVariableTypeTable_attribute.java + src/share/classes/com/sun/tools/classfile/Method.java + src/share/classes/com/sun/tools/classfile/ModuleExportTable_attribute.java + src/share/classes/com/sun/tools/classfile/ModuleMemberTable_attribute.java + src/share/classes/com/sun/tools/classfile/Module_attribute.java + src/share/classes/com/sun/tools/classfile/OpCodes.java + src/share/classes/com/sun/tools/classfile/RuntimeAnnotations_attribute.java + src/share/classes/com/sun/tools/classfile/RuntimeInvisibleAnnotations_attribute.java + src/share/classes/com/sun/tools/classfile/RuntimeInvisibleParameterAnnotations_attribute.java + src/share/classes/com/sun/tools/classfile/RuntimeParameterAnnotations_attribute.java + src/share/classes/com/sun/tools/classfile/RuntimeVisibleAnnotations_attribute.java + src/share/classes/com/sun/tools/classfile/RuntimeVisibleParameterAnnotations_attribute.java + src/share/classes/com/sun/tools/classfile/Signature.java + src/share/classes/com/sun/tools/classfile/Signature_attribute.java + src/share/classes/com/sun/tools/classfile/SourceDebugExtension_attribute.java + src/share/classes/com/sun/tools/classfile/SourceFile_attribute.java + src/share/classes/com/sun/tools/classfile/SourceID_attribute.java + src/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java + src/share/classes/com/sun/tools/classfile/StackMap_attribute.java + src/share/classes/com/sun/tools/classfile/Synthetic_attribute.java + src/share/classes/com/sun/tools/classfile/Type.java + src/share/classes/com/sun/tools/classfile/package.html + src/share/classes/com/sun/tools/javap/AnnotationWriter.java + src/share/classes/com/sun/tools/javap/AttributeWriter.java + src/share/classes/com/sun/tools/javap/BasicWriter.java + src/share/classes/com/sun/tools/javap/ClassWriter.java + src/share/classes/com/sun/tools/javap/CodeWriter.java + src/share/classes/com/sun/tools/javap/ConstantWriter.java + src/share/classes/com/sun/tools/javap/Context.java + src/share/classes/com/sun/tools/javap/DisassemblerTool.java + src/share/classes/com/sun/tools/javap/InternalError.java + src/share/classes/com/sun/tools/javap/JavapFileManager.java + src/share/classes/com/sun/tools/javap/JavapTask.java + src/share/classes/com/sun/tools/javap/Main.java + src/share/classes/com/sun/tools/javap/Options.java + src/share/classes/com/sun/tools/javap/overview.html + src/share/classes/com/sun/tools/javap/package.html + src/share/classes/com/sun/tools/javap/resources/javap.properties + src/share/classes/com/sun/tools/javap/resources/version.properties-template ! src/share/classes/sun/tools/javap/Main.java + test/tools/javap/4870651/T4870651.java + test/tools/javap/4870651/Test.java + test/tools/javap/ListTest.java + test/tools/javap/OptionTest.java + test/tools/javap/T4075403.java + test/tools/javap/T4459541.java + test/tools/javap/T4501660.java + test/tools/javap/T4876942.java + test/tools/javap/T4880663.java + test/tools/javap/T4975569.java + test/tools/javap/T6271787.java + test/tools/javap/T6305779.java + test/tools/javap/T6474890.java + test/tools/javap/T6587786.java + test/tools/javap/T6622216.java + test/tools/javap/T6622232.java + test/tools/javap/T6622260.java Changeset: 12c9e612e9e3 Author: jjg Date: 2008-06-05 13:46 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/12c9e612e9e3 6711276: langtools has incorrect -Werror switch Reviewed-by: ksrini ! make/build.properties Changeset: c2abfb92ba69 Author: tbell Date: 2008-06-06 15:17 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/c2abfb92ba69 Merge Changeset: 5ee49b24d378 Author: tbell Date: 2008-06-12 13:19 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/5ee49b24d378 Merge Changeset: b9bcea8bbe24 Author: jjg Date: 2008-06-16 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/b9bcea8bbe24 6714364: refactor javac File handling code into new javac.file package Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/main/JavaCompiler.java ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java + src/share/classes/com/sun/tools/javac/file/BaseFileObject.java + src/share/classes/com/sun/tools/javac/file/JavacFileManager.java + src/share/classes/com/sun/tools/javac/file/Old199.java + src/share/classes/com/sun/tools/javac/file/Paths.java + src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java + src/share/classes/com/sun/tools/javac/file/ZipFileIndexEntry.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java - src/share/classes/com/sun/tools/javac/util/BaseFileObject.java ! src/share/classes/com/sun/tools/javac/util/DiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java - src/share/classes/com/sun/tools/javac/util/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/util/Log.java - src/share/classes/com/sun/tools/javac/util/Old199.java - src/share/classes/com/sun/tools/javac/util/Paths.java - src/share/classes/com/sun/tools/javac/zip/ZipFileIndex.java - src/share/classes/com/sun/tools/javac/zip/ZipFileIndexEntry.java ! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javap/JavapFileManager.java ! test/tools/javac/6304921/TestLog.java ! test/tools/javac/6589361/T6589361.java ! test/tools/javac/T6358024.java ! test/tools/javac/T6358166.java ! test/tools/javac/T6358168.java ! test/tools/javac/T6705935.java ! test/tools/javac/api/T6358786.java ! test/tools/javac/api/TestResolveIdent.java ! test/tools/javac/util/filemanager/TestName.java Changeset: 700b17652ef6 Author: tbell Date: 2008-06-16 22:23 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/700b17652ef6 Merge - src/share/classes/com/sun/tools/javac/util/BaseFileObject.java - src/share/classes/com/sun/tools/javac/util/JavacFileManager.java - src/share/classes/com/sun/tools/javac/util/Old199.java - src/share/classes/com/sun/tools/javac/util/Paths.java - src/share/classes/com/sun/tools/javac/zip/ZipFileIndex.java - src/share/classes/com/sun/tools/javac/zip/ZipFileIndexEntry.java Changeset: 3cb4fb6e0720 Author: jjg Date: 2008-06-18 16:53 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/3cb4fb6e0720 6715767: javap on java.lang.ClassLoader crashes Reviewed-by: ksrini ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! src/share/classes/com/sun/tools/javap/JavapTask.java + test/tools/javap/T6715767.java Changeset: 0c66311205c2 Author: tbell Date: 2008-06-20 16:36 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/0c66311205c2 Merge From mark at klomp.org Fri Jun 27 03:38:05 2008 From: mark at klomp.org (Mark Wielaard) Date: Fri, 27 Jun 2008 12:38:05 +0200 Subject: Ability to override compiler from environment In-Reply-To: <4863AD95.9020907@gmail.com> References: <486020E4.1070109@sun.com> <1ccfd1c10806241057n718fc035k9a31017d7668bf54@mail.gmail.com> <48615B9C.7050401@gmail.com> <48616C64.1080701@Sun.COM> <1214381032.5507.13.camel@dijkstra.wildebeest.org> <4862BE4F.7010707@gmail.com> <1214461870.3062.47.camel@dijkstra.wildebeest.org> <4863AD95.9020907@gmail.com> Message-ID: <1214563085.3064.5.camel@dijkstra.wildebeest.org> Hi Thorbj?rn, On Thu, 2008-06-26 at 16:54 +0200, Thorbj?rn Ravn Andersen wrote: > Mark Wielaard skrev den 26-06-2008 08:31: > > > >> The script first looks for an awk and finds /usr/bin/nawk, and then > >> explicitly later looks for gawk. export GAWK=/usr/bin/nawk got me over > >> that test. > >> > > It explicitly tests for gawk since that is what the build says it > > requires. > > > Good reason! > > > dnl OpenJDK's README-builds.html lists gawk as a build dependency so we > > dnl check for it explicitly rather than using AC_PROG_AWK. > > FIND_TOOL([GAWK], [gawk]) > > > > > >> It requires both an ecj.jar and a libgcj.jar. Are both necessary? > >> > > Yes, one is a compiler and one is a core class library set. > > > But are they necessary if there is a Java6 JDK available? This IS > Solaris :) If you already have a bootstrapped icedtea or openjdk on the system then it isn't strictly necessary and you can also configure --with-icedtea or --with-openjdk and it will use that for the bootstrapping phase. See also ./configure --help for some more options to specify the "home dir" for these installations if you got them in a non-default place. > >> I'll look at building lesstif and see what happens then... > >> > > This really shouldn't be necessary anymore. At least not for > > icedtea/jdk7, there might still be some header constants used in > > icedtea6/openjdk6, but if so we should backport the fixes to remove them > > and remove this check. > > > I think I'll continue this discussion up on the icetea list. My fingers > cannot get used to the missing Reply-to header on this list. I CCed the icedtea list (distro-pkg-dev), but that (luckily) also doesn't do the harmful reply-to header munging (but that is probably another bikeshed flamewar waiting to happen...). Cheers, Mark From Kelly.Ohair at Sun.COM Fri Jun 27 18:11:31 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 27 Jun 2008 18:11:31 -0700 Subject: Trying to build openjdk7 under opensolaris In-Reply-To: <48615A51.3060404@gmail.com> References: <48615A51.3060404@gmail.com> Message-ID: <48658FC3.7040505@sun.com> The cc and CC also need to be in your PATH. -kto Thorbj?rn Ravn Andersen wrote: > Hi. > > I have tried to get an OpenSolaris build environment for OpenJDK7 up and > running (just for the fun of it), and have installed ss-dev and updated > everything as much as I could. The forrest should be up to date as of > the time of writing. > > My problem right now is that the "gmake" fails with > > gmake[5]: CC: Command not found > > (see output below) and I have set both COMPILER_PATH and > ALT_COMPILER_PATH (see below). > > Have I missed a configuration setting? > > Thanks in advance, > > /Thorbj?rn > > --- > > Output from "export" looks like: > > -- > ravn at bean:~/download/openjdk/jdk7/jdk7$ export > declare -x > ALT_BINARY_PLUGS_PATH="/export/home/ravn/download/openjdk/jdk7/plugins/openjdk-binary-plugs/" > > declare -x ALT_COMPILER_PATH="/opt/SunStudioExpress/bin/" > declare -x > ALT_CUPS_HEADERS_PATH="/export/home/ravn/download/cups-install/include/" > declare -x COMPILER_PATH="/opt/SunStudioExpress/bin/" > declare -x HOME="/export/home/ravn" > declare -x LANG="C" > declare -x LOGNAME="ravn" > declare -x MAIL="/var/mail/ravn" > declare -x MANPATH="/usr/gnu/share/man:/usr/share/man:/usr/X11/share/man" > declare -x > OLDPWD="/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/make" > declare -x PAGER="/usr/bin/less -ins" > declare -x > PATH="/export/home/ravn/download/findbugs-1.3.4/bin:/export/home/ravn/gnu/bin:/usr/gnu/bin:/usr/bin:/usr/X11/bin:/usr/sbin:/sbin" > > declare -x PWD="/export/home/ravn/download/openjdk/jdk7/jdk7" > declare -x SHELL="/bin/bash" > declare -x SHLVL="1" > declare -x SSH_CLIENT="192.168.0.13 2143 22" > declare -x SSH_CONNECTION="192.168.0.13 2143 192.168.0.10 22" > declare -x SSH_TTY="/dev/pts/3" > declare -x TERM="xterm" > declare -x TZ="Europe/Copenhagen" > declare -x USER="ravn" > -- > and output just before the failure > ----- > > cd ./hotspot/make && \ > gmake > JDK_TOPDIR=/export/home/ravn/download/openjdk/jdk7/jdk7/jdk > JDK_MAKE_SHARED_DIR=/export/home/ravn/download/openjdk/jdk7/jdk7/jdk/make/common/shared > EXTERNALSANITYCONTROL=true TARGET_CLASS_VERSION=5 MILESTONE=internal > BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 > FULL_VERSION=1.7.0-internal-ravn_2008_06_24_22_20-b00 > PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 > JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 > PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 > PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=32 COOKED_BUILD_NUMBER=0 > ALT_OUTPUTDIR=/export/home/ravn/download/openjdk/jdk7/jdk7/build/solaris-i586/hotspot/outputdir > ALT_EXPORT_PATH=/export/home/ravn/download/openjdk/jdk7/jdk7/build/solaris-i586/hotspot/import > ALT_SLASH_JAVA=/NOT-SET ALT_BOOTDIR=/usr/jdk/instances/jdk1.6.0 > ALT_LANGTOOLS_DIST=/export/home/ravn/download/openjdk/jdk7/jdk7/build/solaris-i586/langtools/dist > all_product > gmake[1]: Entering directory > `/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/make' > cd /export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/make; \ > gmake VM_TARGET=product generic_build2 > ALT_OUTPUTDIR=/export/home/ravn/download/openjdk/jdk7/jdk7/build/solaris-i586/hotspot/outputdir > > gmake[2]: Entering directory > `/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/make' > mkdir -p > /export/home/ravn/download/openjdk/jdk7/jdk7/build/solaris-i586/hotspot/outputdir > > cd > /export/home/ravn/download/openjdk/jdk7/jdk7/build/solaris-i586/hotspot/outputdir; > \ > gmake -f > /export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/make/solaris/Makefile > \ > JAVA_HOME=/usr/jdk/instances/jdk1.6.0 > GAMMADIR=/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot > MAKE_VERBOSE=y HOTSPOT_RELEASE_VERSION=13.0-b02 > JRE_RELEASE_VERSION=1.7.0-internal-ravn_2008_06_24_22_20-b00 > HOTSPOT_BUILD_VERSION= product > gmake[3]: Entering directory > `/export/home/ravn/download/openjdk/jdk7/jdk7/build/solaris-i586/hotspot/outputdir' > > cd solaris_i486_compiler2/product && gmake -w > WARNING: You are using CC version /bin/sh: line 1: CC: not found and > should be using version 5.8 > WARNING: You are using cc version cc: `-V' option must have argument and > should be using version 5.8 > expr: syntax error > expr: syntax error > expr: syntax error > expr: syntax error > expr: syntax error > gmake[4]: Entering directory > `/export/home/ravn/download/openjdk/jdk7/jdk7/build/solaris-i586/hotspot/outputdir/solaris_i486_compiler2/product' > > WARNING: You are using CC version /bin/sh: line 1: CC: not found and > should be using version 5.8 > WARNING: You are using cc version cc: `-V' option must have argument and > should be using version 5.8 > expr: syntax error > expr: syntax error > expr: syntax error > expr: syntax error > expr: syntax error > gmake[5]: Entering directory > `/export/home/ravn/download/openjdk/jdk7/jdk7/build/solaris-i586/hotspot/outputdir/solaris_i486_compiler2/product' > > Compiling > /export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/adlc/adlparse.cpp > > rm -f ../generated/adfiles/adlparse.o > CC -DSOLARIS -DSPARC_WORKS -DIA32 -DASSERT > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/asm > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/c1 > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/ci > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/classfile > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/code > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/compiler > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/gc_implementation > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/gc_implementation/shared > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/gc_implementation/parallelScavenge > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/gc_implementation/parNew > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/gc_interface > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/interpreter > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/libadt > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/memory > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/oops > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/opto > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/prims > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/runtime > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/services > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/utilities > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/cpu/x86/vm > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/os/solaris/vm > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/os_cpu/solaris_x86/vm > -I/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/adlc > -I../generated -DCOMPILER2 -DCOMPILER1 -DSOLARIS_7_OR_LATER > -D_REENTRANT -library=Cstd -g -c -o ../generated/adfiles/adlparse.o > /export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/share/vm/adlc/adlparse.cpp > > gmake[5]: CC: Command not found > gmake[5]: *** [../generated/adfiles/adlparse.o] Error 127 > From Kelly.Ohair at Sun.COM Fri Jun 27 18:44:33 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 27 Jun 2008 18:44:33 -0700 Subject: Recommended GCC version? In-Reply-To: <485FC38F.3030607@redhat.com> References: <194f62550803310937g2a1b2a7ci337b9093facb354c@mail.gmail.com> <1213902871.1712.7.camel@nirvana> <18522.51061.694662.235387@sun.com> <485AEC2E.6030806@sun.com> <17c6771e0806191635i782a0aa2u6c3b2c59e051ed61@mail.gmail.com> <485AF7E8.6080305@sun.com> <485AF9D6.2090102@sun.com> <485B8CBC.6040606@redhat.com> <485EE5CB.9060701@sun.com> <485FC38F.3030607@redhat.com> Message-ID: <48659781.8090104@sun.com> Source that compiles with many different compilers is generally a good thing, assuming the code hasn't been ifdef'd to death. But successful compilation is just part of the picture. Anyone delivering built openjdk bits, needs to have tested those bits and that they understand the quality issues that a built jdk has on the C/C++ compiler used. It would be impossible for any one group to guarantee that every change is buildable with every system & compiler combination, much less guarantee it runs perfectly in all cases. But I think that's understood. I see no reason to block changes that allow our openjdk source to be built with any reasonable compiler, and even well documented workarounds could even be justified. But we may want some reasonable limitations so that the code stays maintainable. -kto Andrew Haley wrote: > David Holmes - Sun Microsystems wrote: >> Andrew, >> >> Andrew Haley said the following on 06/20/08 20:55: >>> The changes we had to make to build OpenJDK with gcc 4.3 were to fix >>> nonstandard C++ code and to turn off -Werror because gcc 4.3 is much >>> more fulsome in its warnings. Rather than insist on using an older >>> compiler, we would probably be better off fixing the code that >>> generates the warnings. >> It isn't compilation that is the issue (we should certainly fix the >> OpenJDK code to compile cleanly on a standards-compliant compiler) but >> the actual runtime behaviour of the compiled code. WE don't "recommend" >> the old compiler because it allows old sloppy code to get through, but >> because we've already uncovered the bugs that affect us at runtime, >> through literally years of use and testing. > > Sure. I was counselling against the (oft-seen) practice of using an old > compiler because the code doesn't run on the new one. > > Andrew. From martinrb at google.com Fri Jun 27 19:10:29 2008 From: martinrb at google.com (Martin Buchholz) Date: Fri, 27 Jun 2008 19:10:29 -0700 Subject: Trying to build openjdk7 under opensolaris In-Reply-To: <48658FC3.7040505@sun.com> References: <48615A51.3060404@gmail.com> <48658FC3.7040505@sun.com> Message-ID: <1ccfd1c10806271910x432b1fcrc77116c7b91458fa@mail.gmail.com> On Fri, Jun 27, 2008 at 6:11 PM, Kelly O'Hair wrote: > The cc and CC also need to be in your PATH. ... which is a long-standing bug in the Makefiles (only for hotspot?) If you set ALT_COMPILER_PATH and PATH pointing at two different compilers, will subtle bad things happen? Martin From Kelly.Ohair at Sun.COM Fri Jun 27 19:18:27 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 27 Jun 2008 19:18:27 -0700 Subject: Trying to build openjdk7 under opensolaris In-Reply-To: <1ccfd1c10806271910x432b1fcrc77116c7b91458fa@mail.gmail.com> References: <48615A51.3060404@gmail.com> <48658FC3.7040505@sun.com> <1ccfd1c10806271910x432b1fcrc77116c7b91458fa@mail.gmail.com> Message-ID: <48659F73.9010902@sun.com> Martin Buchholz wrote: > On Fri, Jun 27, 2008 at 6:11 PM, Kelly O'Hair wrote: >> The cc and CC also need to be in your PATH. > > ... which is a long-standing bug in the Makefiles (only for hotspot?) Yeah, depends on your point of view, some consider the whole ALT_COMPILER_PATH a bug. ;^) > > If you set ALT_COMPILER_PATH and PATH pointing at two different compilers, > will subtle bad things happen? Probably. -kto > > Martin From thunderaxiom at gmail.com Sat Jun 28 00:33:19 2008 From: thunderaxiom at gmail.com (=?UTF-8?B?VGhvcmJqw7hybiBSYXZuIEFuZGVyc2Vu?=) Date: Sat, 28 Jun 2008 09:33:19 +0200 Subject: Ability to override compiler from environment In-Reply-To: <1214461870.3062.47.camel@dijkstra.wildebeest.org> References: <486020E4.1070109@sun.com> <1ccfd1c10806241057n718fc035k9a31017d7668bf54@mail.gmail.com> <48615B9C.7050401@gmail.com> <48616C64.1080701@Sun.COM> <1214381032.5507.13.camel@dijkstra.wildebeest.org> <4862BE4F.7010707@gmail.com> <1214461870.3062.47.camel@dijkstra.wildebeest.org> Message-ID: <4865E93F.3080204@gmail.com> Mark Wielaard skrev den 26-06-2008 08:31: > Hi Thorbj?rn, > > On Wed, 2008-06-25 at 23:53 +0200, Thorbj?rn Ravn Andersen wrote: > >> I gave it a try again, just to see what happens. >> >> The script first looks for an awk and finds /usr/bin/nawk, and then >> explicitly later looks for gawk. export GAWK=/usr/bin/nawk got me over >> that test. >> > > It explicitly tests for gawk since that is what the build says it > requires. > > dnl OpenJDK's README-builds.html lists gawk as a build dependency so we > dnl check for it explicitly rather than using AC_PROG_AWK. > FIND_TOOL([GAWK], [gawk]) > > >> It requires both an ecj.jar and a libgcj.jar. Are both necessary? >> > > Yes, one is a compiler and one is a core class library set. > > >> A "-bash-3.2$ ./configure >> --with-ecj-jar=/export/home/ravn/download/ecj.jar --with-ecj >> --with-libgcj-jar=/export/home/ravn/download/ecj.jar >> --with-xalan2-jar=/export/home/ravn/download/ecj.jar >> --with-xalan2-serializer-jar=/export/home/ravn/download/ecj.jar >> --with-xerces2-jar=/export/home/ravn/download/ecj.jar" got me to >> configure: error: "motif headers were not found - >> try installing lesstif-devel." >> >> which I now remember to be the place where I gave up the last time as >> apparently Motif is not available under OpenSolaris and "pkg search >> lesstif" did not show any packages. >> >> I'll look at building lesstif and see what happens then... >> > > This really shouldn't be necessary anymore. At least not for > icedtea/jdk7, there might still be some header constants used in > icedtea6/openjdk6, but if so we should backport the fixes to remove them > and remove this check. > I banged some more on icedtea. Installed lesstif and told it about /usr/openwin for X11 stuff. I did not have a software companion cd so I just compiled cups and used that for headers. It appears that alsa is required unconditionally instead of under Linux only. The pkg-config commadn is used to get details about XP (a package). I could not resolve this - is this a gnome package? Hacked the configure script to get pass this. Oh, it would be nice if there was an "openjdk-dev-prerequisites" package in the repository :) Right now I'm giving up on this... -- Thorbj?rn From martinrb at google.com Sat Jun 28 01:17:59 2008 From: martinrb at google.com (Martin Buchholz) Date: Sat, 28 Jun 2008 01:17:59 -0700 Subject: [NEW BUG] Running jtreg tests on NetBSD In-Reply-To: <4861A4BC.2090801@mcs.vuw.ac.nz> References: <4861A4BC.2090801@mcs.vuw.ac.nz> Message-ID: <1ccfd1c10806280117i4e4bab36h358963f98f7e39aa@mail.gmail.com> Of course, the non-portable constructs in the shell scripts come from a long term mindset of "if it's not solaris or linux, it must be windows." Better would be "if it's not windows, it must be unix" Very compactly (untested): case "`uname -s`" in Windows* | CYGWIN*) NULL=NUL PS=";" FS="\\" ;; *) NULL=/dev/null PS=":" FS="/" ;; esac This would be a pervasive change. Martin On Tue, Jun 24, 2008 at 6:51 PM, Alex Potanin wrote: > Hello, > > I am working on the javac extension and I tried to run the javac tests in > the OpenJDK's latest Mercurial repository. > > I see that a few of them contain the following in the shell scripts: > > # set platform-dependent variables > OS=`uname -s` > case "$OS" in > SunOS | Linux ) > NULL=/dev/null > PS=":" > FS="/" > ;; > Windows* ) > NULL=NUL > PS=";" > FS="\\" > ;; > * ) > echo "Unrecognized system!" > exit 1; > ;; > esac > > Since I use NetBSD, my 'uname -s' returns NetBSD. > > I had to add "| NetBSD" to the "SunOS | Linux" line to fix the test scripts > so that they don't return "Unrecognized system!". > > Some of the affected scripts are: > > tools/javac/4846262/Test.sh > tools/javac/6302184/T6302184.sh > tools/javac/ClassPathTest/ClassPathTest.sh > > But there are others that I can find if required (I suspect grepping will do > a good job). > > I was wondering if it can please be fixed to take NetBSD into account or > whether there is a better way of fixing this? > > Thanks, > Alex. > From thunderaxiom at gmail.com Sat Jun 28 02:19:25 2008 From: thunderaxiom at gmail.com (=?ISO-8859-1?Q?Thorbj=F8rn_Ravn_Andersen?=) Date: Sat, 28 Jun 2008 11:19:25 +0200 Subject: Trying to build openjdk7 under opensolaris In-Reply-To: <48658FC3.7040505@sun.com> References: <48615A51.3060404@gmail.com> <48658FC3.7040505@sun.com> Message-ID: <4866021D.6000905@gmail.com> Kelly O'Hair skrev den 28-06-2008 03:11: > The cc and CC also need to be in your PATH. Thanks, didn't think it would be so simple. I then got this compilation error (OpenSolaris fully updated, SS12, Pentium III). I verified that "hg update" was up to date. "/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/os/solaris/vm/os_solaris.cpp", line 3689: Error: ia_nice is not a member of iaparms. 1 Error(s) detected. gmake[5]: *** [os_solaris.o] Error 1 gmake[5]: Leaving directory `/export/home/ravn/download/openjdk/jdk7/jdk7/build/solaris-i586/hotspot/outputdir/solaris_i486_compiler2/product' Is this still a setup problem or is it a SS12/SS11 issue? -- Thorbj?rn From Kelly.Ohair at Sun.COM Sat Jun 28 10:01:06 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Sat, 28 Jun 2008 10:01:06 -0700 Subject: Trying to build openjdk7 under opensolaris In-Reply-To: <4866021D.6000905@gmail.com> References: <48615A51.3060404@gmail.com> <48658FC3.7040505@sun.com> <4866021D.6000905@gmail.com> Message-ID: <48666E52.9090500@sun.com> That one is new to me. You may need to isolate this problem, I haven't seen it before. Is this really SS12 or Sun Studio Express? What does CC -V say? (The hotspot alias is hotspot-dev at openjdk.java.net, you probably should send this problem to that alias). -kto Thorbj?rn Ravn Andersen wrote: > Kelly O'Hair skrev den 28-06-2008 03:11: >> The cc and CC also need to be in your PATH. > > Thanks, didn't think it would be so simple. > > I then got this compilation error (OpenSolaris fully updated, SS12, > Pentium III). I verified that "hg update" was up to date. > > "/export/home/ravn/download/openjdk/jdk7/jdk7/hotspot/src/os/solaris/vm/os_solaris.cpp", > line 3689: Error: ia_nice is not a member of iaparms. > 1 Error(s) detected. > gmake[5]: *** [os_solaris.o] Error 1 > gmake[5]: Leaving directory > `/export/home/ravn/download/openjdk/jdk7/jdk7/build/solaris-i586/hotspot/outputdir/solaris_i486_compiler2/product' > > > Is this still a setup problem or is it a SS12/SS11 issue? > From David.Holmes at Sun.COM Sun Jun 29 19:56:53 2008 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Mon, 30 Jun 2008 12:56:53 +1000 Subject: [Fwd: Re: Trying to build openjdk7 under opensolaris] Message-ID: <48684B75.5090908@sun.com> -------------- next part -------------- An embedded message was scrubbed... From: David Holmes - Sun Microsystems Subject: Re: Trying to build openjdk7 under opensolaris Date: Mon, 30 Jun 2008 12:54:58 +1000 Size: 6494 Url: http://mail.openjdk.java.net/pipermail/build-dev/attachments/20080630/740628c3/attachment.mht