Re: New build system problems

[Martin Buchholz]

On Mon, Jan 28, 2013 at 11:58 AM, Kelly O'Hair wrote:

> I would like configure to be executable too, but openjdk has a tradition
> of not allowing executable files in the source repos.
>
>
> To avoid the possibility of any executable binaries being put into the
> OpenJDK "source" repositories, we disallowed
> any files with execute permissions. I myself think this is a good policy
> and I don't think we should change that policy.
>
> I have seen too many files creep into source repositories with execute
> permissions that were actually mistakes.
>
>
How hard would it be to teach jcheck to only accept executable files that
start with "#!/" ?
Or jcheck could maintain a whitelist of permitted executable scripts.
Not having configure be executable violates developer expectations.

New build system problems

[Martin Buchholz]

I was trying out the shiny new build system.

Problem: configure is not executable - must run bash ./configure
It's traditional for configure scripts to be executable.

Problem: Your life is hell if you have a non-compiler "cl" command on your
PATH, even on Linux.

checking for cl... /usr/bin/cl
configure: Resolving CC (as /usr/bin/cl) failed, using /usr/bin/cl directly.

with subsequent failure to compile.

Even if you specify the compiler explicitly, it doesn't help:

CC=/usr/bin/gcc CXX=/usr/bin/g++ bash ./configure

Of course, one can work around this by creating a "tools dir", but excising
the unloved cl from the configure script is tempting and effective.

Re: Review Makefile Changes For JDK-8001334 - Remove use of JVM_* functions from java.io code

[Martin Buchholz]

On Wed, Jan 23, 2013 at 2:20 PM, Dan Xu  wrote:

> Hi,
>
> I have a fix for JDK-8001334 to remove JVM_* functions and replace with
> direct system calls. It introduces newmake filechangesin IO area especially
> on Windows platform. Please help review and approve them.
>
> Bug: 
> https://jbs.oracle.com/bugs/**browse/JDK-8001334


jbs seems to be down


>
> webrev: 
> http://cr.openjdk.java.net/~**dxu/8001334/webrev.00/<
> http://cr.openjdk.java.net/%**7Edxu/8001334/webrev.00/
> >
>


There seems to be little to no documentation on these various internal
functions.  E.g. How are read, IO_Read, and JVM_Read supposed to differ?
 Where's the interface doc?

Many years ago I filed
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4904617
that remains unaddressed :-(
Perhaps as part of this change or set of changes, that bug could be dealt
with?
Perhaps even by deleting JVM_Read?

Re: Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion

[Martin Buchholz]

+res = readFully (fdin, &magic, sizeof(magic));
+if (res != 4 || magic != magicNumber()) {

s/4/sizeof(magic)/

---

+extern int errno;

Delete.

---

+#define ALLOC(X,Y) { \
+void *mptr; \
+mptr = malloc (Y); \
+if (mptr == 0) { \
+error (fdout, ERR_MALLOC); \
+} \
+X = mptr; \
+}

It's traditional to define such a thing as a real function instead of a
macro, often with the name xmalloc.

Compare with

static void*
xmalloc(JNIEnv *env, size_t size)
{
void *p = malloc(size);
if (p == NULL)
JNU_ThrowOutOfMemoryError(env, NULL);
return p;
}

#define NEW(type, n) ((type *) xmalloc(env, (n) * sizeof(type)))

Re: Request for Review: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion

[Martin Buchholz]

Thanks for this.  I agree with the strategy.

I'm hoping build folks and macosx folks also take a look at this hairy
change.

+LINKFLAG =
+ifeq ($(ARCH_DATA_MODEL), 64)
+LINKFLAG = -m64
+endif

It looks wrong to be specifying toolchain-specific flags here.   Also, -m64
is logically a compiler flag, i.e. belongs in a variable with a name like
CFLAGS.

---
 ifeq ($(OPENJDK_TARGET_OS), solaris)
- ifeq ($(OPENJDK_TARGET_CPU_BITS), 32)
- BUILD_JEXEC := 1
- endif
+ifeq ($(OPENJDK_TARGET_CPU_BITS), 32)
+BUILD_JEXEC := 1
+endif
 endif

Why mess with jexec?

---

+String s = System.getProperty("java.lang.useFork");

"java.lang.Process.useFork" is a better name.
Also, useFork suggests it's a binary choice.  Wouldn't it be better to have
the system property
"java.lang.Process.spawn.mechanism" with values fork, vfork, posix_spawn,
clone

---

+enum LaunchMechanism {
+CLONE(1), FORK(2),
+VFORK(3), SPAWN(4);

I would rename SPAWN to POSIX_SPAWN.
The enum can be moved to a unix-flavor-independent file.

---

+helperpath = javahome + "/lib/" + osarch + "/jspawnhelper";

There ought to be a standard way to get the "libarchdir"


---

Of course, WhyCantJohnnyExec should have been WhyJohnnyCantExec
This is your chance to correct my mistake!


---

Sometimes I see __APPLE__ sometimes I see _ALLBSD_SOURCE.  Hopefully such
things will be removed later when the new build system is obligatory.

---


+/* Initialize xx_parentPathv[] */

It's not called xx_anything any more.


---

+shutItDown();

How about renaming to usageError() ?

---

+r = sscanf (argv[argc-1], "%d:%d", &fdin, &fdout);

How about checking for argc == 2 ?

Martin

On Wed, Dec 19, 2012 at 6:28 PM, Rob McKenna  wrote:

> Hi folks,
>
> Thanks for the feedback so far. I've uploaded a new webrev to:
>
> http://cr.openjdk.java.net/~**robm/5049299/webrev.02/<
> http://cr.openjdk.java.net/%**7Erobm/5049299/webrev.02/
> >
>
> I've made the following headline changes:
>
> - Initial effort to get this stuff into the new build-infra. Hoping
> build-infra can steer me in the right direction. (note to build infra
> reviewers: see links below)
>
> - Source thats shared between jspawnhelper.c and UNIXProcess_md.c now
> resides in childproc.h/c. This results in cleaner changes to the makefiles.
>
> - jspawnhelper moved to /lib/ on solaris (ipc necessitate
> the use of a separate jspawnhelper for each arch) and just /lib on macosx.
>
> The following links to earlier threads are well worth reading for
> additional context:
>
> http://mail.openjdk.java.net/**pipermail/core-libs-dev/2012-**
> November/012417.html
> http://mail.openjdk.java.net/**pipermail/core-libs-dev/2009-**
> June/001747.html
>
> -Rob
>
>
> On 30/11/12 03:48, Rob McKenna wrote:
>
>> Hi David,
>>
>> On 30/11/12 02:31, David Holmes wrote:
>>
>>> Hi Rob,
>>>
>>> This is only a superficial scan.
>>>
>>> The changes in java/java/makefile look pretty horrible. What are all
>>> those -R entries?
>>>
>> Library search paths. Currently jprochelper is linked to libjava. I'm
>> hoping to either cut their number (by altering jprochelpers home) or get
>> rid of them altogether (by avoiding linking at all) in the next draft, they
>> are indeed ungainly.
>>
>>>
>>> We will need equivalent changes for the new build system before this is
>>> pushed.
>>>
>>>  Indeed.
>>
>>> Is the spawn use BSD specific (as per UnixProcess.java.BSD) or Apple
>>> specific (as per __APPLE_ in UNIXProcess_md.c) ?
>>>
>>>  Eesh, thanks, it applies to both platforms.
>>
>>> Are the UnixProcess.java files similar enough that we could use a single
>>> template and generate the per-OS variants?
>>>
>>>  Before this change .bsd & .linux were identical (iirc) unfortunately,
>> no longer. Solaris has  differences. When you say "generate the per-OS
>> variants" how do you mean? I'd like to keep it as straightforward as
>> possible from a sustaining perspective. (personally I'd like to just extend
>> a base class and try to get away from the makefiles as much as possible -
>> we can discuss this in 8000975 which I'll revisit once I get through this)
>>
>>> In UNIXProcess_md.c:
>>>
>>> 209 #ifdef _CS_PATH
>>>  210 char *pathbuf;
>>>  211 size_t n;
>>>  212 n = confstr(_CS_PATH,NULL,(size_t) 0);
>>>  213 pathbuf = malloc(n);
>>>  214 if (pathbuf == NULL)
>>>  215 abort();
>>>  216 confstr(_CS_PATH, pathbuf, n);
>>>  217 return pathbuf;
>>>  218 #else
>>>
>>> what is _CS_PATH and why are we calling abort()? 
>>>
>>>  As per Martins comments I'm going to separate this into another change.
>> See:
>>
>> http://mail.openjdk.java.net/**pipermail/core-libs-dev/2009-**
>> May/001

Re: Boot JDK requirements for 8 ?

[Martin Buchholz]

On Tue, Dec 4, 2012 at 4:37 PM, David Holmes wrote:

> /java/embedded/users/dh198349/**profiles/builds/b66/se-linux-**
> i586-ea/jdk/classes/java/lang/**Integer.class: major version 52 is newer
> than 51, the highest major version supported by this compiler.
>

Consider (just for jdk development purposes) internally turning this into
an error, so that all such warnings are caught before release.  I think
such a thing is useful enough that you could have a system property or
javac flag to turn this into an error.  openjdk development would not be
the only team making use of that, e.g. to find missing -bootclasspath flags.

Re: static linking of libgcc on linux ?

[Martin Buchholz]

This appears to be another case where the hotspot and jdk repo makefiles differ.

hotspot does:

# statically link libgcc and/or libgcc_s, libgcc does not exist before gcc-3.x.
ifneq ("${CC_VER_MAJOR}", "2")
STATIC_LIBGCC += -static-libgcc
endif

making it look like the jdk repo makefile is in error.

I continue to be surprised that with all the strange fiddling with
linker flags (use of -static-libgcc is not encouraged), that jdk
binaries have such a high degree of binary compatibility.

Martin

On Sun, Sep 19, 2010 at 23:02, David Holmes  wrote:
> In the j2se/jdk repo make/common/Defs-linux.gmk contains this old code:
>
> #
> # -static-libgcc is a gcc-3 flag to statically link libgcc, gcc-2.9x always
> # statically link libgcc but will print a warning with the flag. We don't
> # want the warning, so check gcc version first.
> #
> CC_VER_MAJOR := $(shell $(CC) -dumpversion | $(SED) 's/egcs-//' | $(CUT)
> -d'.' -f1)
> ifeq ("$(CC_VER_MAJOR)", "3")
> OTHER_LDFLAGS  += -static-libgcc
> endif
>
> Now we build with gcc 4 we actually don't set -static-libgcc. Can someone
> comment on the correctness of this - should we instead be checking for
> "ifneq ("$(CC_VER_MAJOR)", "2") ?
>
> Thanks,
> David Holmes
>

Re: Pending Character-related work - Character-warnings

[Martin Buchholz]

I just tried to reproduce the failure ... and could not,
so it may have been either my fuzzy memory,
or perhaps some issue with the import JDK
not being sufficiently up to date.

Sorry for wasting bandwidth...

Standard response to

Q: Shouldn't we start using the diamond operator?
A: Yes.  Write a very clever script and convert the jdk sources.
Make sure the JDK can still be built from scratch using only jdk6.

Martin

On Thu, Jul 1, 2010 at 17:15, Jonathan Gibbons
 wrote:
> Ulf,
>
> Have you tried it, and if so, what error do you get?   If you get an error,
> this may be a fault in the Makefiles for this part of the system, using the
> wrong macro to get at javac.   That's what I was trying to get at in my
> previous message.  However, I'm not an expert on this part of the code, I'm
> just trying to explain generalities here. There may be reasons I don't know
> about why this needs to be compilable by the BOOT JDK.
>
> Separately, I know at some point, Joe was planning to have a concerted
> effort to diamond-ize the JDK code base in areas where that is technically
> reasonable (i.e. not javac etc.)
>
> -- Jon
>
>
> On 07/01/2010 04:51 PM, Ulf Zibis wrote:
>>
>> Jonathan,
>>
>> much thanks.
>>
>> My question is not about the generated parts, it's about following lines
>>
>>  652         private static Map  map
>>  653             = new HashMap(256);
>>
>> in
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/Character-warnings/src/share/classes/java/lang/Character.java.sdiff.html
>> where JDK-7 compiler returns a warning: "redundant type arguments in new
>> expression (use diamond operator instead).".
>>
>> If coded as:
>>
>>  652         private static Map  map  = new
>> HashMap<>(256);
>>
>> Martin said, this doesn't work, because j.l.Character must be compilable
>> by the bootstrap JDK which is JDK-6.
>> This I don't understand in reference to what you said: "... and all the
>> code in the jdk/ repo can be built with the latest language features."
>>
>> -Ulf
>>
>>
>>
>> Am 02.07.2010 01:22, schrieb Jonathan Gibbons:
>>>
>>> Ulf,
>>>
>>> As complicated as the build is now, it used to be way more complicated.
>>>  I suspect you're just seeing a bit of history leaking into that part of the
>>> build.   Because some of the code in the java.lang.Character area is
>>> automatically generated, it has its own special Makefile rules, so I suspect
>>> it has slipped through the cracks to make sure the files that get generated
>>> are compiled with the latest compiler to -target 7 class files.
>>>
>>> -- Jon
>>>
>>>
>>> On 07/01/2010 04:11 PM, Ulf Zibis wrote:
>>>>
>>>> Jonathan, Kelly,
>>>>
>>>> thanks for your short but excellent descriptive explanation.
>>>> It mainly reflects how I understood the build process in general.
>>>> Can you briefly answer my questions below?
>>>>
>>>> Am 01.07.2010 18:13, schrieb Kelly O'Hair:
>>>>>
>>>>> On Jul 1, 2010, at 7:56 AM, Jonathan Gibbons wrote:
>>>>>
>>>>>> On 07/01/2010 01:32 AM, Ulf Zibis wrote:
>>>>>>>
>>>>>>> Am 01.07.2010 09:38, schrieb Martin Buchholz:
>>>>>>>>
>>>>>>>> On Wed, Jun 30, 2010 at 23:49, Ulf Zibis  wrote:
>>>>>>>>>
>>>>>>>>> Am 30.06.2010 19:50, schrieb Martin Buchholz:
>>>>>>>>>>
>>>>>>>>>> On Wed, Jun 30, 2010 at 01:22, Ulf Zibis
>>>>>>>>>>  wrote:
>>>>>>>>>>
>>>>>>>>>>> Am 29.06.2010 02:29, schrieb Martin Buchholz:
>>>>>>>>>>>>
>>>>>>>>>>>> I tried to do that, but Character.java is one of those classes
>>>>>>>>>>>> that needs to be compilable by the bootstrap JDK,
>>>>>>>>>>>> so this change ist leider nicht moeglich.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> I think, there should be a note about this in the sources of
>>>>>>>>>>> those
>>>>>>>>>>> classes.
>>>>>>>>>>>
>>>>

Re: Pending Character-related work - Character-warnings

[Martin Buchholz]

On Thu, Jul 1, 2010 at 00:23, Ulf Zibis  wrote:
> Oops, it's never superfluous to review again:
>
> Line 245: too much spaces
> Compare line 363 vs 376 etc.: inconsistent indentation after @since
> Line 598: can be deleted
> Line 600: 2 spaces after @exception
> Line 600: 2 spaces after NullPointerException
> Line 600: better use @throws
> Line 652: shoudn't you add a @suppressWarnings before // But I still think,
> a little comment would be better.
> Line 4706: 2 spaces after ch should be enough (you can donate it to line
> 4736 after codePoint ;-) )
> Line 5297, 5330: one more space after @return
> Line 5812: another type of indentation iregularity
> ... (there are some more irregularities in this class on indentation and
> spacing)
> ... I think, the time has come to replace things like:
> '\u005A'

Too late; I've committed my changes; we can always create a new batch
of webrevs.

As you know, I think @exception is worth changing to @throws, but only
via automated script.

Martin

> -Ulf
>
>
>
> Am 30.06.2010 19:50, schrieb Martin Buchholz:
>>
>> On Wed, Jun 30, 2010 at 01:22, Ulf Zibis  wrote:
>>
>>>
>>> Am 29.06.2010 02:29, schrieb Martin Buchholz:
>>>
>>
>>
>>>>
>>>> I tried to do that, but Character.java is one of those classes
>>>> that needs to be compilable by the bootstrap JDK,
>>>> so this change ist leider nicht moeglich.
>>>>
>>>>
>>>>
>>>
>>> I think, there should be a note about this in the sources of those
>>> classes.
>>>
>>
>> Such a note is likely to become obsolete soon.
>>
>>
>>>
>>> Maybe it's possible to have 2 versions, one for the bootstrap + another
>>> for
>>> the final compilation.
>>>
>>
>> It's not a crime to implement language FOO(N) in language FOO(N-1).
>>
>> Martin
>>
>>
>>
>
>

Re: Pending Character-related work - Character-warnings

[Martin Buchholz]

On Wed, Jun 30, 2010 at 23:49, Ulf Zibis  wrote:
> Am 30.06.2010 19:50, schrieb Martin Buchholz:
>>
>> On Wed, Jun 30, 2010 at 01:22, Ulf Zibis  wrote:
>>
>>>
>>> Am 29.06.2010 02:29, schrieb Martin Buchholz:
>>>
>>
>>
>>>>
>>>> I tried to do that, but Character.java is one of those classes
>>>> that needs to be compilable by the bootstrap JDK,
>>>> so this change ist leider nicht moeglich.
>>>>
>>>>
>>>>
>>>
>>> I think, there should be a note about this in the sources of those
>>> classes.
>>>
>>
>> Such a note is likely to become obsolete soon.
>>
>
> How do you mean that? Will the build procedure change soon. Then it would be
> anyway appropriate to update to new "style".

In jdk8, the bootstrap jdk will be at least jdk7.

>>
>>>
>>> Maybe it's possible to have 2 versions, one for the bootstrap + another
>>> for
>>> the final compilation.
>>>
>>
>> It's not a crime to implement language FOO(N) in language FOO(N-1).
>>
>
>
> ... but a bad example for programmers, especially beginners, in case they
> look through the sources to catch some ideas.

True, but as you can see, modernizing a code base is a process that
tends not to get done unless someone like you makes it a personal
project.

Re: Pending Character-related work - Character-warnings

[Martin Buchholz]

On Wed, Jun 30, 2010 at 01:22, Ulf Zibis  wrote:
> Am 29.06.2010 02:29, schrieb Martin Buchholz:

>> I tried to do that, but Character.java is one of those classes
>> that needs to be compilable by the bootstrap JDK,
>> so this change ist leider nicht moeglich.
>>
>>
>
> I think, there should be a note about this in the sources of those classes.

Such a note is likely to become obsolete soon.

> Maybe it's possible to have 2 versions, one for the bootstrap + another for
> the final compilation.

It's not a crime to implement language FOO(N) in language FOO(N-1).

Martin

Re: Makefile help: setting HOTSPOT_EXTRA_SYSDEFS

[Martin Buchholz]

I'm pasting in the relevant section from the GNU make manual,
hoping it helps.

5.7.2 Communicating Variables to a Sub-`make'
-

Variable values of the top-level `make' can be passed to the sub-`make'
through the environment by explicit request.  These variables are
defined in the sub-`make' as defaults, but do not override what is
specified in the makefile used by the sub-`make' makefile unless you
use the `-e' switch (*note Summary of Options: Options Summary.).

   To pass down, or "export", a variable, `make' adds the variable and
its value to the environment for running each command.  The sub-`make',
in turn, uses the environment to initialize its table of variable
values.  *Note Variables from the Environment: Environment.

   Except by explicit request, `make' exports a variable only if it is
either defined in the environment initially or set on the command line,
and if its name consists only of letters, numbers, and underscores.
Some shells cannot cope with environment variable names consisting of
characters other than letters, numbers, and underscores.

   The value of the `make' variable `SHELL' is not exported.  Instead,
the value of the `SHELL' variable from the invoking environment is
passed to the sub-`make'.  You can force `make' to export its value for
`SHELL' by using the `export' directive, described below.  *Note
Choosing the Shell::.

   The special variable `MAKEFLAGS' is always exported (unless you
unexport it).  `MAKEFILES' is exported if you set it to anything.

   `make' automatically passes down variable values that were defined
on the command line, by putting them in the `MAKEFLAGS' variable.
*Note Options/Recursion::.

   Variables are _not_ normally passed down if they were created by
default by `make' (*note Variables Used by Implicit Rules: Implicit
Variables.).  The sub-`make' will define these for itself.

   If you want to export specific variables to a sub-`make', use the
`export' directive, like this:

 export VARIABLE ...

If you want to _prevent_ a variable from being exported, use the
`unexport' directive, like this:

 unexport VARIABLE ...

In both of these forms, the arguments to `export' and `unexport' are
expanded, and so could be variables or functions which expand to a
(list of) variable names to be (un)exported.

   As a convenience, you can define a variable and export it at the same
time by doing:

 export VARIABLE = value

has the same result as:

 VARIABLE = value
 export VARIABLE

and

 export VARIABLE := value

has the same result as:

 VARIABLE := value
 export VARIABLE

   Likewise,

 export VARIABLE += value

is just like:

 VARIABLE += value
 export VARIABLE

*Note Appending More Text to Variables: Appending.

   You may notice that the `export' and `unexport' directives work in
`make' in the same way they work in the shell, `sh'.

   If you want all variables to be exported by default, you can use
`export' by itself:

 export

This tells `make' that variables which are not explicitly mentioned in
an `export' or `unexport' directive should be exported.  Any variable
given in an `unexport' directive will still _not_ be exported.  If you
use `export' by itself to export variables by default, variables whose
names contain characters other than alphanumerics and underscores will
not be exported unless specifically mentioned in an `export' directive.

   The behavior elicited by an `export' directive by itself was the
default in older versions of GNU `make'.  If your makefiles depend on
this behavior and you want to be compatible with old versions of
`make', you can write a rule for the special target
`.EXPORT_ALL_VARIABLES' instead of using the `export' directive.  This
will be ignored by old `make's, while the `export' directive will cause
a syntax error.

   Likewise, you can use `unexport' by itself to tell `make' _not_ to
export variables by default.  Since this is the default behavior, you
would only need to do this if `export' had been used by itself earlier
(in an included makefile, perhaps).  You *cannot* use `export' and
`unexport' by themselves to have variables exported for some commands
and not for others.  The last `export' or `unexport' directive that
appears by itself determines the behavior for the entire run of `make'.

   As a special feature, the variable `MAKELEVEL' is changed when it is
passed down from level to level.  This variable's value is a string
which is the depth of the level as a decimal number.  The value is `0'
for the top-level `make'; `1' for a sub-`make', `2' for a
sub-sub-`make', and so on.  The incrementation happens when `make' sets
up the environment for a command.

   The main use of `MAKELEVEL' is to test it in a conditional directive
(*note Conditional Parts of Makefiles: Conditionals.); this way you can
write a makefile that behaves one way if run recursively and another
way if run directly by you.

   You can use the var

Stop linking with -lnsl on Linux

[Martin Buchholz]

Hi Kelly, I'd like you to do a code review.

The JDK links with libnsl on Linux, but this is an unused dependency.

Here's a patch to stop linking with it - very similar to the handling
of libsocket:

http://cr.openjdk.java.net/~martin/webrevs/openjdk7/libnsl

I don't know whether libnsl is also unused on Solaris - I'll leave
that up to someone else.  Solaris and Linux libnsls are very
different.

Thanks,

Martin

Re: Stop linking with -lnsl on Linux

[Martin Buchholz]

On Thu, Jun 10, 2010 at 15:46, Jonathan Gibbons
 wrote:
> Martin,
>
> Do you need a real bug-ID -- it looks like you were not the lucky recipient
> of 666?

Thanks,  but Kelly just filed

6960394: Stop linking with -lnsl on Linux

Re: Building with MinGW?

[Martin Buchholz]

Building OpenJDK is known to be difficult,
and that is especially so on Windows,
but people do it regularly.
E.g.
http://blogs.tedneward.com/2007/12/15/Let+The+JDK+Hacking+Begin.aspx

Don't use any paths containing spaces.

Martin

On Fri, Apr 23, 2010 at 08:42, Raffaello Giulietti
 wrote:
> Let me put things in perspective.
>
> I'm not interested in building OpenJDK7 per se. I would use the binary
> snapshots, were it not for the fact that, for my purposes, I need the
> latest extensions provided by the MLVM project. Unfortunately, there is
> no binary snapshot for that, so I need to download the Mercurial
> repository, apply the MLVM specific patches and build it.
>
> Now, I invested two frustrating days in trying to build the "pure"
> OpenJDK7, i.e., without the MLVM extensions. I did it according to the
> details described in the quite complete "OpenJDK Build README" page. So
> I used the expected licensed VisualStudio compiler. The problems I
> encountered can be generally grouped in the "path not found" category,
> be it because of spaces in the path, because of \ versus /, etc. As a
> consequence, I didn't even try a build with the MLVM extensions.
>
> To be clear, I'm not complaining about the README or the like. I'm only
> reporting my experience with such a complex system and its build.
>
> So, the real reason behind my request for a MinGW based build is that it
> would be a second chance to try a build of the MLVM. But since nobody
> seems to have first-hand experience with OpenJDK7/MinGW, I'll gather my
> energies and my patience and retry with VisualStudio.
>
> RG
>
>
>
> On 2010-04-21 18:40, Kelly O'Hair wrote:
>>
>> On Apr 21, 2010, at 5:58 AM, Raffaello Giulietti wrote:
>>
>>> Hello,
>>>
>>> I'm wondering if anybody has already tried to build OpenJDK7 on Windows
>>> using the MinGW suite.
>>
>> If they have, I never heard from them.
>>
>>>
>>> * Is there anything known to be a hard to circumvent show stopper?
>>
>> To me the basic problem is that with "Windows" it is hard to separate
>> the code
>> dependencies on the OS, some Windows SDK, something specific to Visual
>> Studio,
>> etc. I'm not saying it would be impossible, but it is not a simple
>> change and
>> parts of the jdk might be very difficult to disconnect from Visual Studio
>> dependencies. The code has assumed Visual Studio for a long long time.
>>
>> If someone did it, and we were able to build either way, and the changes
>> weren't
>> too outrageous, I'm sure we consider accepting that contribution.
>> But I just don't think it will be that simple.
>>
>>> * Is it known why Visual C++ is still the reference build system on
>>> Windows?
>>
>> It was probably chosen as the defacto standard on Windows a long time
>> ago and
>> there was never any value in changing that.
>> The performance was probably a key issue, and whether or not you could
>> convert
>> to a different compiler set, before the official builds would ever
>> change you
>> would need some very detailed performance measurements to verify no loss of
>> performance. That's not an easy job, or simple either.
>>
>> ---
>>
>> Any change to the compilers used to create the binary JDKs we distribute
>> is always
>> a change made very carefully. It might provide significant benefits, but
>> the
>> hidden dangers are often difficult to find and diagnose.
>> I know this binary distribution model is of less interest to some who
>> just want
>> to build the openjdk source for a particular platform, but it certainly
>> is a
>> critical issue for us. Compiler changes are carefully tracked.
>>
>> -kto
>>
>>>
>>> Thanks
>>> Raffaello
>>
>
>

Re: JDK build questions

[Martin Buchholz]

On Fri, Apr 16, 2010 at 12:09, David Dabbs  wrote:
>> > * If so, is it possible to build using Intel's compiler?
>>
>> You'll probably need to port, and to modify
>> some underlying assumptions.
>> I don't recommend it.
>>
>
> I'm not sure I understand your reference to "port." The Intel
> compiler is available on both Windows as well as Linux.

What I mean is that you will need to port the JDK Makefiles
and source code.  You will need to find the (many) places where
the code assumes that gcc is used on linux or that microsoft's
compiler is used on windows.

Also, don't expect to be able to run any 3rd-party native code in your
new JDK via JNI,
unless it has also been compiled using intel cc.

Martin

Re: JDK build questions

[Martin Buchholz]

On Fri, Apr 16, 2010 at 10:24, David Dabbs  wrote:
>
> Hello. My apologies if these questions are OT for this list.
>
> On the premise that building my own binaries could yield performance
> improvements versus the Sun(Oracle)-provided binaries I've decided to
> tinker with building from source.
>
> * My first question is "Is this a reasonable premise?"

Unlikely, since the code that really counts is generated
by the JIT at runtime.  The most performance-sensitive
native code is probably the GC.

> * If so, is it possible to build using Intel's compiler?

You'll probably need to port, and to modify
some underlying assumptions.
I don't recommend it.

> * Now that Visual Studio 2010 has been released will there be an
>  option to use it to build the JDK under Windows?
>
> * If I build on a recent Xeon with "gcc -march=native ..." would one expect
>  to see performance differences versus the Sun(Oracle)-provided binary to
>  justify the effort?
>
> * I have recently been tinkering with Intel's memory allocator and TCMalloc,
> etc.
>  Would compiling with these be expected to a) even work and b) yield perf
>  improvements worth the effort.

The JDK doesn't malloc much.

I would welcome having more choice of compilers,
but I think it's a bigger project than it looks.

The IcedTea project has a "configure" infrastructure,
that would be more accommodating to your goals.

Martin

Re: Question on how to properly find all the sources going into a JDK

[Martin Buchholz]

On Thu, Apr 8, 2010 at 12:40, Joe Darcy  wrote:
> Hello.
>
> From time to time, I want to run an annotation processor over all the Java
> sources going into the JDK.  Annotation processors as compiler plug-ins can
> be used to check various structural properties of the code.  For example, an
> annotation processor could be used to find potential methods to be converted
> to use var-args.
>
> The goal is to ideally have a single command like
>
>   javac -proc:only -processor MyProcessor $OTHER_OPTIONS  `Long list of
> files`
>
> and I wanted to verify the proper way to get the long list of files.  From
> the root of a JDK 7 forest with a build directory, does
>
> find corba/src \
> jaxp/drop/jaxp_src \
> jaxws/drop/jaxws_src \
> langools/src \
> jdk/src/share jdk/src/$OS \
> $BUILDDIR/$PLATFORM/gensrc \
> -name "*.java"
>
> cover all the files of interest?

That looks pretty good;
if you wanted to verify its accuracy,
you could build a list of class files
by running jar tf on the jar files in the
images, and correlating with the results
from running find on the source files
as you did above.

Martin

Re: Unhappy about test/ProblemList.txt

[Martin Buchholz]

On Tue, Mar 30, 2010 at 09:11, Kelly O'Hair  wrote:
>
> On Mar 29, 2010, at 7:04 PM, Martin Buchholz wrote:
>
>> On Mon, Mar 29, 2010 at 17:14, Kelly O'Hair  wrote:
>>>
>>> Jonathan is working on some changes to jtreg that may allow many of the
>>> tests on the ProblemList to be removed, I am hopeful anyway.
>>> Once we have that new jtreg available, trimming this list down is next.
>>>
>>> I admit to being a little quick to add some tests to the list, it was a
>>> somewhat
>>> frustrating experience to isolate these things when looking at all 12
>>> platforms/vms.
>>>
>>> I think in this case it was timing out on Solaris sparc and appeared to
>>> be a
>>> stress test.
>>> This test is already marked othervm, so I can only assume that it is very
>>> close
>>> to the default timeout,
>>
>> If increasing the timeout will make failures go away, then that is
>> perfectly fine.
>> You can reasonably increase the timeout up to 1 hour.
>
> I'm not sure having this one test take an hour is fair to the other 1,000's
> of tests.
> It it can't run in under 5min, I'd question the test, maybe it's sleeping or
> blocking
> too much if that is the case.
> Part of the goal in all this was to provide wide solid test coverage in a
> reasonable amount
> of time, but if we allow many tests to run for an hour, that's a bit of a
> problem.
>
> Regardless, I don't think this test takes an hour, I'll put a 10min timeout
> on it
> and see how that goes. But I suspect it will run in well under 5min.

It takes (only) 8 sec to run on my linux box,
and tests the entire Process subsystem,
which requires actually creating many subprocesses,
has regression tests for many bugids,
and reports
Passed = 2668

Not bad for one test file.

Martin

Re: Unhappy about test/ProblemList.txt

[Martin Buchholz]

On Mon, Mar 29, 2010 at 17:14, Kelly O'Hair  wrote:
>
> Jonathan is working on some changes to jtreg that may allow many of the
> tests on the ProblemList to be removed, I am hopeful anyway.
> Once we have that new jtreg available, trimming this list down is next.
>
> I admit to being a little quick to add some tests to the list, it was a
> somewhat
> frustrating experience to isolate these things when looking at all 12
> platforms/vms.
>
> I think in this case it was timing out on Solaris sparc and appeared to be a
> stress test.
> This test is already marked othervm, so I can only assume that it is very
> close
> to the default timeout,

If increasing the timeout will make failures go away, then that is
perfectly fine.
You can reasonably increase the timeout up to 1 hour.

Martin

Re: Unhappy about test/ProblemList.txt

[Martin Buchholz]

On Mon, Mar 29, 2010 at 17:14, Kelly O'Hair  wrote:
>
> Jonathan is working on some changes to jtreg that may allow many of the
> tests on the ProblemList to be removed, I am hopeful anyway.
> Once we have that new jtreg available, trimming this list down is next.
>
> I admit to being a little quick to add some tests to the list, it was a
> somewhat
> frustrating experience to isolate these things when looking at all 12
> platforms/vms.
>
> I think in this case it was timing out on Solaris sparc and appeared to be a
> stress test.
> This test is already marked othervm, so I can only assume that it is very
> close
> to the default timeout, looks like a fairly complex testcase, but I see
> no reason to not add it back in, maybe I can bump up the timeout on this
> test.

ProcessBuilder/Basic.java has a lot of infrastructure for testing the
process infrastructure, so it has grown organically to house many
different individual tests.  Consider it a test suite!

Martin

Unhappy about test/ProblemList.txt

[Martin Buchholz]

I was surprised to see some of my own favorite tests
in  test/ProblemList.txt and am not happy about that.
I fear that we have regression tests finding actual
regressions and that instead of this causing the
guilty changeset to be reverted, (or better yet
never checked in), innocent tests are just
getting added to the blacklist.

At least please un-blacklist my pet ProcessBuilder/Basic.java.

Martin

Re: No rule to make foo.cpp needed by foo.o ???

[Martin Buchholz]

On Tue, Dec 22, 2009 at 21:55, David Holmes - Sun Microsystems
> No it's not that simple. If I update 5 files the first build reports the 1st
> is missing, the second reports the 2nd is missing and so forth and a lot
> longer than 30 seconds has passed in between. :(

Then it's probably a different problem.
Debugging dependency handling in makefiles
is an arcane skill.

Martin

Re: No rule to make foo.cpp needed by foo.o ???

[Martin Buchholz]

On Mon, Dec 21, 2009 at 18:42, David Holmes - Sun Microsystems
 wrote:
> Igor Nekrestyanov said the following on 12/22/09 11:45:
>>
>> Check the output of "gnumake -dd" looking for everything related to files
>> in question. It will tell you why rules are not fired.
>
> Surprisingly the answer was because "Foo.cpp does not exist" which of course
> is nonsense.
>
> I'm guessing this must be some kind of NFS caching issue. I rsync the
> updated files to the build location and then run the build on another
> machine.

If the problem goes away if you add a
sleep 30
after the NFS copy, you are probably right.
NFS has always worked thus.

It is just like the consistency considerations with the
java memory model, except that the cache lifetimes
are typically much longer.

You can fix it by rsyncing to the machine where the
build will happen, so that there will be no caching
of stale bits.

Martin

Re: the trustAnchors parameter must be non-empty for jdk7-jaxp-m5.zip

[Martin Buchholz]

On Tue, Nov 24, 2009 at 15:39, Kelly O'Hair  wrote:
> What version of ant are you using?

I think I'm using 1.7.0

Re: the trustAnchors parameter must be non-empty for jdk7-jaxp-m5.zip

[Martin Buchholz]

I'm seeing this problem too, building openjdk7-b76.
Seems like a P2 bug to me.
I *can* download using wget.
Is there an easy way to download all the bundles I need?
http://kenai.com/projects/jdk7-drops/downloads has bundles,
but they appear to be incomplete.

Martin

On Sun, Nov 22, 2009 at 21:45, Andrew John Hughes
 wrote:
> 2009/11/23 Michael Franz :
>> Hi,
>>
>> I did a new fclone of the bsd repo today.  When running the build I get the
>> following error:
>> javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error:
>> java.security.InvalidAlgorithmParameterException: the trustAnchors parameter
>> must be non-empty
>>
>> I tried to download the zip file using wget and get the following error:
>> --2009-11-22 23:53:14--
>> https://jaxp.dev.java.net/files/documents/913/144160/jdk7-jaxp-m5.zip
>> Resolving jaxp.dev.java.net... 204.16.104.198
>> Connecting to jaxp.dev.java.net|204.16.104.198|:443... connected.
>> ERROR: cannot verify jaxp.dev.java.net's certificate, issued by
>> `/C=US/O=Equifax/OU=Equifax Secure Certificate Authority':
>>   Unable to locally verify the issuer's authority.
>> To connect to jaxp.dev.java.net insecurely, use `--no-check-certificate'.
>> Unable to establish SSL connection.
>>
>> Is anyone else having problems downloading?
>>
>> Michael
>>
>>
>>
>>
>
> I also see this on standard JDK7 trees, as reported on build-dev back
> in October:
>
> http://mail.openjdk.java.net/pipermail/build-dev/2009-October/002498.html
>
> to no response.
>
> CCing this to build-dev as well as this is a general issue, not BSD-specific.
>
> As a workaround, you can use ALT_DROPS_DIR to point the build to a
> directory containing the downloaded tarballs.  Downloading using wget
> works fine.
> IcedTea avoids this issue in this manner by consolidating these
> downloads with the downloads of the other OpenJDK tarballs before the
> OpenJDK build begins.
> --
> Andrew :-)
>
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> 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
>
>

Re: Need reviewers - jdk testing changes 6888927

[Martin Buchholz]

On Wed, Nov 4, 2009 at 09:19, Kelly O'Hair  wrote:

> Managing the ProblemList (as Jon noted) will be a pain at times.

It's even more of a problem as development becomes more distributed,
as failures become platform-dependent, etc...

I would prefer to see per-file annotations that jtreg can understand.

I also like the approach I advocated some years ago:
- run tests under JDK 1
- run tests under JDK 2
- diff the results (JTreport directories)
See my diff-javatest script.
jtreg now has support for this (I haven't tried it lately).

Martin

Re: Need reviewers - jdk testing changes 6888927

[Martin Buchholz]

One of the things you've done is to create "test sets".
I did something like that in my "jtr" script (ask Tim if you can't find it).
For each logical component, it's non-trivial to find all the tests
for that (e.g. how to test string handling).
This is especially true for shared directories like java/lang
and java/util.  I don't think there's much value in creating a special
target for testing java/util, since
1) jtreg can do that easily already
2) this doesn't match the job of any particular technology developer

What would be really useful is to try to fix all the tests
that fail under -samevm (perhaps by marking them
@run othervm)

Martin

On Tue, Nov 3, 2009 at 18:03, Kelly O'Hair  wrote:

>
> I need some formal reviewers on these jdk/test/Makefile changes.
>
> More polish and changes may need to be done later, but there
> is value in what I have now, and I need lots of help to improve
> things (and fix some of our testcases).
>
> Here is the bugid and webrev:
>
> 6888927: Fix jdk jtreg tests to indicate which ones need othervm, allow for
> use of samevm option
>
> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-samevm-6888927/webrev/
>
> The goal was to see if we could easily run most of the regression
> tests in the jdk/test directory, in minimum time, and without so
> much noise (e.g. do not run unstable or problematic tests).
> This could then be used as a benchmark to validate some quality measure
> of the jdk7 that was built.
>
> The primary changes include:
>  * New jdk/test/Makefile targets: jdk_all jdk_lang jdk_util jdk_nio ...
>  * Addition of a jdk/test/ProblemList file to be used by jdk/test/Makefile
>
> I tried to group all the tests (by directory names) into jdk_* sets, then
> tried to balance them as to how long each set ran and if they could be run
> with the jtreg -samevm option. The balancing was tricky, and will need more
> polish, along with the virtual frame buffer idea. I also had to give up
> on the awt, rmi, and swing tests until the Xvfb issues are figured out.
>
> I chose to not actually modify the tests themselves if they needed fixing,
> it was just too overwhelming. So developers and teams may want to browse
> the
> ProblemList for their favorite tests (which aren't my favorites ;^) and
> consider what they might want to do.
>
> With this new jdk/test/Makefile, anybody can:
>
>  cd jdk/test
>  gnumake [PRODUCT_HOME=${YOUR_JDK7_HOME}] [JT_HOME=${YOUR_JTREG_HOME}]
> jdk_all
>
> And run about 3,000+ tests that SHOULD PASS in roughly 2 hours if your
> machine isn't too slow and old. I was able to run it in 90 minutes on a
> monster OpenSolaris AMD machine which had 16Gb RAM and 16 2.2Ghz cpus.
>
> Then I added "-j 4" to the gnumake command line and it only took 30mins!
> So the various jdk_* make targets can be run in parallel.
>
> Please let me know what you think.
>
> -kto
>
>
>

Re: Need reviewers - jdk testing changes 6888927

[Martin Buchholz]

On Tue, Nov 3, 2009 at 18:45, Jonathan Gibbons wrote:

>
> The thing that stood out to me was the use of SLASH_JAVA which is something
> of a Sun legacy which doesn't apply to folk outside Sun.
>

I've been using SLASH_JAVA because it simplifies the job of organizing
my jdk build dependencies.  make sanity tells me where it's expecting
to find things, and I fulfill its expectations.
Admittedly, the organization is easier to understand if you've
previously worked at Sun.

Martin

Re:

[Martin Buchholz]

Hi Max,

Sounds to me like you're using a very recent gcc.
My policy has been to use a stodgy gcc,
and let other folks use bleeding edge.
Fedora/Ubuntu hackers are more likely
to dogfood their gcc so check out the
icedtea patch set.

I wish that Openjdk release engineering maintained
buildability by a broad range of compilers
through regular testing.

Martin

On Thu, Oct 22, 2009 at 18:05, Max (Weijun) Wang  wrote:
> Hi Martin
>
> I've just changed my Linux box to a x86_64 one, and my first build of JDK 7
> shows these errors:
>
> ...
> cc1plus: warnings being treated as errors
> /media/sda6/space/work/myjdk/hotspot/src/cpu/x86/vm/methodHandles_x86.cpp:
> In function ‘void trace_method_handle_stub(const char*, oopDesc*, intptr_t*,
> intptr_t*)’:
> /media/sda6/space/work/myjdk/hotspot/src/cpu/x86/vm/methodHandles_x86.cpp:276:
> error: format ‘%016lx’ expects type ‘long unsigned int’, but argument 3 has
> type ‘void*’
> /media/sda6/space/work/myjdk/hotspot/src/cpu/x86/vm/methodHandles_x86.cpp:276:
> error: format ‘%016lx’ expects type ‘long unsigned int’, but argument 4 has
> type ‘intptr_t*’
> make[7]: *** [methodHandles_x86.o] Error 1
> ...
>
> What am I missing here? and, do you have any private patches to share?
>
> Thanks
> Max
>
>

Re: JDK 7 build 73 is available at the openjdk.java.net website

[Martin Buchholz]

Hi,

I tried building jdk7-b73 on Ubuntu dapper,
and had it fail with


BUILD FAILED
.../jaxp/build-defs.xml:66: Could not create task or type of type:
replaceregexp.

Ant could not find the task or a class this task relies upon.



This problem does not happen on Ubuntu hardy.

It appears to be fixed by installing the "ant-optional"
debian package, in addition to "ant".
But this is not obvious - it might be worth adding
sanity checks and/or documentation.

Martin

On Fri, Oct 2, 2009 at 15:24, Michael Wilkerson
 wrote:
> The OpenJDK source is available at:
> http://hg.openjdk.java.net/jdk7/jdk7
> http://hg.openjdk.java.net/jdk7/jdk7/rev/3ac6dcf78232
>
> The OpenJDK source binary plugs for the promoted JDK 7 build 73 are
> available under the openjdk http://openjdk.java.net website under Source
> Code (direct link to bundles: http://download.java.net/openjdk/jdk7)
>
> Summary of changes:
> http://download.java.net/jdk7/changes/jdk7-b73.html
>
>
> -Michael
>

Re: Please review fix for 6705913 "freetype_versioncheck.exe - Unable To Locate Component"

[Martin Buchholz]

On Fri, Aug 21, 2009 at 13:46, Tim Bell  wrote:

>
> BTW: Our current releases work because they put a copy of msvcr71.dll into
> C:/WINDOWS/system32/.  This trick was always vulnerable to having the file
> replaced or deleted by some other application or installer.  The option
> has been specifically ruled out by Microsoft for the newer runtimes.
>

Well, I have to side with Microsoft on this one.
One of my favorite features of the jdk (on Unix)
is how the installation is self-contained and "just works"
without modifying any OS-specific directories,
or indeed any sort of "install" process.

Martin

Re: Please review fix for 6705913 "freetype_versioncheck.exe - Unable To Locate Component"

[Martin Buchholz]

A way to check at runtime, since freetype 2.0.9, is

- A  new function  named  `FT_Library_Version' has  been added  to
  return  the current  library's major,  minor, and  patch version
  numbers.   This is  important since  the  macros FREETYPE_MAJOR,
  FREETYPE_MINOR,  and  FREETYPE_PATCH  cannot  be used  when  the
  library is dynamically linked by a program.

So it is possible to have compile-time, link-time,
and run-time library versions checked.

---

BTW, I just can't believe that building a simple program
with recent microsoft compilers can be so difficult.
There must be a saner way.

Martin


On Fri, Aug 21, 2009 at 12:20, Kelly O'Hair  wrote:

> Humm...  as much as building a freetype application tells us that the
> libraries work, I'm wondering if we could just do something like this
> in the makefile sanity check:
>
> ifdef OPENJDK
>  FREETYPE_VERSION_H=$(FREETYPE_HEADERS_PATH)/freetype/freetype.h
>  _FREETYPE_VER := \
>if [ -f "${FREETYPE_VERSION_H}" ] ; then \
>  _major="`${GREP} 'define FREETYPE_MAJOR' | ${CUT} -d' ' -f3`" ; \
>  _minor="`${GREP} 'define FREETYPE_MINOR' | ${CUT} -d' ' -f3`" ; \
>  _micro="`${GREP} 'define FREETYPE_PATCH' | ${CUT} -d' ' -f3`" ; \
>  $(ECHO) "${_major}.${_minor}.${_micro}"; \
>else \
>  $(ECHO) "0.0.0"; \
>fi
>  FREETYPE_VER :=$(call GetVersion,"$(_FREETYPE_VER)")
>  FREETYPE_CHECK :=$(call
> CheckVersions,$(FREETYPE_VER),$(REQUIRED_FREETYPE_VERSION))
>
> sane-freetype:
>@if [ "$(FREETYPE_CHECK)" != "same" -a "$(FREETYPE_CHECK)" !=
> "newer" ]; then \
>  $(ECHO) "ERROR: The version of freetype being used is older than
> \n" \
>  "the required version of '$(REQUIRED_FREETYPE_VERSION)'.
> \n" \
>  "The version of freetype found was '$(FREETYPE_VER)'. \n"
> \
>  "" >> $(ERROR_FILE) ; \
>fi
>
> else
>
> #do nothing  (not OpenJDK)
> sane-freetype:
>
> endif
>
>
> ---
> Just a thought Then that whole freetype check program can go away,
> but if the libraries are wrong, we won't find out at sanity check time.
>
> (I have not tested the above logic)
>
> -kto
>
>
> Tim Bell wrote:
>
>> Kelly O'Hair wrote:
>>
>>> Looks good Tim.
>>>
>>
>> Thanks, Kelly.  I plan to push this fix to the build forest later today.
>>
>>  I wish that freetype just had a simple version.h file we could check. :^(
>>>
>>
>> I checked the freetype 2.3.5 include files... we could use this from
>> include/freetype/freetype.h:
>>
>>
>>  /*
>>   *
>>   *  @enum:
>>   *FREETYPE_XXX
>>   *
>>   *  @description:
>>   *These three macros identify the FreeType source code version.
>>   *Use @FT_Library_Version to access them at runtime.
>>   *
>>   *  @values:
>>   *FREETYPE_MAJOR :: The major version number.
>>   *FREETYPE_MINOR :: The minor version number.
>>   *FREETYPE_PATCH :: The patch level.
>>   *
>>   *  @note:
>>   *The version number of FreeType if built as a dynamic link library
>>   *with the `libtool' package is _not_ controlled by these three
>>   *macros.
>>   */
>> #define FREETYPE_MAJOR  2
>> #define FREETYPE_MINOR  3
>> #define FREETYPE_PATCH  5
>>
>>
>>
>> Tim
>>
>>  -kto
>>>
>>> Tim Bell wrote:
>>>
 Hi Folks

 When building OpenJDK, the freetype sanity check compiles a
 little program to test that the freetype include files and
 libraries are available, and also that the version number is
 acceptable.

 If building on Windows and using a Visual Studio compiler
 newer than 2003, this program will fail due to the new
 rules for accessing MSVCR??.dll. [1]

 I didn't make the up the rules, in fact I am extremely
 puzzled that Microsoft is forcing ALL external developers
 and ISVs to solve this problem.  I am trying to get the
 OpenJDK build to deal with them or at least tolerate
 them for those people out there who build OpenJDK on
 Windows.

 The bugzilla report:
  https://bugs.openjdk.java.net/show_bug.cgi?id=100101

 The code review:
  
 http://cr.openjdk.java.net/~tbell/6705913/webrev.00/

 These changes build OK on all JPRT systems:

 linux_i586_2.6
 linux_x64_2.6
 solaris_i586_5.10
 solaris_sparc_5.10
 solaris_sparcv9_5.10
 solaris_x64_5.10-
 windows_i586_5.0
 windows_x64_5.2

 They also work on my Windows XP SP2 / Visual Studio 2008
 build machine.

 Thanks in advance-

 Tim

 [1] How to redistribute the Visual C++ Libraries with your application
 (Ben Anderson)

 http://blogs.msdn.com/vcblog/archive/2007/10/12/how-to-redistribute-the-visual-c-libraries-with-your-application.aspx

>>>
>>

Re: Can't build latest openjdk6

[Martin Buchholz]

As an experiment, I tried the obvious

diff --git a/make/Defs-internal.gmk b/make/Defs-internal.gmk
--- a/make/Defs-internal.gmk
+++ b/make/Defs-internal.gmk
@@ -205,6 +205,7 @@
 JDK_MAKE_SHARED_DIR=$(ABS_JDK_TOPDIR)/make/common/shared \
 EXTERNALSANITYCONTROL=true \
 TARGET_CLASS_VERSION=$(TARGET_CLASS_VERSION) \
+SOURCE_LANGUAGE_VERSION=$(TARGET_CLASS_VERSION) \
 MILESTONE=$(MILESTONE) \
 BUILD_NUMBER=$(BUILD_NUMBER) \
 JDK_BUILD_NUMBER=$(JDK_BUILD_NUMBER) \

and to my surprise, that caused the build to succeed.
Note: This message still in bug-reporting, not bug-fixing, mode!

Martin

On Thu, Aug 13, 2009 at 21:27, Joseph D. Darcy wrote:
> I'll do some test builds myself on Friday.
>
> -Joe
>
> Jonathan Gibbons wrote:
>>
>> Martin,
>>
>> Comment noted.   I'm now on vacation, so I'll look at this next week.
>>
>> -- Jon
>>
>> On Aug 13, 2009, at 6:10 PM, Martin Buchholz wrote:
>>
>>> It appears that ant is being invoked with "-Djavac.target=5", but not
>>> with -Djavac.source
>>>
>>> execve("/usr/bin/ant", ["ant", "-Djdk.version=1.6.0",
>>> "-Dfull.version=1.6.0-internal-ma"..., "-Dmilestone=internal",
>>> "-Dbuild.number=b00", "-Djavac.target=5", "-Dboot.java.home=/ .
>>>
>>> In turn, this may be due to COMMON_BUILD_ARGUMENTS
>>> including TARGET_CLASS_VERSION but not SOURCE_LANGUAGE_VERSION
>>>
>>> # 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 would explain why invoking ant directly in the langtools directory
>>> without -Djavac.target=5 would work fine (I haven't tried it).
>>>
>>> langtools build.xml could try to check javac.target and ensure that
>>> javac.source <= javac.target
>>> but I don't know how to do that (I hack make, not ant).
>>>
>>> Martin
>>>
>>> On Thu, Aug 13, 2009 at 17:35, Jonathan Gibbons
>>> wrote:
>>>>
>>>> The primary goal of changeset:   49:608910eef036 is to bring the
>>>> langtools
>>>> build into line between jdk6 and jdk7, so that we can rely on
>>>> eseentially
>>>>  the same behavior (subject to version differences) across the two
>>>> repositoiries.
>>>>
>>>> The override mechanism is unused and harmless since javac.source is
>>>> correctly defaulted in build.properties.  It is included in 6 to
>>>> minimize
>>>> the differences between 6 and 7.
>>>>
>>>> Generally, the langtools build tries to isolate the user as much as
>>>> possible
>>>> from the version of Java used to run Ant.
>>>> To build langtools, you should just need to set boot.java.home; to run
>>>> the
>>>> regression tests, you will also need to
>>>> set target.java.home.
>>>>
>>>> -- Jon
>>>>
>>>>
>>>> On Aug 13, 2009, at 5:00 PM, Mark Wielaard wrote:
>>>>
>>>>> Hi Martin,
>>>>>
>>>>> On Thu, 2009-08-13 at 15:25 -0700, Martin Buchholz wrote:
>>>>>>
>>>>>> /home/martinrb/ws/openjdk6/build/linux-amd64/langtools/build/classes
>>>>>>  [javac] javac: source release 6 requires target release 1.6
>>>>>>
>>>>>> BUILD FAILED
>>>>>>
>>>>>> /usr/local/google/home/martin/ws/openjdk6/langtools/make/build.xml:196:
>>>>>> The following error occurred while executing this line:
>>>>>>
>>>>>> /usr/local/google/home/martin/ws/openjdk6/langtools/make/build.xml:525:
>>>>>> Compile failed; see the compiler error output for details.
>>>>>>
>>>>>&

Re: Can't build latest openjdk6

[Martin Buchholz]

It appears that ant is being invoked with "-Djavac.target=5", but not
with -Djavac.source

execve("/usr/bin/ant", ["ant", "-Djdk.version=1.6.0",
"-Dfull.version=1.6.0-internal-ma"..., "-Dmilestone=internal",
"-Dbuild.number=b00", "-Djavac.target=5", "-Dboot.java.home=/ .

In turn, this may be due to COMMON_BUILD_ARGUMENTS
including TARGET_CLASS_VERSION but not SOURCE_LANGUAGE_VERSION

# 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 would explain why invoking ant directly in the langtools directory
without -Djavac.target=5 would work fine (I haven't tried it).

langtools build.xml could try to check javac.target and ensure that
javac.source <= javac.target
but I don't know how to do that (I hack make, not ant).

Martin

On Thu, Aug 13, 2009 at 17:35, Jonathan Gibbons wrote:
> The primary goal of changeset:   49:608910eef036 is to bring the langtools
> build into line between jdk6 and jdk7, so that we can rely on eseentially
>  the same behavior (subject to version differences) across the two
> repositoiries.
>
> The override mechanism is unused and harmless since javac.source is
> correctly defaulted in build.properties.  It is included in 6 to minimize
> the differences between 6 and 7.
>
> Generally, the langtools build tries to isolate the user as much as possible
> from the version of Java used to run Ant.
> To build langtools, you should just need to set boot.java.home; to run the
> regression tests, you will also need to
> set target.java.home.
>
> -- Jon
>
>
> On Aug 13, 2009, at 5:00 PM, Mark Wielaard wrote:
>
>> Hi Martin,
>>
>> On Thu, 2009-08-13 at 15:25 -0700, Martin Buchholz wrote:
>>>
>>> /home/martinrb/ws/openjdk6/build/linux-amd64/langtools/build/classes
>>>   [javac] javac: source release 6 requires target release 1.6
>>>
>>> BUILD FAILED
>>> /usr/local/google/home/martin/ws/openjdk6/langtools/make/build.xml:196:
>>> The following error occurred while executing this line:
>>> /usr/local/google/home/martin/ws/openjdk6/langtools/make/build.xml:525:
>>> Compile failed; see the compiler error output for details.
>>>
>>> whether or not I use a vanilla jdk6 (or even jdk7) as bootstrap jdk
>>>
>>> Can anyone else successfully build openjdk6?
>>> If so, what is the secret?
>>> Did I miss something in my inbox?
>>
>> I haven't tried upgrading oj6 yet. And one of the reasons for not
>> upgrading icedtea6 atm is to make sure the recent changes (which as far
>> as I could tell were not discussed on the list) to the source and target
>> defaults don't break the bootstrap. The commit you probably want to
>> inspect is:
>>
>> changeset:   49:608910eef036
>> user:        jjg
>> date:        Tue Aug 11 16:40:03 2009 -0700
>> files:       make/Makefile make/build.properties make/build.xml
>> description:
>> 6870641: [langtools] update make/build.* for jdk6
>> Reviewed-by: darcy
>>
>> Unfortunately the bug associated with that commit is also not public.
>>
>> The idea behind the commit seems to be to make the -source and -target
>> explicit in more places (which is a good thing). There is now also an
>> override mechanism, that I admit to not fully understand because it
>> seems to be never used, through setting SOURCE_LANGUAGE_VERSION and/or
>> JAVAC_SOURCE_ARG.
>>
>> Also note that with ant the default source and target depends on the VM
>> that runs the ant process (which might be different from the bootstrap
>> VM you are using, it probably depends on your ant installation).
>>
>> Cheers,
>>
>> Mark
>>
>
>

Re: Can't build latest openjdk6

[Martin Buchholz]

The version of java using ant being significant
means there are 3 different java versions being juggled during
a single build - it's easy for us all to get very confused.

I'm going to try to stay in bug-reporting mode, not bug-fixing mode,
with this problem unless Jonathan/Kelly/Joe can't reproduce the failure.

Martin

On Thu, Aug 13, 2009 at 17:00, Mark Wielaard wrote:
> Hi Martin,
>
> On Thu, 2009-08-13 at 15:25 -0700, Martin Buchholz wrote:
>> /home/martinrb/ws/openjdk6/build/linux-amd64/langtools/build/classes
>>     [javac] javac: source release 6 requires target release 1.6
>>
>> BUILD FAILED
>> /usr/local/google/home/martin/ws/openjdk6/langtools/make/build.xml:196:
>> The following error occurred while executing this line:
>> /usr/local/google/home/martin/ws/openjdk6/langtools/make/build.xml:525:
>> Compile failed; see the compiler error output for details.
>>
>> whether or not I use a vanilla jdk6 (or even jdk7) as bootstrap jdk
>>
>> Can anyone else successfully build openjdk6?
>> If so, what is the secret?
>> Did I miss something in my inbox?
>
> I haven't tried upgrading oj6 yet. And one of the reasons for not
> upgrading icedtea6 atm is to make sure the recent changes (which as far
> as I could tell were not discussed on the list) to the source and target
> defaults don't break the bootstrap. The commit you probably want to
> inspect is:
>
> changeset:   49:608910eef036
> user:        jjg
> date:        Tue Aug 11 16:40:03 2009 -0700
> files:       make/Makefile make/build.properties make/build.xml
> description:
> 6870641: [langtools] update make/build.* for jdk6
> Reviewed-by: darcy
>
> Unfortunately the bug associated with that commit is also not public.
>
> The idea behind the commit seems to be to make the -source and -target
> explicit in more places (which is a good thing). There is now also an
> override mechanism, that I admit to not fully understand because it
> seems to be never used, through setting SOURCE_LANGUAGE_VERSION and/or
> JAVAC_SOURCE_ARG.
>
> Also note that with ant the default source and target depends on the VM
> that runs the ant process (which might be different from the bootstrap
> VM you are using, it probably depends on your ant installation).
>
> Cheers,
>
> Mark
>
>

Re: Can't build latest openjdk6

[Martin Buchholz]

There seems to be what they like to call an impedance mismatch
between make and ant.

make prints

JAVAC_CMD = 
/usr/local/google/SLASH_JAVA/re/openjdk/6/promoted/latest/binaries/linux-amd64/bin/javac
 -J-XX:ThreadStackSize=1536 -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m
-J-XX:MaxPermSize=160m  -source 1.5 -target 5 -encoding ascii
-Xbootclasspath:/home/martinrb/ws/openjdk6/build/linux-amd64/classes

but strace tells me that ant is invoking

[pid 12600] execve(".../linux-amd64/bin/javac",
["/usr/local/google/SLASH_JAVA/re/"..., "-d",
"/home/martinrb/ws/openjdk6/build"..., "-classpath",
"/home/martinrb/ws/openjdk6/build"..., "-target", "5", "-g:none",
"-J-Xbootclasspath/p:/home/martin"..., "-Xlint", "-source", "6",
..

where you can see the mismatch between -source and -target

Could this have something to do with my ANT version, perhaps too new?

  ANT_VER = 1.7 [requires at least 1.6.3]

Martin

On Thu, Aug 13, 2009 at 16:00, Jonathan Gibbons wrote:
> The langtools Hudson for jdk6/jdk6/langtools is happy here, last built Aug
> 12, 9:02. a.m.
>
> -- Jon
>
> Martin Buchholz wrote:
>>
>> When I try to build latest hg openjdk6, I get:
>>
>>
>> build-classes-javac:
>>    [mkdir] Created dir:
>> /home/martinrb/ws/openjdk6/build/linux-amd64/langtools/build/gensrc
>>    [mkdir] Created dir:
>> /home/martinrb/ws/openjdk6/build/linux-amd64/langtools/build/classes
>>  [pcompile] Generating 7 resource files to
>> /home/martinrb/ws/openjdk6/build/linux-amd64/langtools/build/gensrc
>>     [copy] Copying 1 file to
>> /home/martinrb/ws/openjdk6/build/linux-amd64/langtools/build/gensrc
>>  [pcompile] Generating 1 resource files to
>> /home/martinrb/ws/openjdk6/build/linux-amd64/langtools/build/gensrc
>>    [javac] Compiling 8 source files to
>> /home/martinrb/ws/openjdk6/build/linux-amd64/langtools/build/classes
>>    [javac] javac: source release 6 requires target release 1.6
>>
>> BUILD FAILED
>> /usr/local/google/home/martin/ws/openjdk6/langtools/make/build.xml:196:
>> The following error occurred while executing this line:
>> /usr/local/google/home/martin/ws/openjdk6/langtools/make/build.xml:525:
>> Compile failed; see the compiler error output for details.
>>
>>
>> whether or not I use a vanilla jdk6 (or even jdk7) as bootstrap jdk
>>
>> Can anyone else successfully build openjdk6?
>> If so, what is the secret?
>> Did I miss something in my inbox?
>>
>> Martin
>>
>
>

Can't build latest openjdk6

[Martin Buchholz]

When I try to build latest hg openjdk6, I get:


build-classes-javac:
[mkdir] Created dir:
/home/martinrb/ws/openjdk6/build/linux-amd64/langtools/build/gensrc
[mkdir] Created dir:
/home/martinrb/ws/openjdk6/build/linux-amd64/langtools/build/classes
 [pcompile] Generating 7 resource files to
/home/martinrb/ws/openjdk6/build/linux-amd64/langtools/build/gensrc
 [copy] Copying 1 file to
/home/martinrb/ws/openjdk6/build/linux-amd64/langtools/build/gensrc
 [pcompile] Generating 1 resource files to
/home/martinrb/ws/openjdk6/build/linux-amd64/langtools/build/gensrc
[javac] Compiling 8 source files to
/home/martinrb/ws/openjdk6/build/linux-amd64/langtools/build/classes
[javac] javac: source release 6 requires target release 1.6

BUILD FAILED
/usr/local/google/home/martin/ws/openjdk6/langtools/make/build.xml:196:
The following error occurred while executing this line:
/usr/local/google/home/martin/ws/openjdk6/langtools/make/build.xml:525:
Compile failed; see the compiler error output for details.


whether or not I use a vanilla jdk6 (or even jdk7) as bootstrap jdk

Can anyone else successfully build openjdk6?
If so, what is the secret?
Did I miss something in my inbox?

Martin

Re: Need reviewers - 6856630: Restructure jaxp repository

[Martin Buchholz]

On Thu, Aug 13, 2009 at 13:33, Joseph D. Darcy wrote:
> Hello.
>
> From my home network (no Sun VPN, etc.) I was successfully able to do a
> build of jaxp after applying Kelly's patch and (after setting up the
> environment a bit http://blogs.sun.com/kto/entry/anatomy_of_the_jdk_build).
>  I used my laptop running Ubuntu 8.10.  The download of the jaxp source
> bundle went smoothly.
>
> Martin, can you please verify the modified jaxp build works for you too?

I haven't really been following this effort.. and don't have any special
expertise here.  The RedHat folks have more experience separating
out independently obtained sources.

Martin

> Kelly, I don't think the update to .hgignore should be included in your
> patch; although it is a good idea.
>
> -Joe
>

Re: JDK 7 build 59 is available at the openjdk.java.net website

[Martin Buchholz]

I'm not sure whether the problem was at my end or your end,
but I retried the download and everything is now fine.

Martin

On Sat, May 16, 2009 at 00:13, Martin Buchholz  wrote:
> Now the b59 bits are available, but there is a new problem:
>
>  $ java -jar jdk-7-ea-plug-b59-linux-x64-14_may_2009.jar
> Invalid or corrupt jarfile jdk-7-ea-plug-b59-linux-x64-14_may_2009.jar
>
> Martin
>
> On Thu, May 14, 2009 at 19:59, Martin Buchholz  wrote:
>> On Thu, May 14, 2009 at 17:13, Vassili Igouchkine
>>  wrote:
>>> Code (direct link to bundles: http://download.java.net/openjdk/jdk7)
>>
>> The URL http://download.java.net/openjdk/jdk7 still has b58 as of this 
>> writing.
>>
>> Martin
>>
>

Re: JDK 7 build 59 is available at the openjdk.java.net website

[Martin Buchholz]

Now the b59 bits are available, but there is a new problem:

 $ java -jar jdk-7-ea-plug-b59-linux-x64-14_may_2009.jar
Invalid or corrupt jarfile jdk-7-ea-plug-b59-linux-x64-14_may_2009.jar

Martin

On Thu, May 14, 2009 at 19:59, Martin Buchholz  wrote:
> On Thu, May 14, 2009 at 17:13, Vassili Igouchkine
>  wrote:
>> Code (direct link to bundles: http://download.java.net/openjdk/jdk7)
>
> The URL http://download.java.net/openjdk/jdk7 still has b58 as of this 
> writing.
>
> Martin
>

Re: Review Request: 6812511: Allow Interpreter-only builds

[Martin Buchholz]

[+build-dev]

Not that it matters much, but build-dev is a better list for this patch
than core-libs-dev.

Martin

On Fri, May 8, 2009 at 09:14, Gary Benson  wrote:
> Hi all,
>
> I have a patch that's been sitting in the bug databases for a while:
>
>  https://bugs.openjdk.java.net/show_bug.cgi?id=100011
>  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6812511
>
> It allows HotSpot to be built interpreter-only, which is required
> for the Zero assembler port.  It touches both the hotspot and the
> jdk forests, so it may need approval from someone in both teams.
> Christian Thalinger (twisti) said that someone (Kelly?) told him
> verbally it was fine to commit a while back, but it was a month
> or so ago and can't remember exactly what was said.  I have push
> access (I think -- I've not tried it out yet!) but I don't want
> to commit it while it's ambiguous like this.
>
> Cheers,
> Gary
>
> --
> http://gbenson.net/
>

Re: PATCH: Tired of waiting for rt.jar to build?

[Martin Buchholz]

On Tue, Apr 28, 2009 at 16:27, Martin Buchholz  wrote:
> On Mon, Apr 27, 2009 at 17:54, Martin Buchholz  wrote:
>> Someone who cares about the Makefiles can also try to remove the
>> 16000 gratuitous -C flags that makes jar's life "jar hell".
>
> Hmmm Apparently I care enough.
>
> Kelly (or Tim?), please review.

Let's try that again.

http://cr.openjdk.java.net/~martin/dashJ

diff --git a/make/common/Release.gmk b/make/common/Release.gmk
--- a/make/common/Release.gmk
+++ b/make/common/Release.gmk
@@ -94,7 +94,7 @@
   ifeq ($(PLATFORM), windows)
 LICENSE_DOCLIST_JDK = $(subst $(LICENSE_VERSION),,\
   $(shell $(CD) $(SHARE_JDK_DOC_SRC) && \
-  $(LS) *LICENSE*$(LICENSE_VERSION)))
+  $(LS) *LICENSE*$(LICENSE_VERSION)))
 LICENSE_DOCLIST_JRE = $(subst $(LICENSE_VERSION),,\
   $(shell $(CD) $(SHARE_JRE_DOC_SRC) && \
   $(LS) *LICENSE*$(LICENSE_VERSION)))
@@ -399,7 +399,7 @@
sun/tools/jstack\
sun/tools/jinfo \
sun/tools/jmap
-   
+
 # classes that go into jsse.jar
 JSSE_CLASSES_DIRS = \
sun/security/provider/Sun.class \
@@ -644,7 +644,7 @@
@$(java-vm-cleanup)

 # Create the manifest file.
-JAR_MANIFEST_FILE=$(TEMPDIR)/manifest.tmp
+JAR_MANIFEST_FILE=$(ABS_TEMPDIR)/manifest.tmp
 $(JAR_MANIFEST_FILE): $(MAINMANIFEST) $(BEANMANIFEST)
$(prep-target)
$(SED) -e "s/@@RELEASE@@/$(RELEASE)/" $(MAINMANIFEST) >> $@
@@ -652,25 +652,22 @@
$(CAT) $(BEANMANIFEST) >> $@

 # Create resources.jar containing non-class files
-RESOURCES_JAR=$(TEMPDIR)/resources-orig.jar
-RES_JAR_ARGLIST=$(RES_JAR_FILELIST)_args
-$(RES_JAR_ARGLIST): $(RES_JAR_FILELIST)
+RESOURCES_JAR=$(ABS_TEMPDIR)/resources-orig.jar
+$(RESOURCES_JAR): $(RES_JAR_FILELIST) $(JAR_MANIFEST_FILE)
$(prep-target)
-   $(SED) -e "s...@^@-C $(CLASSBINDIR) @" $< > $@
-$(RESOURCES_JAR): $(RES_JAR_ARGLIST) $(JAR_MANIFEST_FILE)
-   $(prep-target)
-   $(BOOT_JAR_CMD) c0mf $(JAR_MANIFEST_FILE) $@ \
-   @$(RES_JAR_ARGLIST) $(BOOT_JAR_JFLAGS)
-   @$(java-vm-cleanup)
+   $(CD) $(CLASSBINDIR) && \
+   $(BOOT_JAR_CMD) c0mf $(JAR_MANIFEST_FILE) $@ \
+   @$(RES_JAR_FILELIST) $(BOOT_JAR_JFLAGS)
+   @$(CD) $(CLASSBINDIR) && $(java-vm-cleanup)

 # Create jsse.jar containing SunJSSE implementation classes
-JSSE_JAR=$(TEMPDIR)/jsse-orig.jar
+JSSE_JAR=$(ABS_TEMPDIR)/jsse-orig.jar
 $(JSSE_JAR): $(JAR_MANIFEST_FILE)
$(prep-target)
-   $(BOOT_JAR_CMD) c0mf $(JAR_MANIFEST_FILE) $@ \
-   $(JSSE_CLASSES_DIRS:%=-C $(CLASSBINDIR) %) \
-   $(BOOT_JAR_JFLAGS)
-   @$(java-vm-cleanup)
+   $(CD) $(CLASSBINDIR) && \
+   $(BOOT_JAR_CMD) c0mf $(JAR_MANIFEST_FILE) $@ \
+   $(JSSE_CLASSES_DIRS) $(BOOT_JAR_JFLAGS)
+   @$(CD) $(CLASSBINDIR) && $(java-vm-cleanup)

 # Create sec-bin.zip
 SEC_FILES_ZIP=$(ABS_TEMPDIR)/sec-bin.zip
@@ -712,15 +709,12 @@

 # Create rt.jar
 RT_JAR=$(ABS_TEMPDIR)/rt-orig.jar
-RT_JAR_ARGLIST=$(RT_JAR_FILELIST)_args
-$(RT_JAR_ARGLIST): $(RT_JAR_FILELIST)
+$(RT_JAR): $(RT_JAR_FILELIST) $(JAR_MANIFEST_FILE)
$(prep-target)
-   $(SED) -e "s...@^@-C $(CLASSBINDIR) @" $< > $@
-$(RT_JAR): $(RT_JAR_ARGLIST) $(JAR_MANIFEST_FILE)
-   $(prep-target)
-   $(BOOT_JAR_CMD) c0mf $(JAR_MANIFEST_FILE) $@ \
-   @$(RT_JAR_ARGLIST) $(BOOT_JAR_JFLAGS)
-   @$(java-vm-cleanup)
+   $(CD) $(CLASSBINDIR) && \
+   $(BOOT_JAR_CMD) c0mf $(JAR_MANIFEST_FILE) $@ \
+   @$(RT_JAR_FILELIST) $(BOOT_JAR_JFLAGS)
+   @$(CD) $(CLASSBINDIR) && $(java-vm-cleanup)

 # Meta-index construction to make core class loaders lazier

@@ -943,10 +937,10 @@
@#
@# lib/tools.jar
@#
-   $(BOOT_JAR_CMD) c0f $(LIBDIR)/tools.jar $(addprefix \
-   -C $(CLASSBINDIR) , $(TOOLS)) \
-   $(BOOT_JAR_JFLAGS)
-   @$(java-vm-cleanup)
+   $(CD) $(CLASSBINDIR) && \
+   $(BOOT_JAR_CMD) c0f $(ABS_LIBDIR)/tools.jar \
+   $(TOOLS) $(BOOT_JAR_JFLAGS)
+   @$(CD) $(CLASSBINDIR) && $(java-vm-cleanup)
$(CP) $(LIBDIR)/tools.jar $(JDK_IMAGE_DIR)/lib/tools.jar
@#
@# lib/ct.sym

Re: PATCH: Tired of waiting for rt.jar to build?

[Martin Buchholz]

On Mon, Apr 27, 2009 at 17:54, Martin Buchholz  wrote:
> Someone who cares about the Makefiles can also try to remove the
> 16000 gratuitous -C flags that makes jar's life "jar hell".

Hmmm Apparently I care enough.

Kelly (or Tim?), please review.

diff --git a/make/common/Release.gmk b/make/common/Release.gmk
--- a/make/common/Release.gmk
+++ b/make/common/Release.gmk
@@ -644,7 +644,7 @@
@$(java-vm-cleanup)

 # Create the manifest file.
-JAR_MANIFEST_FILE=$(TEMPDIR)/manifest.tmp
+JAR_MANIFEST_FILE=$(ABS_TEMPDIR)/manifest.tmp
 $(JAR_MANIFEST_FILE): $(MAINMANIFEST) $(BEANMANIFEST)
$(prep-target)
$(SED) -e "s/@@RELEASE@@/$(RELEASE)/" $(MAINMANIFEST) >> $@
@@ -652,25 +652,22 @@
$(CAT) $(BEANMANIFEST) >> $@

 # Create resources.jar containing non-class files
-RESOURCES_JAR=$(TEMPDIR)/resources-orig.jar
-RES_JAR_ARGLIST=$(RES_JAR_FILELIST)_args
-$(RES_JAR_ARGLIST): $(RES_JAR_FILELIST)
+RESOURCES_JAR=$(ABS_TEMPDIR)/resources-orig.jar
+$(RESOURCES_JAR): $(RES_JAR_FILELIST) $(JAR_MANIFEST_FILE)
$(prep-target)
-   $(SED) -e "s...@^@-C $(CLASSBINDIR) @" $< > $@
-$(RESOURCES_JAR): $(RES_JAR_ARGLIST) $(JAR_MANIFEST_FILE)
-   $(prep-target)
-   $(BOOT_JAR_CMD) c0mf $(JAR_MANIFEST_FILE) $@ \
-   @$(RES_JAR_ARGLIST) $(BOOT_JAR_JFLAGS)
-   @$(java-vm-cleanup)
+   $(CD) $(CLASSBINDIR) && \
+   $(BOOT_JAR_CMD) c0mf $(JAR_MANIFEST_FILE) $@ \
+   @$(RES_JAR_FILELIST) $(BOOT_JAR_JFLAGS)
+   @$(CD) $(CLASSBINDIR) && $(java-vm-cleanup)

 # Create jsse.jar containing SunJSSE implementation classes
-JSSE_JAR=$(TEMPDIR)/jsse-orig.jar
+JSSE_JAR=$(ABS_TEMPDIR)/jsse-orig.jar
 $(JSSE_JAR): $(JAR_MANIFEST_FILE)
$(prep-target)
-   $(BOOT_JAR_CMD) c0mf $(JAR_MANIFEST_FILE) $@ \
-   $(JSSE_CLASSES_DIRS:%=-C $(CLASSBINDIR) %) \
-   $(BOOT_JAR_JFLAGS)
-   @$(java-vm-cleanup)
+   $(CD) $(CLASSBINDIR) && \
+   $(BOOT_JAR_CMD) c0mf $(JAR_MANIFEST_FILE) $@ \
+   $(JSSE_CLASSES_DIRS) $(BOOT_JAR_JFLAGS)
+   @$(CD) $(CLASSBINDIR) && $(java-vm-cleanup)

 # Create sec-bin.zip
 SEC_FILES_ZIP=$(ABS_TEMPDIR)/sec-bin.zip
@@ -712,15 +709,12 @@

 # Create rt.jar
 RT_JAR=$(ABS_TEMPDIR)/rt-orig.jar
-RT_JAR_ARGLIST=$(RT_JAR_FILELIST)_args
-$(RT_JAR_ARGLIST): $(RT_JAR_FILELIST)
+$(RT_JAR): $(RT_JAR_FILELIST) $(JAR_MANIFEST_FILE)
$(prep-target)
-   $(SED) -e "s...@^@-C $(CLASSBINDIR) @" $< > $@
-$(RT_JAR): $(RT_JAR_ARGLIST) $(JAR_MANIFEST_FILE)
-   $(prep-target)
-   $(BOOT_JAR_CMD) c0mf $(JAR_MANIFEST_FILE) $@ \
-   @$(RT_JAR_ARGLIST) $(BOOT_JAR_JFLAGS)
-   @$(java-vm-cleanup)
+   $(CD) $(CLASSBINDIR) && \
+   $(BOOT_JAR_CMD) c0mf $(JAR_MANIFEST_FILE) $@ \
+   @$(RT_JAR_FILELIST) $(BOOT_JAR_JFLAGS)
+   @$(CD) $(CLASSBINDIR) && $(java-vm-cleanup)

 # Meta-index construction to make core class loaders lazier

@@ -943,10 +937,10 @@
@#
@# lib/tools.jar
@#
-   $(BOOT_JAR_CMD) c0f $(LIBDIR)/tools.jar $(addprefix \
-   -C $(CLASSBINDIR) , $(TOOLS)) \
-   $(BOOT_JAR_JFLAGS)
-   @$(java-vm-cleanup)
+   $(CD) $(CLASSBINDIR) && \
+   $(BOOT_JAR_CMD) c0f $(ABS_LIBDIR)/tools.jar \
+   $(TOOLS) $(BOOT_JAR_JFLAGS)
+   @$(CD) $(CLASSBINDIR) && $(java-vm-cleanup)
$(CP) $(LIBDIR)/tools.jar $(JDK_IMAGE_DIR)/lib/tools.jar
@#
@# lib/ct.sym
(marti...@suttles) ~/ws/logging $ cat .hg/patches/dashJ
diff --git a/make/common/Release.gmk b/make/common/Release.gmk
--- a/make/common/Release.gmk
+++ b/make/common/Release.gmk
@@ -94,7 +94,7 @@
   ifeq ($(PLATFORM), windows)
 LICENSE_DOCLIST_JDK = $(subst $(LICENSE_VERSION),,\
   $(shell $(CD) $(SHARE_JDK_DOC_SRC) && \
-  $(LS) *LICENSE*$(LICENSE_VERSION)))
+  $(LS) *LICENSE*$(LICENSE_VERSION)))
 LICENSE_DOCLIST_JRE = $(subst $(LICENSE_VERSION),,\
   $(shell $(CD) $(SHARE_JRE_DOC_SRC) && \
   $(LS) *LICENSE*$(LICENSE_VERSION)))
@@ -399,7 +399,7 @@
sun/tools/jstack\
sun/tools/jinfo \
sun/tools/jmap
-   
+
 # classes that go into jsse.jar
 JSSE_CLASSES_DIRS = \
sun/security/provider/Sun.class \
@@ -644,7 +644,7 @@
@$(java-vm-cleanup)

 # Create the manifest file.
-JAR_MANIFEST_FILE=$(TEMPDIR)/manifest.tmp
+JAR_MANIFEST_FILE=$(ABS_TEMPDIR)/manifest.tmp
 $(JAR_MANIFEST_FILE): $(MAINMANIFEST) $(BEANMANIFEST)
$(prep-target)
$(SED) -e "s/@@RELEASE@@/$(RELEASE)/" $(MAINMANIFEST) >> $@
@@ -652,25 +652,22 @@
$(CAT) $(BEANMANIFEST) >> $@

 # Create resources.jar containing non-class files
-RESOURCES_JAR=$(TEMPDIR)/resources-orig.jar
-RES_JAR_ARGL

Re: hg: jdk7/build/langtools: 6829575: 100028: Debug information is incomplete or missing

[Martin Buchholz]

On Mon, Apr 20, 2009 at 02:06, Andrew Haley  wrote:
> Jonathan Gibbons wrote:
>> Andrew.
>>
>> Earlier this week, Mark announced that Release Team approval was required
>> for the final M3 builds for JDK7. [1]
>
> Glad I asked.
>
>> Even without that, jcheck would require that you have another BugTraq CR
>> for this issue, even though it is just a modification of a recent fix. I
>> didn't see
>> a new CR get created yet; is that right?
>
> https://bugs.openjdk.java.net/show_bug.cgi?id=100045

I believe that openjdk infrastructure has not yet advanced to the point
where it can use bugzilla bugs for commits.  All of my own commits
have had actual bugs.sun.com bugs filed on my behalf.

Martin

> Andrew.
>

Re: New project: getting rid of IcedTea local patches

[Martin Buchholz]

On Sat, Apr 18, 2009 at 02:50, Andrew Haley  wrote:
> Martin Buchholz wrote:
> Well, maintaining this "buffer" forest is, more or less, what IcedTea does.
> I'm not sure that we need another one.

I wasn't suggesting we start a new buffer forest.
I was suggesting we (Google + IcedTea)
consider sharing the forest at  http://openjdk.java.net/projects/icedtea/.
even though Google's patches didn't originate in IcedTea proper.

Martin

Re: New project: getting rid of IcedTea local patches

[Martin Buchholz]

On Thu, Apr 9, 2009 at 06:14, Andrew Haley  wrote:
> Andrew Haley wrote:
>> We at Red Hat have noticed that the list of IcedTea local patches has
>> been getting large, with some local patches that should have been
>> pushed upstream.  Also, some IcedTea patches have been committed to
>> OpenJDK 7 but not OpenJDK 6.
>>
>> So, we're going to have a serious attempt to minimize the number of
>> IcedTea patches.  We'll create a Wiki page at icedtea.classpath.org
>> that is a list of the patches, and for every one we're going to
>> discuss whether it should stay IcedTea local, be pushed upstream to
>> OpenJDK, or be deleted altogether.  Then we will create OpenJDK
>> bugzilla entries for the patches that we think should be integrated
>> upstream and work with Sun engineers to get that done.
>
> The page is at http://icedtea.classpath.org/wiki/IcedTea_JDK6_Patches
> These are the patches in icedtea/patches and icedtea/patches/hotspot.

IcedTea folk and especially Andrew, thank you very much for this effort.

Here at Google, we also have some local patches and we have a similar
effort to push changes upstream.  It is probably a common experience
that patches are developed in a hurry to meet some release date,
and the upstream push effort is deferred to post-release.  This may result
in a delay before the rest of the openjdk community shares the patch,
but has the advantage that the patch is much more likely to be correct,
since it will already have had real users.

It occurs to me that there is a new reason to maintain a "buffer" forest
that contains patches on their way into Sun's master forest, namely
the periodic stabilization for jdk7 milestone releases.  It may make sense
for Google (i.e. me) to push changes
into the icedtea upstream-directed forest
if openjdk forests are in quiescent mode.

Martin

Re: jdk-repo-only-build broken in openjdk6

[Martin Buchholz]

On Mon, Apr 6, 2009 at 14:33, Tim Bell  wrote:
> Hi Martin:
>
> Bug ID: 6668260 build in openjdk/jdk/make fails if openjdk/build exists
> Bug ID: 6668018 Incremental/partial OpenJDK builds from jdk/make
> subdirectories do not always work
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6668260
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6668018
>
> Did you previously do a control build at the top level?

Ah yes indeed - good clue!

 If so, another
> workaround is to rename that output directory.  In your case, that would be:
>  mv /usr/local/google/home/martin/ws/openjdk6/build \
>     /usr/local/google/home/martin/ws/openjdk6/build.ignore

I think my JDK_TOPDIR workaround is another clue,
that should be added to the bug report.

Since it appears that this bug is also in openjdk7,
I would make it a P2, just because of the extreme frustration
developers are likely to encounter.

The Makefiles could simply make JDK_TOPDIR absolute,
but that has the problem that FullPath is defined in a Makefile
included using a path that uses JDK_TOPDIR.

Martin

>
> HTH - Tim
>
>
>> It's not obvious why a full control build doesn't encounter this issue.
>> After much frustrating debugging, I found that it's due to the control
>> build
>> passing an absolute JDK_TOPDIR to the jdk repo sub-build.
>>
>> So I have a fine workaround.  Define JDK_TOPDIR to the absolute path
>> of the jdk directory.  I still don't know where in the makefiles is a
>> dependency on JDK_TOPDIR not being relative.  The smartcardio Makefile
>> appears to be blameless.  This would be a P2 bug to fix,
>> were it not for the fact that openjdk6 does not see a lot of development.
>>
>> Here's a snippet of perl I use in my build script:
>>
>> {
>>  # Work around bug in openjdk6, that requires an absolute JDK_TOPDIR
>>  use Cwd 'getcwd';
>>  my $dir = getcwd();
>>  while ($dir ne '') {
>>    sub isJdkDir($) { -r "$_[0]/make/common/Program.gmk" }
>>    last if isJdkDir "$dir/jdk";
>>    if (isJdkDir $dir) {
>>      $ENV{JDK_TOPDIR} = $dir;
>>      print "JDK_TOPDIR=$dir\n" if $verbose;
>>      last;
>>    }
>>    $dir =~ s~/[^/]*$~~;
>>  }
>> }
>>
>> Hope this helps.
>>
>> Martin
>
>

jdk-repo-only-build broken in openjdk6

[Martin Buchholz]

Hi build experts,

I tried building just the openjdk6 jdk repo in (more or less) the usual way
using 'cd jdk/make && make...'

This works in openjdk7 but fails in openjdk6 (and has failed for quite a while)


>>>Recursively making smartcardio all @ Sun Apr  5 16:04:57 PDT 2009 ...
make[3]: Entering directory
`/usr/local/google/home/martin/ws/openjdk6/jdk/make/sun/security/smartcardio'
/bin/mkdir -p 
../../../../build/linux-i586/tmp/sun/sun.security.smartcardio/j2pcsc/obj_g
rm -f 
../../../../build/linux-i586/tmp/sun/sun.security.smartcardio/j2pcsc/obj_g/.class.headers.i586
# Running javah:
/usr/local/google/SLASH_JAVA/re/openjdk/6/promoted/latest/binaries/linux-i586/bin/javah
-bootclasspath ../../../../build/linux-i586/classes -d
../../../../build/linux-i586/tmp/sun/sun.security.smartcardio/j2pcsc/CClassHeaders/
\
sun.security.smartcardio.PCSC 
sun.security.smartcardio.PlatformPCSC
error: cannot access sun.security.smartcardio.PCSC
class file for sun.security.smartcardio.PCSC not found
javadoc: error - Class sun.security.smartcardio.PCSC not found.
error: cannot access sun.security.smartcardio.PlatformPCSC
class file for sun.security.smartcardio.PlatformPCSC not found
javadoc: error - Class sun.security.smartcardio.PlatformPCSC not found.
Error: No classes were specified on the command line.  Try -help.
make[3]: *** 
[../../../../build/linux-i586/tmp/sun/sun.security.smartcardio/j2pcsc/obj_g/.class.headers.i586]
Error 15
make[3]: Leaving directory
`/usr/local/google/home/martin/ws/openjdk6/jdk/make/sun/security/smartcardio'
make[2]: *** [all] Error 1
make[2]: Leaving directory
`/usr/local/google/home/martin/ws/openjdk6/jdk/make/sun/security'
make[1]: *** [all] Error 1
make[1]: Leaving directory
`/usr/local/google/home/martin/ws/openjdk6/jdk/make/sun'
make: *** [all] Error 1
Command /usr/bin/nice /usr/bin/linux32 make SHELL=/bin/bash
VARIANT=DBG sanity all docs images failed: rc=2


It's not obvious why a full control build doesn't encounter this issue.
After much frustrating debugging, I found that it's due to the control build
passing an absolute JDK_TOPDIR to the jdk repo sub-build.

So I have a fine workaround.  Define JDK_TOPDIR to the absolute path
of the jdk directory.  I still don't know where in the makefiles is a
dependency on JDK_TOPDIR not being relative.  The smartcardio Makefile
appears to be blameless.  This would be a P2 bug to fix,
were it not for the fact that openjdk6 does not see a lot of development.

Here's a snippet of perl I use in my build script:

{
  # Work around bug in openjdk6, that requires an absolute JDK_TOPDIR
  use Cwd 'getcwd';
  my $dir = getcwd();
  while ($dir ne '') {
sub isJdkDir($) { -r "$_[0]/make/common/Program.gmk" }
last if isJdkDir "$dir/jdk";
if (isJdkDir $dir) {
  $ENV{JDK_TOPDIR} = $dir;
  print "JDK_TOPDIR=$dir\n" if $verbose;
  last;
}
$dir =~ s~/[^/]*$~~;
  }
}

Hope this helps.

Martin

Re: Binary blobs for older trees?

[Martin Buchholz]

The jdk7 builds at
http://download.java.net/jdk7/archive/
are for the non-open-source jdk7.

The binary plugs for recent openjdk7 builds
are available in non-obvious places like

http://download.java.net/openjdk/jdk7/promoted/b45/

but b45 is the oldest available build.

I would like to see all of the historically downloadable bits
to remain available.  Current JDK sources for builds back to
b20 or so are available via mercurial, but there's no way to
build them properly without the binary plugs.

Martin

On Wed, Mar 4, 2009 at 09:19, Phil Race  wrote:
> There's an archive here :
> http://download.java.net/jdk7/archive/
>
> Its linked via
> http://openjdk.java.net/ ->
> http://download.java.net/openjdk/jdk7/ ->
> http://download.java.net/jdk7/binaries/ ->
>
> Also we should sync the 2D repo
>
> -phil.
>
> Roman Kennke wrote:
>>
>> Hi,
>>
>> I'm trying to build the 2d-tree, but it fails because it's missing some
>> jsound library. I recently updated my version of the binary blobs for a
>> plain openjdk7 build, but it seems like the 2d-tree still requires an
>> older version. Are older versions of the blobs available somewhere? I
>> think it would be very useful, not only because some group trees lag
>> behind, but also when somebody wants to build an older version of a
>> current tree. (Ideally, I'd think the build system should offer to fetch
>> a matching blob via ant's get-tag or wget...)
>>
>> /Roman
>>
>

Re: Heads Up: JDK 7 Linux platforms moving to Fedora 9

[Martin Buchholz]

On Fri, Dec 19, 2008 at 11:39, Kelly O'Hair  wrote:
> So what we need to do is figure out if there is a way to build
> on Fedora9 that allows the product to work better on other systems,
> or if we need to change to something other than Fedora9.
>
> Constructive suggestions are welcome.

I suggest not trying to use Fedora9 for release engineering builds.
Let individual developers use Fedora, if they wish.

Use one of the stable supported releases (or their clones) that
include glibc 2.3.  Either RHEL 4 or Ubuntu dapper would qualify.

Martin

Re: Heads Up: JDK 7 Linux platforms moving to Fedora 9

[Martin Buchholz]

On Fri, Dec 19, 2008 at 10:27, Andrew Haley  wrote:
> As an example of the cost of building on old boxes, OpenJDK contains
> prototypes for epoll(7) that are incorrect for some arches.  These

We are changing the subject slightly from portability of binaries
to portability of sources.

> prototypes exist because epoll didn't come into existence before
> Kernel 2.6(ish), and OpenJDK was being built on an old box, so the
> prototypes were copied from the kernel headers on (I think) an x86
> box.  This bug causes bizarre and hard to debug behaviour on non-x86
> arches.
>
> At some point you have to get rid of cruft like this.  If not now,
> when?

Obviously opinions differ on how long to support older platforms.

"Kids these days..." think 2 years is old.

When I was maintaining an open source project,
I tried to maintain a portability horizon of at least 10 years.
Seriously.  I would like people to be able to build my
software on that old Irix machine they picked up at a
garage sale.

For problems like changing prototypes, we have configure.

Sure the following example is ugly cruft,
but we can wait one more decade before nuking it.

dnl If `getpgrp' takes no argument (the POSIX.1 version), define
dnl `GETPGRP_VOID'.  Otherwise, it is the BSD version, which takes a
dnl process ID as an argument.
AC_CHECK_FUNCS(getpgrp)
AC_FUNC_GETPGRP

Martin

Re: Heads Up: JDK 7 Linux platforms moving to Fedora 9

[Martin Buchholz]

Hi Mark,

On Fri, Dec 19, 2008 at 09:53, Mark Wielaard  wrote:
> To be honest I think it will be easier to get the distros to do this for
> us. They are much better at it and it saves you from endless discussion
> of which architectures, platforms, compilers, libraries, configure/build
> options, etc need to be supported.

There's the old debate over the "one true binary" vs.
a set of binaries optimized for every particular platform.
Each has their advantages.

> Still, if they were around I would indeed take a look and compare stuff
> a bit with my local builds if I had any strange test failures for
> example.
>
> Fedora 9 binaries would be fine for me, I am on Fedora 10 already :)
> Although my servers are a mix of Debian stable and CentOS 5.
>
>> > But how would be tag these builds as "official"?
>>
>> I'm not sure I understand the question.
>> Here "official" means there's been some release engineering love
>> and an expectation of a minimal level of quality.

Let me expand on that a little.
Every "build" coming from Sun has already had
a significant amount of testing applied to it.
For comparative testing, I would like to try the very same binaries
that Sun must have already created.

Martin

Re: Heads Up: JDK 7 Linux platforms moving to Fedora 9

[Martin Buchholz]

On Fri, Dec 19, 2008 at 03:39, Andrew Haley  wrote:
> Does this failure to run on Ubuntu dapper have anything to do with
> Fedora 9?

Since it appears to have been caused by building on Fedora 9,
the answer is very likely "yes".

In particular, Fedora 9 very likely has a glibc version > 2.3,
and apps built on such a system tend to have linker
dependencies on symbols introduced in glibc 2.4,
causing
libc.so.6: version `GLIBC_2.4' not found
load-time errors.

I also suspect compiler runtime incompatibilities.

(I've never used Fedora, and I'm not suggesting there's anything
wrong with Fedora 9, aside from being too new.)

Martin

Re: Heads Up: JDK 7 Linux platforms moving to Fedora 9

[Martin Buchholz]

On Fri, Dec 19, 2008 at 01:57, Mark Wielaard  wrote:
> Are there any "official" GPL binaries for OpenJDK these days?

No, but I encourage Sun and encourage others to encourage Sun
to provide those, at least for Linux where there is a community that cares.

> If there
> are it would be interesting to use these for testing against distro
> produced binaries.

That is the primary purpose for me - comparative testing.
(For the same reason, "proprietary" JDK builds are also valuable
for open source developers)

> But how would be tag these builds as "official"?

I'm not sure I understand the question.
Here "official" means there's been some release engineering love
and an expectation of a minimal level of quality.

Martin

Re: Heads Up: JDK 7 Linux platforms moving to Fedora 9

[Martin Buchholz]

build 42 has come, and the JDK binaries no longer work on my
system (32-bit Ubuntu dapper).  java -version gives
an instant crash with "floating point exception".
Not very friendly.

I have always liked the fact that in the past Sun's JDK engineers
put in great effort to ensure that JDK binaries work on
a large variety of systems, generally by being built on
some old unloved machine in the closet.

I believe using Fedora 9 for official binaries is
excessively aggressive.
Like the JDK itself, operating systems (like Ubuntu
"Long Term Support") tend to have about a
5-year support lifespan.  Fedora 9 is just too young.

I suggest using a build machine that, like Ubuntu dapper,
has a glibc 2.3, which was the first release with NPTL.
More specifically, I recommend glibc 2.3.6.

Or more generally, try to support popular platforms
for at least 5 years of life.

Martin

On Wed, Oct 29, 2008 at 20:31, Xiomara Jayasena
 wrote:
>
> Hi,
>
> The official Release Engineering builds for JDK 7 will be moving from the
> following OSs:
>
> *32 bit builds*
> ==
> *From: *RH AS 2.1 to Fedora 9
>
> *64 bit builds*
> ==
> *From: *SUSE 8 to: Fedora 9
>
> All required Makefile changes are in place, there are still  other items
> that are still being investigated for this OS upgrade to happen but wanted
> to inform of the changes that are on the way.
> *When:*  It is expected that this change will happen by build 42.
>
> Please let me know if there are any questions.
>
> Thanks,
> -Xiomara
>
>

Re: OpenJDK 6 build 14 source posted

[Martin Buchholz]

On Wed, Dec 3, 2008 at 11:38, Joe Darcy <[EMAIL PROTECTED]> wrote:
> The source bundle for OpenJDK 6 build 14 is available for download from:
>
>http://download.java.net/openjdk/jdk6/

The new Hotspot 11 failed to compile on a modified 64-bit (debian arch=amd64)
Ubuntu dapper system as follows:

cc1plus: warnings being treated as errors
/usr/local/google/home/martin/ws/buildAllOpenJDK6/hotspot/src/share/vm/utilities/ostream.cpp:
In member function 'bool networkStream::connect(const char*, short
int)':
/usr/local/google/home/martin/ws/buildAllOpenJDK6/hotspot/src/share/vm/utilities/ostream.cpp:835:
warning: comparison is always false due to limited range of data type

32-bit systems are unaffected (not sure why).

gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5)

Running make with WARNINGS_ARE_ERRORS="" as previously advertised,
appears to be the workaround.

Martin

build readme typo fix

[Martin Buchholz]

diff --git a/README-builds.html b/README-builds.html
--- a/README-builds.html
+++ b/README-builds.html
@@ -1429,7 +1429,7 @@
 build output is to go.
 The default output directory will be build/platform.
 
-ALT_SLASHJAVA
+ALT_SLASH_JAVA
 
 The default root location for many of the ALT
path locations
 of the following ALT variables.

Re: splashscreen.so is missing pnggccrd.c

[Martin Buchholz]

Hi Artem and Anthony,

To understand this problem, please examine the snippet in pngconf.h

#  if !defined(PNG_MMX_CODE_SUPPORTED) && !defined(PNG_NO_MMX_CODE) && \
 defined(__MMX__)
#define PNG_MMX_CODE_SUPPORTED
#  endif

The macro __MMX__ is defined if the gcc is configured to have mmx
support on by default.  You can reproduce the problem probably
most easily by modifying the makefiles to add the flag
"-mmmx" to the C compiler flags.

I believe this issue has existed for a while,
dependent on the way that gcc was configured.

Another way to examine the problem is to
look at the link error, failure to find png_combine_row,
and trace where this function is defined and how
it might be called.  The version of this function in
pngrutil.c is only defined if there is _no_ mmx support.

Martin

On Mon, Sep 1, 2008 at 07:02, Artem Ananiev <[EMAIL PROTECTED]> wrote:
>
> Martin Buchholz wrote:
>>
>> On Fri, Aug 29, 2008 at 3:37 AM, Anthony Petrov <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> On 08/28/2008 08:33 PM Martin Buchholz wrote:
>>>>
>>>> I'm thinking:
>>>> - the MMX support is in pnggccrd.c,
>>>> - but that file is never compiled in OpenJDK
>
> Quick grep for PNG_MMX_CODE_SUPPORTED shows two .h files and six .c files in
> src/share/native/sun/awt/libpng directory, pnggccrd.c is only one of them,
> but what about others?
>
> Thanks,
>
> Artem
>
>>> Why? There's the following line in the make/sun/splashscreen/Makefile:
>>>
>>> vpath %.c   $(SHARE_SRC)/native/$(PKGDIR)/libpng
>>>
>>> that effectively includes all *.c files in the libpng sources directory
>>> (src/share/native/sun/awt/libpng/) in the compilation process.
>>
>> Anthony,
>>
>> I believe this is a small misunderstanding of how vpath works.
>> vpath changes the _search path_ for files, but does not affect which
>> files are actually compiled.   That is defined in
>> make/sun/splashscreen/FILES_c.gmk
>> and pnggccrd.c is notably absent from that file.
>> If you actually try a clean build, on any platform,
>> you will see no references to pnggccrd (or pngvcrd)
>> in the logs (prove me wrong!).
>>
>> Martin
>

Re: splashscreen.so is missing pnggccrd.c

[Martin Buchholz]

On Fri, Aug 29, 2008 at 3:37 AM, Anthony Petrov <[EMAIL PROTECTED]> wrote:
> On 08/28/2008 08:33 PM Martin Buchholz wrote:
>>
>> I'm thinking:
>> - the MMX support is in pnggccrd.c,
>> - but that file is never compiled in OpenJDK
>
> Why? There's the following line in the make/sun/splashscreen/Makefile:
>
> vpath %.c   $(SHARE_SRC)/native/$(PKGDIR)/libpng
>
> that effectively includes all *.c files in the libpng sources directory
> (src/share/native/sun/awt/libpng/) in the compilation process.

Anthony,

I believe this is a small misunderstanding of how vpath works.
vpath changes the _search path_ for files, but does not affect which
files are actually compiled.   That is defined in
make/sun/splashscreen/FILES_c.gmk
and pnggccrd.c is notably absent from that file.
If you actually try a clean build, on any platform,
you will see no references to pnggccrd (or pngvcrd)
in the logs (prove me wrong!).

Martin

Re: splashscreen.so is missing pnggccrd.c

[Martin Buchholz]

Hi Anthony,

On Fri, Aug 29, 2008 at 3:30 AM, Anthony Petrov <[EMAIL PROTECTED]> wrote:
> Hi Martin,
>
> The AWT folks think we need to guard this CPPFLAGS setting with the
> following condition:
>
> ifneq ($(PLATFORM), windows)
> ...
> endif

I am certain this would "work" for everyone, but ...
I am a perfectionist and I am also quite certain that it is wrong.
But if you insist, it's OK.

> We don't use gcc on Windows, and everything works just fine with MS VS.

"We" are now a community of folks with different platforms in mind.
People will want to use gcc on Windows.

> Please feel free to submit the patch with this change, and please add
> OpenJDK user 'art' to the reviewers list. Given this modification applied,
> I'm approving the fix. The push is going to be performed by Artem (CC'ed).
> Thanks in advance!

Again, sorry to be contrary, but I am an OpenJDK committer,
and I would prefer to do hg pushes myself,
for "community development" reasons.
I propose to push these changes to jdk7/awt-gate/jdk

It appears that currently every changeset needs a unique bugid,
so a new bug would have to be filed.  Anthony, could you take care of this?

Thanks,

Martin

Can't use single bugid for multiple changesets

[Martin Buchholz]

Hi Mark,

I'm trying to commit my fixes for a particular bug,
and I went to the trouble of cleanly separating my changes
into 3 changesets, but when I try to do the push, I get:

pushing to ssh://[EMAIL PROTECTED]/jdk7/tl-gate/jdk/
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 4 changesets with 12 changes to 8 files
remote:
remote: > Changeset: 512:6d8ae1098ca5
remote: > Author:martin
remote: > Date:  2008-08-28 21:49 -0700
remote: >
remote: > 6728229: (str) StringBuilder.append(CharSequence) does not
throw IndexOutOfBoundsException
remote: > Summary: Add missing @throws IndexOutOfBoundsException
remote: > Reviewed-by: alanb
remote:
remote: Bugid 6728229 already used in this repository, in revision 511
remote:
remote: > Changeset: 513:ba510454713a
remote: > Author:martin
remote: > Date:  2008-08-28 21:49 -0700
remote: >
remote: > 6728229: (str) StringBuilder.append(CharSequence) does not
throw IndexOutOfBoundsException
remote: > Summary: Minor spec improvements
remote: > Reviewed-by: alanb
remote:
remote: Bugid 6728229 already used in this repository, in revision 511
remote:
remote: abort: pretxnchangegroup.0.jcheck hook failed

This seems pretty draconian.  Especially while external committers
can't yet create their own bugs directly.

Aren't there "cleanup bugs" that are used for occasional repeated
minor changes?  Using them seems impossible with the jcheck hook.

What do I do now?

Thanks,

Martin

Re: splashscreen.so is missing pnggccrd.c

[Martin Buchholz]

Hi Anthony,

I investigated yet a bit more, and finally am sure about the underlying cause:
Standard gcc does not define __MMX__, but ours does,
perhaps because it has been configured to make MMX support the default.

$ gcc -E -dM main.c | grep __MMX__
$ /usr/local/google/fauxJDKCompiler/gcc -E -dM main.c | grep __MMX__
#define __MMX__ 1

By default, pngconf.h uses mmx instructions if __MMX__ is defined.
But this can be disabled by -DPNG_NO_MMX_CODE.

Since the existing code in OpenJDK depends on MMX not being used
(since pnggccrd.c is never compiled) -DPNG_NO_MMX_CODE should
be added to CPPFLAGS in the splashscreen makefile unconditionally.

Requesting permission to push...

You could file a new bug, or we could reuse 6613927, at your option.

Martin

# HG changeset patch
# User martin
# Date 1219960566 25200
# Node ID 198b5e82cd0fa4b42cafabce3e763e2a2cb3888c
# Parent  1267605489211c6c162bb246f653759e933bd06e
6613927: Compilation of splashscreen png library failed on Ubuntu 7.04 (64bit)
Summary: Define -DPNG_NO_MMX_CODE unconditionally, not just on 64-bit Linux
Reviewed-by: anthony

diff --git a/make/sun/splashscreen/Makefile b/make/sun/splashscreen/Makefile
--- a/make/sun/splashscreen/Makefile
+++ b/make/sun/splashscreen/Makefile
@@ -85,13 +85,6 @@
 CPPFLAGS += -I$(PLATFORM_SRC)/native/$(PKGDIR)/splashscreen
-I$(SHARE_SRC)/native/$(PKGDIR)/splashscreen
 CPPFLAGS += -I$(SHARE_SRC)/native/$(PKGDIR)/image/jpeg
-I$(SHARE_SRC)/native/java/util/zip/zlib-1.1.3

-ifeq ($(PLATFORM), linux)
-  ifeq ($(ARCH_DATA_MODEL), 64)
-# 64-bit gcc has problems compiling MMX instructions.
-# Google it for more details. Possibly the newer versions of
-# the PNG-library and/or the new compiler will not need this
-# option in the future.
-CPPFLAGS += -DPNG_NO_MMX_CODE
-  endif
-endif
-
+# Shun the less than portable MMX assembly code in pnggccrd.c,
+# and use alternative implementations in C.
+CPPFLAGS += -DPNG_NO_MMX_CODE

On Thu, Aug 28, 2008 at 9:33 AM, Martin Buchholz <[EMAIL PROTECTED]> wrote:
> I'm thinking:
> - the MMX support is in pnggccrd.c,
> - but that file is never compiled in OpenJDK
> - so... how could png ever work when PNG_NO_MMX_CODE is not defined,
>  on any platform?
>
> I am suspicious that png splashscreens are actually broken
> without my proposed patch.  Has this actually been tested?
>
> I googled a little and have a theory.
> "-z defs" is supposed to be ignored for shared libs
> (but why are we using it to build libsplashscreen.so?)
> but very recent gcc toolchains don't ignore it the way they
> perhaps should.
>
> E.g. Here's a debian bug report
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489142
> On hppa -Wl,-z,defs is not ignored for shared libraries
>
> But using "-z defs" is actually good engineering practice,
> since it catches problems at link time instead of run time.
> Whether or not it's a bug in my toolchain, my toolchain
> detects the unsatisfied symbols in the link.
> There's a good chance that my change will be necessary
> to build OpenJDK on future stock Linux systems.
>
> Martin
>
>
> On Thu, Aug 28, 2008 at 3:11 AM, Anthony Petrov <[EMAIL PROTECTED]> wrote:
>> Hello Martin,
>>
>> Thank you for the patch. Though there's a little concern: how does the bare
>> libpng deal with this issue when compiled using the toolchain you use? I
>> mean, the problem is not reproducible when compiling on a "regular" 32-bit
>> system, so it might be important to identify the root cause of this issue.
>> Could you please take a look at the libpng source (the version that was
>> forked for the purposes of OpenJDK is 1.2.18) and try compiling it with your
>> tools (by the way, what are they?)? If this is the problem with this
>> particular version of libpng, and newer versions do not experience this
>> problem, then this might be probably a justification for updating our
>> version of libpng rather than disabling the usage of MMX for all platforms.
>> What do you think?
>>
>> --
>> best regards,
>> Anthony
>>
>>
>> On 08/28/2008 02:23 AM Martin Buchholz wrote:
>>>
>>> Anthony,
>>>
>>> Thanks for your patience; you were entirely right,
>>> it was indeed necessary to define PNG_NO_MMX_CODE.
>>> Since pnggccrd.c is never compiled, and it contains the MMX code,
>>> the only correct thing appears to be to define this macro unconditionally.
>>> The obvious patch follows (tested on 32-bit Ubuntu Linux with
>>> very recent gcc toolchain)
>>>
>>> (Has anyone actually tested png splashscreen images on 32 or 64-bit
>>> Linux?)
>>>
>>> # HG changeset patch
>>> # User martin
>&

Re: splashscreen.so is missing pnggccrd.c

[Martin Buchholz]

In its current form, the icedtea-libraries.patch
would probably be rejected by Sun, because it
unconditionally changes to using the system libraries.
Instead it should be an option.

Also, it appears that the changes introduce a
run-time dependency on libpng that wasn't there before.
This is fine for building packages as part of a Linux distro
that manages such dependencies, but is unacceptable
in other environments.

A quick look at the changes suggests
they are insufficiently portable (i.e. a quick hack):
e.g.
+void *handle = dlopen("libjpeg.so.62", RTLD_LAZY | RTLD_GLOBAL);

Martin

On Thu, Aug 28, 2008 at 1:51 AM, Mark Wielaard <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Wed, 2008-08-27 at 15:34 -0700, Martin Buchholz wrote:
>> Adding options to use the system versions of these graphics libraries
>> is integrated into IcedTea already.  IcedTea and Sun AWT engineers
>> should work together to put such changes into OpenJDK7.
>
> Yes, this would be great so we don't have to maintain so many extra
> external patches. The patch to do this in icedtea6 is at:
> http://icedtea.classpath.org/hg/icedtea6/file/tip/patches/icedtea-libraries.patch
> That makes sure the system versions of the png, jpeg and zlib libraries
> are used.
>
> Cheers,
>
> Mark
>
>

Re: splashscreen.so is missing pnggccrd.c

[Martin Buchholz]

I'm thinking:
- the MMX support is in pnggccrd.c,
- but that file is never compiled in OpenJDK
- so... how could png ever work when PNG_NO_MMX_CODE is not defined,
  on any platform?

I am suspicious that png splashscreens are actually broken
without my proposed patch.  Has this actually been tested?

I googled a little and have a theory.
"-z defs" is supposed to be ignored for shared libs
(but why are we using it to build libsplashscreen.so?)
but very recent gcc toolchains don't ignore it the way they
perhaps should.

E.g. Here's a debian bug report
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489142
On hppa -Wl,-z,defs is not ignored for shared libraries

But using "-z defs" is actually good engineering practice,
since it catches problems at link time instead of run time.
Whether or not it's a bug in my toolchain, my toolchain
detects the unsatisfied symbols in the link.
There's a good chance that my change will be necessary
to build OpenJDK on future stock Linux systems.

Martin


On Thu, Aug 28, 2008 at 3:11 AM, Anthony Petrov <[EMAIL PROTECTED]> wrote:
> Hello Martin,
>
> Thank you for the patch. Though there's a little concern: how does the bare
> libpng deal with this issue when compiled using the toolchain you use? I
> mean, the problem is not reproducible when compiling on a "regular" 32-bit
> system, so it might be important to identify the root cause of this issue.
> Could you please take a look at the libpng source (the version that was
> forked for the purposes of OpenJDK is 1.2.18) and try compiling it with your
> tools (by the way, what are they?)? If this is the problem with this
> particular version of libpng, and newer versions do not experience this
> problem, then this might be probably a justification for updating our
> version of libpng rather than disabling the usage of MMX for all platforms.
> What do you think?
>
> --
> best regards,
> Anthony
>
>
> On 08/28/2008 02:23 AM Martin Buchholz wrote:
>>
>> Anthony,
>>
>> Thanks for your patience; you were entirely right,
>> it was indeed necessary to define PNG_NO_MMX_CODE.
>> Since pnggccrd.c is never compiled, and it contains the MMX code,
>> the only correct thing appears to be to define this macro unconditionally.
>> The obvious patch follows (tested on 32-bit Ubuntu Linux with
>> very recent gcc toolchain)
>>
>> (Has anyone actually tested png splashscreen images on 32 or 64-bit
>> Linux?)
>>
>> # HG changeset patch
>> # User martin
>> # Date 1219875308 25200
>> # Node ID 86b160e4bc1aae927aa71dfd712bb2365ebc0e1c
>> # Parent  1267605489211c6c162bb246f653759e933bd06e
>> 6613927: Compilation of splashscreen png library failed on Ubuntu 7.04
>> (64bit)
>> Summary: Define -DPNG_NO_MMX_CODE unconditionally, not just on 64-bit
>> Linux
>> Reviewed-by: anthony
>>
>> diff --git a/make/sun/splashscreen/Makefile
>> b/make/sun/splashscreen/Makefile
>> --- a/make/sun/splashscreen/Makefile
>> +++ b/make/sun/splashscreen/Makefile
>> @@ -85,13 +85,6 @@
>>  CPPFLAGS += -I$(PLATFORM_SRC)/native/$(PKGDIR)/splashscreen
>> -I$(SHARE_SRC)/native/$(PKGDIR)/splashscreen
>>  CPPFLAGS += -I$(SHARE_SRC)/native/$(PKGDIR)/image/jpeg
>> -I$(SHARE_SRC)/native/java/util/zip/zlib-1.1.3
>>
>> -ifeq ($(PLATFORM), linux)
>> -  ifeq ($(ARCH_DATA_MODEL), 64)
>> -# 64-bit gcc has problems compiling MMX instructions.
>> -# Google it for more details. Possibly the newer versions of
>> -# the PNG-library and/or the new compiler will not need this
>> -# option in the future.
>> -    CPPFLAGS += -DPNG_NO_MMX_CODE
>> -  endif
>> -endif
>> -
>> +# Shun the less than portable MMX assembly code in pnggccrd.c.
>> +# Newer versions of the PNG-library may not need this option.
>> +CPPFLAGS += -DPNG_NO_MMX_CODE
>>
>> Martin
>>
>> On Wed, Aug 27, 2008 at 5:48 AM, Anthony Petrov <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Hi Martin,
>>>
>>> On 08/25/2008 08:17 PM Martin Buchholz wrote:
>>>>
>>>> Thanks for the link, but...
>>>> - The fix for 6613927 is applied in my workspace
>>>
>>> And it gets activated when building on a 64-bit system only. Could you
>>> please take a look at the make/sun/splashscreen/Makefile file and make
>>> sure
>>> it defines the "CPPFLAGS += -DPNG_NO_MMX_CODE" in every case. It is
>>> really
>>> very interesting if this will resolve the issue. Thank you in advance.
>>
>

Re: make sanity RFE

[Martin Buchholz]

On Wed, Aug 27, 2008 at 3:19 PM, Dalibor Topic <[EMAIL PROTECTED]> wrote:
>
> sudo apt-get build-dep openjdk-6

Wow! __That__'s the command I've been looking for!

Martin

Re: splashscreen.so is missing pnggccrd.c

[Martin Buchholz]

On Wed, Aug 27, 2008 at 5:48 AM, Anthony Petrov <[EMAIL PROTECTED]> wrote:
> This is not an ideal solution. Updating to a new libpng version would be
> fine, however these should be some clean sources (i.e. vanilla libpng source
> tarball, w/o any static <-> const swaps, etc.), and secondly it requires
> some Sun-internal bureaucratic process to put these sources to the OpenJDK
> source tree.

I'm well acquainted with the Sun-internal bureaucratic process.
I encourage the libpng upgrade to happen, but it's not high
enough priority for me to do the work.

> Currently I don't see the suggested change is justified since using the
> standard build environment does not reproduce the problem.

OpenJDK is a community effort, and no longer just a Sun effort.
For us this is a P1 bug, since it is a compilation error in our environment.
If we cannot get a fix for this accepted upstream, we would be forced to fork.

 However, you
> might probably be interested in fixing the following CR:
> http://bugs.sun.com/view_bug.do?bug_id=6565114
> This would eliminate this problem at once and forever. Diego 'Flameeyes'
> Pettenò didn't provide us with a working patch (please see the archives of
> the awt-dev mailing list), hence the CR has been suspended.

Adding options to use the system versions of these graphics libraries
is integrated into IcedTea already.  IcedTea and Sun AWT engineers
should work together to put such changes into OpenJDK7.

Martin

Re: splashscreen.so is missing pnggccrd.c

[Martin Buchholz]

Anthony,

Thanks for your patience; you were entirely right,
it was indeed necessary to define PNG_NO_MMX_CODE.
Since pnggccrd.c is never compiled, and it contains the MMX code,
the only correct thing appears to be to define this macro unconditionally.
The obvious patch follows (tested on 32-bit Ubuntu Linux with
very recent gcc toolchain)

(Has anyone actually tested png splashscreen images on 32 or 64-bit Linux?)

# HG changeset patch
# User martin
# Date 1219875308 25200
# Node ID 86b160e4bc1aae927aa71dfd712bb2365ebc0e1c
# Parent  1267605489211c6c162bb246f653759e933bd06e
6613927: Compilation of splashscreen png library failed on Ubuntu 7.04 (64bit)
Summary: Define -DPNG_NO_MMX_CODE unconditionally, not just on 64-bit Linux
Reviewed-by: anthony

diff --git a/make/sun/splashscreen/Makefile b/make/sun/splashscreen/Makefile
--- a/make/sun/splashscreen/Makefile
+++ b/make/sun/splashscreen/Makefile
@@ -85,13 +85,6 @@
 CPPFLAGS += -I$(PLATFORM_SRC)/native/$(PKGDIR)/splashscreen
-I$(SHARE_SRC)/native/$(PKGDIR)/splashscreen
 CPPFLAGS += -I$(SHARE_SRC)/native/$(PKGDIR)/image/jpeg
-I$(SHARE_SRC)/native/java/util/zip/zlib-1.1.3

-ifeq ($(PLATFORM), linux)
-  ifeq ($(ARCH_DATA_MODEL), 64)
-# 64-bit gcc has problems compiling MMX instructions.
-# Google it for more details. Possibly the newer versions of
-# the PNG-library and/or the new compiler will not need this
-# option in the future.
-CPPFLAGS += -DPNG_NO_MMX_CODE
-  endif
-endif
-
+# Shun the less than portable MMX assembly code in pnggccrd.c.
+# Newer versions of the PNG-library may not need this option.
+CPPFLAGS += -DPNG_NO_MMX_CODE

Martin

On Wed, Aug 27, 2008 at 5:48 AM, Anthony Petrov <[EMAIL PROTECTED]> wrote:
> Hi Martin,
>
> On 08/25/2008 08:17 PM Martin Buchholz wrote:
>>
>> Thanks for the link, but...
>> - The fix for 6613927 is applied in my workspace
>
> And it gets activated when building on a 64-bit system only. Could you
> please take a look at the make/sun/splashscreen/Makefile file and make sure
> it defines the "CPPFLAGS += -DPNG_NO_MMX_CODE" in every case. It is really
> very interesting if this will resolve the issue. Thank you in advance.

Re: make sanity RFE

[Martin Buchholz]

If you're running on Ubuntu, the makefiles could check for the
installed-ness of various build-time dependencies.
The Ubuntu packagers (i.e. doko) must already have such a list.

Martin

On Wed, Aug 27, 2008 at 2:25 PM, Jonathan Gibbons
<[EMAIL PROTECTED]> wrote:
> For the first time, I've been trying a full complete build of OpenJDK
> (full open+closed forest.)
>
> I'm building on Ubuntu, and the build has now failed a second time
> because of a missing command -- or more specifically, a command which
> is not installed by default.  The first command was msgfmt, the latest
> was bb. I do not know if there are more to come.
>
> It would be nice if make sanity had a mechanism for a quick existence
> check for commands that are likely to be required during the build, so
> that missing commands can be detected and reported early, and not
> one at a time at the end of a long build.
>
> -- Jon
>

Re: splashscreen.so is missing pnggccrd.c

[Martin Buchholz]

Hi Anthony,

Thanks for the link, but...
- The fix for 6613927 is applied in my workspace
- The error I'm seeing (and as reported in 6613927)
  is a link error, not a compile or runtime error
- I was seeing the error building in 32-bit mode, as you note.

I don't quite understand, but it seems
to be due to a change in the way
that the GNU toolchain handles unresolved references.

In any case, resolving unresolved references can only be good,
so is there any reason not to apply my patch?
It might even make the fix for 6613927 unnecessary.
The 64-bit-ness of that system may have been a red herring.

Martin

On Mon, Aug 25, 2008 at 3:16 AM, Anthony Petrov <[EMAIL PROTECTED]> wrote:
> Hi Martin,
>
> On 08/24/2008 04:44 AM Martin Buchholz wrote:
>>
>> ../../../build/linux-i586/tmp/sun/sun.awt/splashscreen/obj/png.o: In
>> function `png_init_mmx_flags':
>> png.c:(.text+0xbb): undefined reference to `png_mmx_support'
>
> It looks like another reincarnation of
> http://bugs.sun.com/view_bug.do?bug_id=6613927
> It seems strange the problem arises on a 32-bit system though...
>
> Could you please try using the workaround from this bug to see if it solves
> the issue?
>
> --
> best regards,
> Anthony
>

Re: splashscreen.so is missing pnggccrd.c

[Martin Buchholz]

On Sun, Aug 24, 2008 at 3:55 AM, Andrew Haley <[EMAIL PROTECTED]> wrote:
> What's the point of these changes?
>
>
>> -const static unsigned long long _mask8_0  = 0x0102040810204080LL;

I didn't want to introduce new warnings, and my gcc warned that
static should come at the beginning of a declaration.  so I did

s/const static/static const/g

which seems very safe.

Martin

splashscreen.so is missing pnggccrd.c

[Martin Buchholz]

Hi splashscreen/build maintainers,

I'm using a non-standard gnu toolchain to build OpenJDK7,
and I got errors linking libsplashscreen.so:

../../../build/linux-i586/tmp/sun/sun.awt/splashscreen/obj/png.o: In
function `png_init_mmx_flags':
png.c:(.text+0xbb): undefined reference to `png_mmx_support'

(and many other undefined references)

What's up with that?

The gcc command includes "-z defs", explicitly asking
for an error with unresolved references.
Seems like good software engineering.
I wonder if the behavior of "-z defs" has changed...

Some detective work shows the missing
symbols being defined in pnggccrd.c.
Why isn't that being found?

Ahh, the list of files to be compiled in
make/sun/splashscreen/FILES_c.gmk
is incomplete.  We just need to add in pnggccrd.c

Not so fast.  New compile errors rear their ugly head:

../../../src/share/native/sun/awt/libpng/pnggccrd.c: In function
'png_squelch_warnings':
../../../src/share/native/sun/awt/libpng/pnggccrd.c:390: error:
assignment of read-only variable '_const4'

The ironically named and long suffering function
png_squelch_warnings is trying to assign a read-only variable to itself.
That's not a good idea.

Newer version of libpng have tried to fix png_squelch_warnings,
but have finally squelched png_squelch_warnings itself by
annihilating it from the code base.

Anyways, please:
- review the change below
- file a bug
- let me know which forest to push this into (awt or build?)

BTW, upgrading to the latest libpng probably *is* a good idea.
Also, the icedtea folks simply link against the system libs,
which is a good idea in the context of distro development,
but might not work when trying to produce
"portable binaries".

Thanks,

Martin


# HG changeset patch
# User martin
# Date 1219537969 25200
# Node ID e02349ef40196557bd2561754e51f3c977d1e009
# Parent  af4668faae426222f072827ced8522e9c22ea18a
666: libsplashscreen.so unresolved link-time references
Summary: Compile forgotten source file pnggccrd.c, fix warnings
Reviewed-by:

diff --git a/make/sun/splashscreen/FILES_c.gmk
b/make/sun/splashscreen/FILES_c.gmk
--- a/make/sun/splashscreen/FILES_c.gmk
+++ b/make/sun/splashscreen/FILES_c.gmk
@@ -33,6 +33,7 @@
splashscreen_sys.c \
png.c \
pngerror.c \
+   pnggccrd.c \
pngget.c \
pngmem.c  \
pngpread.c \
diff --git a/src/share/native/sun/awt/libpng/pnggccrd.c
b/src/share/native/sun/awt/libpng/pnggccrd.c
--- a/src/share/native/sun/awt/libpng/pnggccrd.c
+++ b/src/share/native/sun/awt/libpng/pnggccrd.c
@@ -278,9 +278,9 @@
 int PNGAPI png_mmx_support(void);

 #ifdef PNG_USE_LOCAL_ARRAYS
-const static int FARDATA png_pass_start[7] = {0, 4, 0, 2, 0, 1, 0};
-const static int FARDATA png_pass_inc[7]   = {8, 8, 4, 4, 2, 2, 1};
-const static int FARDATA png_pass_width[7] = {8, 4, 4, 2, 2, 1, 1};
+static const int FARDATA png_pass_start[7] = {0, 4, 0, 2, 0, 1, 0};
+static const int FARDATA png_pass_inc[7]   = {8, 8, 4, 4, 2, 2, 1};
+static const int FARDATA png_pass_width[7] = {8, 4, 4, 2, 2, 1, 1};
 #endif

 #if defined(PNG_MMX_CODE_SUPPORTED)
@@ -339,30 +339,30 @@
 static int _unmask;
 #endif

-const static unsigned long long _mask8_0  = 0x0102040810204080LL;
-
-const static unsigned long long _mask16_1 = 0x0101020204040808LL;
-const static unsigned long long _mask16_0 = 0x1010202040408080LL;
-
-const static unsigned long long _mask24_2 = 0x0101010202020404LL;
-const static unsigned long long _mask24_1 = 0x0408080810101020LL;
-const static unsigned long long _mask24_0 = 0x2020404040808080LL;
-
-const static unsigned long long _mask32_3 = 0x0101010102020202LL;
-const static unsigned long long _mask32_2 = 0x0404040408080808LL;
-const static unsigned long long _mask32_1 = 0x1010101020202020LL;
-const static unsigned long long _mask32_0 = 0x4040404080808080LL;
-
-const static unsigned long long _mask48_5 = 0x0101010101010202LL;
-const static unsigned long long _mask48_4 = 0x0202020204040404LL;
-const static unsigned long long _mask48_3 = 0x0404080808080808LL;
-const static unsigned long long _mask48_2 = 0x1010101010102020LL;
-const static unsigned long long _mask48_1 = 0x2020202040404040LL;
-const static unsigned long long _mask48_0 = 0x4040808080808080LL;
-
-const static unsigned long long _const4   = 0x00FFLL;
-//const static unsigned long long _const5 = 0x00FFLL;
// NOT USED
-const static unsigned long long _const6   = 0x00FFLL;
+static const unsigned long long _mask8_0  = 0x0102040810204080LL;
+
+static const unsigned long long _mask16_1 = 0x0101020204040808LL;
+static const unsigned long long _mask16_0 = 0x1010202040408080LL;
+
+static const unsigned long long _mask24_2 = 0x0101010202020404LL;
+static const unsigned long long _mask24_1 = 0x0408080810101020LL;
+static const unsigned long long _mask24_0 = 0x2020404040808080LL;
+
+static const unsigned long long _mask32_3 = 0x0101010102020202LL;
+static const unsigned long long _mask32_2 = 0x0404040408080808LL;
+static const

Re: JRE install bundles for 6u10 are non-executable

[Martin Buchholz]

On Wed, Jul 30, 2008 at 10:42 AM, Kelly O'Hair <[EMAIL PROTECTED]> wrote:
>> If I were still at Sun, I probably would have used
>> Sun's internal bug-tracking system to report such bugs.
>
> The bug with the execute permissions is filed, are you refering
> to another bug?

No.  Probably the ease of searching bugs internally to Sun
would have caused me to find the already filed execute permissions bug,
and I would never have tried to report it.

Martin

Re: JRE install bundles for 6u10 are non-executable

[Martin Buchholz]

Andrew raises a good point.

It's true that Sun does not provide binaries for OpenJDK,
and the code that deploys them is not open source,
but... it would be nice if Sun did provide OpenJDK binaries
(since Sun builds them)
and I would certainly expect the web deployment code
to become open source eventually, even if not technically
a part of OpenJDK.

If I were still at Sun, I probably would have used
Sun's internal bug-tracking system to report such bugs.

Martin

On Wed, Jul 30, 2008 at 4:13 AM, Andrew John Hughes
<[EMAIL PROTECTED]> wrote:
> 2008/7/30 Martin Buchholz <[EMAIL PROTECTED]>:
>> I installed the Linux JREs for 6u10 b28,
>> (using java -jar jre..jar)
>> and was surprised to discover none of the
>> programs (like "bin/java") were executable.
>> I checked earlier 6u10 builds,
>> and they have the same problem.
>> I suspect the jdk7 builds also have this problem.
>>
>> This seems like a P1 deployment bug.
>> Hasn't anyone ever run sanity checks
>> on JREs installed this way?
>>
>> Martin
>>
>
> How is this related to OpenJDK?
> --
> 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
>

Re: JRE install bundles for 6u10 are non-executable

[Martin Buchholz]

On Tue, Jul 29, 2008 at 10:56 PM, Volker Simonis
<[EMAIL PROTECTED]> wrote:
> Hi Martin,
>
> this is a known problem and it it noticed at the top of the download
> page at http://download.java.net/jdk6/ :

> "If you choose to download and install self-extracting JRE or DEBUG
> Jar bundles then you need to change the file permission to be
> executable in the bin directory after the installation."

Thanks.  I missed that.

> I think this is because of a long standing problem which doesn't allow
> the Java zip-classes to create executable files on *nix (i.e. there's
> no standard Java API which allows the manipulation of file access
> permissions on *nix except setting the read-only bit).

Of course, we would like better access to the OS
from Java APIs, and JSR 203 is providing that,
but today there's no reason a Java program can't
simply run /bin/chmod in a subprocess.
It's not like the installer is portable anyways,
with a string like "linux-i586" in its name.

Furthermore, the installer for the JDK actually works!
Why not use the same one for the JRE?

Martin

JRE install bundles for 6u10 are non-executable

[Martin Buchholz]

I installed the Linux JREs for 6u10 b28,
(using java -jar jre..jar)
and was surprised to discover none of the
programs (like "bin/java") were executable.
I checked earlier 6u10 builds,
and they have the same problem.
I suspect the jdk7 builds also have this problem.

This seems like a P1 deployment bug.
Hasn't anyone ever run sanity checks
on JREs installed this way?

Martin

Re: Building on Win 2008

[Martin Buchholz]

Porting OpenJDK to be an actual cygwin program,
rather than just being built using cygwin tools,
is an obvious target for open source porters.
The cygwinized OpenJDK would be available as part of the Cygwin
distribution.  Obviously a porter would have to fight with
many assumptions currently being made in the Makefiles.

Martin

On Tue, Jul 29, 2008 at 4:34 PM, Dalibor Topic <[EMAIL PROTECTED]> wrote:
> Erik Trimble wrote:
>>
>> Dalibor Topic wrote:
>>>
>>> Erik Trimble wrote:

 Also, Cygwin is the UNIX-ism platform of choice, and getting the JDK to
 build solely with Cygwin (on both 32- and 64-bit, Win2k, WinXP, and 
 Win2003)
 would be a _huge_ deal.
>>>
>>> I.e. using the gcc provided by Cygwin and the 'posixy' libc it provides?
>>>
>>> cheers,
>>> dalibor topic
>>>
>> I certainly can't speak for Sun on this.  But, I don't think there is any
>> immediate plans to use GCC on Windows. It would probably be OK if someone
>> wanted to try, but I can't imagine it being even remotely easy.  There's
>> just so much stuff dependent on the various Visual Studio or MS SDK header
>> files, that I'm almost positive you have to install them to do the build, so
>> why bother with GCC?
>
> I'm somewhat curious whether having OpenJDK packaged in Cygwin (and ant,
> etc.) would make our life easier on windows builds, though I'm not really
> hot on going down a rabbit hole if it has no benefit to OpenJDK.
>
> 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 55http://openjdk.java.net
> D-20097 Hamburg mailto:[EMAIL PROTECTED]
> 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
>
>

Re: getting a handle on build warnings

[Martin Buchholz]

One significant simple annoyance is that compile errors are hard to find
amongst the mass of warnings, because errors are not identified as such.
It would be very nice if errors were prefixed by "error:" the same
way that warnings are prefixed by "warning:",
making them easy to search for.

Martin

Re: Need Reviewers - OpenJDK README-builds.html

[Martin Buchholz]

The maintainer of GNU make makes a commitment here:

http://article.gmane.org/gmane.comp.gnu.make.windows/2937

to fix the problem in 3.82


On Mon, 2008-06-30 at 18:08 -0700, Kelly O'Hair wrote:
> I assume cygwin will not be fixing this, in 3.82 or ever, is that
> the conclusion I am seeing?

No; I'm pretty sure it's already been fixed in CVS actually.

I just think that, in general, it's not guaranteed by make (or any other
cygwin tool) that you'll be able to use full DOS-style pathnames.
However, at least for make, unless there's some serious incompatibility
that makes it very difficult (or unless whomever maintains the Cygwin
port declines to make the change, which is not the case here) we'll make
an effort to be compatible.


Martin

On Wed, Jul 9, 2008 at 11:11 PM, Dan Fabulich <[EMAIL PROTECTED]> wrote:
> IMO, this document should not make any predictions about make 3.82, which is
> not yet released.
>
> Last time I researched the "C:/" problem, the developers had said that "C:/"
> paths were defective and that they deliberately pulled support for them
> because they were too much hassle to support in cygwin.  They recommended
> using MSYS make instead.
>
> Here's where they explain their position:
> http://cygwin.com/ml/cygwin/2006-07/msg00671.html
>>
>> > Was this a deliberate break with backwards compatibility?
>> Yes. See . If
>> you are using a POSIX-like "OS" (i.e. Cygwin), you should be using POSIX
>> paths. That's not an inconvenience, that's called writing a bad makefile. If
>> you aren't using Cygwin for the POSIX environment, you should be using
>> MinGW.
>
> [aka MSYS make]
>
> Kelly O'Hair wrote:
>
>>
>> Attached is a diff and an updated OpenJDK README-builds.html file.
>>
>> If anyone has the time to review the changes I would appreciate it.
>>
>> The bugs fixed are:
>>
>> 6704966: OpenJDK README needs additional info on  how to build freetype
>> 6704968: OpenJDK Build README is missing ant requirement
>> 6704973: OpenJDK Build readme needs cygwin package list improvements
>> 6462815: cygwin's gnumake 3.81-1 does not support MS-DOS path names
>>
>> And the environment variable list is sorted.
>>
>> -kto
>>
>
>

Re: OpenJDK 7 build failure in com/sun/tools

[Martin Buchholz]

I don't know how, when or why,
but I can no longer reproduce this problem
in the latest OpenJDK.
Probably a temporary glitch.

Martin

On Wed, Jul 2, 2008 at 4:09 PM, Martin Buchholz <[EMAIL PROTECTED]> wrote:
> While building images in a mercurial workspace updated as of today, I get
>
> /home/martinrb/ws/build/build/linux-i586/classes/com/sun/tools/classfile
> : no such file or directory
> /home/martinrb/ws/build/build/linux-i586/classes/com/sun/tools/javap :
> no such file or directory
> make[1]: *** [initial-image-jdk] Error 1
> make[1]: Leaving directory `/usr/local/google/home/martin/ws/build/jdk/make'
> make: *** [jdk-build] Error 2
>

Re: OpenJDK 7 build failure in com/sun/tools

[Martin Buchholz]

On Wed, Jul 2, 2008 at 6:33 PM, Tim Bell <[EMAIL PROTECTED]> wrote:
> I (Tim Bell) wrote:
>
>> I will test the "complete OpenJDK forest" part.  See below for the "when
>> building the "jdk" repository" part:
>
> My complete OpenJDK forest build ran OK on solaris-i586.

Thanks.
I can reproduce this problem on my personal
Ubuntu 7.10 machine with forest MASTER, linux-i586.
updated as of yesterday.  That would be the kind of
build to try.

> [... snip ...]
>
>> I think if you check you will find that you got the 'old' javap from
>> BOOTDIR (nothing wrong with that - it still works as ever) but the new
>
> I tell a lie here - that should be [ALT_]BUILD_JDK_IMPORT_PATH and not
> BOOTDIR

Agreed.

OpenJDK 7 build failure in com/sun/tools

[Martin Buchholz]

While building images in a mercurial workspace updated as of today, I get

/home/martinrb/ws/build/build/linux-i586/classes/com/sun/tools/classfile
: no such file or directory
/home/martinrb/ws/build/build/linux-i586/classes/com/sun/tools/javap :
no such file or directory
make[1]: *** [initial-image-jdk] Error 1
make[1]: Leaving directory `/usr/local/google/home/martin/ws/build/jdk/make'
make: *** [jdk-build] Error 2

The failing command appears to be a (very long) jar command
invoked from Release.gmk

$(BOOT_JAR_CMD) c0f $(LIBDIR)/tools.jar $(addprefix \
-C $(CLASSBINDIR) , $(TOOLS)) \
$(JAR_JFLAGS)


This happens both building a complete OpenJDK forest and
when building the "jdk" repository.

32-bit linux Ubuntu 6.06

This is a very recently introduced failure (over the past week?).

Fortunately, there is a workaround that's not too painful.
Simply create the two missing directories and restart the build.
Even javap works!

I'm currently successfully building like this:
make clobber; mkdir -p
../build/linux-i586/classes/com/sun/tools/{classfile,javap}; make all
images

But it's still a P1 bug, right?

Martin

Re: [NEW BUG] Running jtreg tests on NetBSD

[Martin Buchholz]

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
<[EMAIL PROTECTED]> 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.
>

Re: Trying to build openjdk7 under opensolaris

[Martin Buchholz]

On Fri, Jun 27, 2008 at 6:11 PM, Kelly O'Hair <[EMAIL PROTECTED]> 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

Re: Ability to override compiler from environment

[Martin Buchholz]

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 <[EMAIL PROTECTED]> 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

Re: Recommended GCC version?

[Martin Buchholz]

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 <[EMAIL PROTECTED]> 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.
>
>

Re: Recommended GCC version?

[Martin Buchholz]

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

Re: hg: jdk7/build/jdk: 2 new changesets

[Martin Buchholz]

On Wed, Jun 11, 2008 at 2:53 PM, Mark Reinhold <[EMAIL PROTECTED]> wrote:
>> Date: Tue, 10 Jun 2008 18:09:10 -0700
>> From: Martin Buchholz <[EMAIL PROTECTED]>
>
>> I did my last hg push from a Google machine.
>> I have no idea why mercurial notification thinks I am [EMAIL PROTECTED]
>
> 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

Re: hg: jdk7/build/jdk: 2 new changesets

[Martin Buchholz]

Hi OpenJDK administrators,

I did my last hg push from a Google machine.
I have no idea why mercurial notification thinks I am [EMAIL PROTECTED]
I'd like to have control over my identity, and these days
I'd like to be known as "Martin Buchholz <[EMAIL PROTECTED]>".

Martin

On Tue, Jun 10, 2008 at 5:11 PM,  <[EMAIL PROTECTED]> wrote:

Removing vestigial MOTIF references from Makefiles

[Martin Buchholz]

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

Improper passing of variables to submake

[Martin Buchholz]

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)

Re: OpenJDK Build error on Ubuntu 8.04

[Martin Buchholz]

On Tue, Jun 3, 2008 at 10:09 AM, Andrew Haley <[EMAIL PROTECTED]> 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

Re: OpenJDK Build error on Ubuntu 8.04

[Martin Buchholz]

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 <[EMAIL PROTECTED]> wrote:
> But if one of our scripts actually needs bash (not just sh) why not use
> #!/bin/bash ?
>
> Andrew.
>

duplicated sanity check warning

[Martin Buchholz]

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

Re: Building OpenJDK 7 on Windows XP

[Martin Buchholz]

I propose that Sun create an externally-visible tree of binaries
in the form that the JDK makefiles expect for ALT_SLASH_JAVA.
Then OpenJDK developers could copy this tree to their development
machine, set ALT_SLASH_JAVA to this directory, and most of
the sanity warnings would evaporate.

Of course, this may not be possible for everything that is
expected to be found in ALT_SLASH_JAVA.  E.g. Sun compilers
probably cannot be provided this way, because of the usual
requirement to have click-through licenses?!
Perhaps Sun could aggregate a complete JDK development
environment in one mega-tarball, protected by just one
click-through license?

Perhaps Sun could provide a known-to-work copy of Cygwin
for JDK development.  The Cygwin project itself doesn't provide
historic binaries, but if you install Cygwin by first downloading
everything to disk, and then installing from there, you'll have
a frozen-in-time set of Cygwin binaries that you can probably
legally redistribute later when they've gotten the thumbs-up
from Sun JDK development engineers.

Martin

JDK_DEBUG_IMAGE_DIR

[Martin Buchholz]

The only reference to JDK_DEBUG_IMAGE_DIR
in the jdk workspace is

./make/common/Release.gmk:1239: $(RM) -r $(JDK_DEBUG_IMAGE_DIR)

This variable is defined nowhere.

As a result, "make images-clobber" runs the command

rm -f -r

This is Mostly Harmless, but what would happen if a user happened to
have defined an environment variable

JDK_DEBUG_IMAGE_DIR=/

so I consider this a P2 bug.

Just remove that line from Release.gmk.

For bonus points, write a script to find all never-defined MAKE variables
in all the JDK makefiles.

# HG changeset patch
# User martin
# Date 1211056134 25200
# Node ID 9149e388e6e353da275887a0e6b4ae5ef63b4689
# Parent  1483094a7c17de9c594d51e0f0785d24e3858392
[mq]: JDK_DEBUG_IMAGE_DIR.patch

diff --git a/make/common/Release.gmk b/make/common/Release.gmk
--- a/make/common/Release.gmk
+++ b/make/common/Release.gmk
@@ -1236,7 +1236,6 @@ ifeq ($(PLATFORM), windows)
$(RM) $(TEMPDIR)/rebase.input
 endif
$(RM) -r $(JDK_IMAGE_DIR)
-   $(RM) -r $(JDK_DEBUG_IMAGE_DIR)
$(RM) -r $(JRE_IMAGE_DIR)

 images images-clobber::

Re: Building on ubuntu 8.04

[Martin Buchholz]

FYI - simply changing the /bin/sh symlink probably works,
but the official way to do this is with dpkg-reconfigure.
BTW, I think the message below is incorrect;
neither bash nor dash is fully POSIX compliant.
See also
https://bugs.launchpad.net/ubuntu/+source/dash/+bug/61463

$ sudo dpkg-reconfigure dash
Configuring dash


Bash is the default /bin/sh on a Debian system.  However, since the Debian
policy requires all shell scripts using /bin/sh to be POSIX compliant, any shell
that conforms to POSIX can serve as /bin/sh.  Since dash is POSIX compliant, it
can be used as /bin/sh.  You may wish to do this because dash is faster and
smaller than bash.

Install dash as /bin/sh? no

Martin

On Thu, May 15, 2008 at 4:07 AM,  <[EMAIL PROTECTED]> wrote:
>
>
> Hi all,
>
> First, I really appreciate the help, thank you all!
>
> Second, I did perform a make clean. And I don't understand. I removed sh
> from my system and made a symlink from sh to bash, so every time sh is
> called, it is forwarded to bash, isn't it?
> Anyway, I checked the files you gave, and I changed the calls, so they
> should use bash now. But, I'm a newbie on this kind of stuff, I use Java for
> several years now, but this is new for me.
>
> Kind regards,
>
> Bram
>
>
> Roman Kennke wrote:
> Also, maybe you simply forgot make clean after you fixed your shell?
>
> /Roman
>
> Am Mittwoch, den 14.05.2008, 12:56 -0700 schrieb Brad Wetmore:
>
> I think you've got a problem still with your sh setup, or possibly something
> else.  IIRC, the ?replType? variables is supposed to be replaced with
> various values depending on whether you have an encoder or decoder.
> (sed/awk preprocessing = a Javaman's #ifdef equivalent)  It's done a similar
> way for the {Byte,Char,Int...}Buffers.
>
> Check jdk/make/java/nio, specifically Makefile, spp.sh, and genCoder.sh
>
> Hope this helps.
>
> Brad
>
>
> Bram Somers wrote:
>
> Dear all,
>
> I've tried building jdk7 on Ubuntu 8.04. I'm aware of the problems with
> sh/dash and I remove sh and made a symlink of sh to bash, so normally I
> shouldn't get this error anymore:
>
> jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:142:
> cannot find symbol
> symbol  : class $replType$
> location: class java.nio.charset.CharsetEncoder
>private $replType$ replacement;
>^
> /home/bsomers/workspaces/openjdk/jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:185:
> cannot find symbol
> symbol  : class $replType$
> location: class java.nio.charset.CharsetEncoder
>   $replType$ replacement)
>   ^
> /home/bsomers/workspaces/openjdk/jdk7/build/openjdk_full_debug/gensrc/java/nio/charset/CharsetEncoder.java:246:
> cannot find symbol
> symbol  : class $replType$
> location: class java.nio.charset.CharsetEncoder
>public final $replType$ replacement() {
> ^
> /home/bsomers/workspaces/openjdk/jdk7/build/openjdk_full_debug/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/bsomers/workspaces/openjdk/jdk7/build/openjdk_full_debug/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
>
>
> Any more suggestions?
>
> Thanks in advance,
>
> kind regards,
>
> Bram
>
>
>
>
>
>

Re: Runing findbugs

[Martin Buchholz]

It looks like you want the -auxclasspath flag to findbugs.
See http://findbugs.sourceforge.net/manual/ch11.html

(I haven't actually tried this myself)

Martin

On Tue, May 13, 2008 at 4:37 PM, Kelly O'Hair <[EMAIL PROTECTED]> wrote:
>
>  I'm currently looking at how we could possible include a run of findbugs
>  in the build process, but my conclusion right now is that we cannot do it
>  by default, it takes way to long to run findbugs over everything. (>12hrs).
>
>  But I could add some minor support to the Makefiles to allow someone to
>  run findbugs on specific classes/packages, using a command line like this:
>
>   findbugs -textui -maxHeap 1024 -javahome /YOUR/jdk1.6.0 -sortByClass \
>-onlyAnalyze "IMPORT_SPEC" -html -output report.html \
>CLASSES_DIRECTORY_OR_JAR
>
>  For example, after I have built the jdk, you could run findbugs over just
>  the java.lang.* classes:
>
>   findbugs -textui -maxHeap 1024 -javahome /opt/java/jdk1.6.0 -sortByClass \
>-onlyAnalyze "java.lang.*" -html -output report.html \
> build/solaris-i586/classes
>
>  Ideally you want a fully populated classes directory or jar file so
>  that it can analyze all the classes properly.
>  (Note: using java.lang.* does not include the classes in the nested
> packages).

Re: Howto re-compile ony parts?

[Martin Buchholz]

Unfortunately, incremental builds by running make in subdirectories
have historically been quite unreliable, and it has never been highest priority
to fix them.  Developers often do (at least in the jdk repository)
- try incremental build; it might work...
- else back off to rebuilding everything;
  cd jdk/make; make clobber all

You could try to fix all of the subdirectory makefiles, but that's an
enormous job.
For bonus points, you could try to fix the architecture of the
recursive makes themselves
using the ideas in "Recursive Make Considered Harmful"
http://miller.emu.id.au/pmiller/books/rmch/

Martin

On Sat, May 10, 2008 at 9:15 AM, Clemens Eisserer <[EMAIL PROTECTED]> wrote:
> Hi,
>
>  Thanks a lot for helping.
>
>  It still does not work, this is what I did:
>  1.) build the entire OpenJDK including corba, ...
>  2.) cd jdk/make/sun/xawt
>  3.) export ALT_JDK_IMPORT_PATH=../../../../build/linux-i586/
>  4.) make ARCH_DATA_MODEL=32

Re: OpenJDK does not build on Solaris nv82

[Martin Buchholz]

I agree that the more conservative fix you applied is perfect for
legacy releases.

For jdk7, we should forget about possible failure with antique Linux
releases, especially given this could only ever affect developers.

Martin

Kelly O'Hair wrote:

This is the change I did to JDK6 and the OpenJDK6 files.
Granted it's been pointed out that maybe just doing this include
on both Linux and Solaris should work, I wasn't sure about
doing this include on Linux at the time I made the change.

We use some pretty antique Linux systems for jdk5/jdk6 and the variations
in the Linux systems seems pretty extreme, so I'm never quite sure
what is safe to do that works for both our antique versions and the
newer versions of Linux. :^(

-kto

--- old/src/solaris/hpi/native_threads/src/sys_api_td.cFri Jan 11 
15:08:55 2008
+++ new/src/solaris/hpi/native_threads/src/sys_api_td.cFri Jan 11 
15:08:55 2008

@@ -1,5 +1,5 @@
 /*
- * @(#)sys_api_td.c1.34 05/11/17
+ * @(#)sys_api_td.c1.35 08/01/11
  *
  * Copyright 2006 Sun Microsystems, Inc. All rights reserved.
  * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
@@ -52,6 +52,8 @@
  */
 #ifdef __linux__
 typedef int rlim_t ;
+#else
+#include 
 #endif



Tim Bell wrote:

Alexey Ushakov wrote:

Hello Max,

Actually, we've already found this problem and passed to the team 
responsible for the code (Cannot provide you  bug id at the moment 
though, but will do as soon as I get it). For now you can use 
following workaround in openjdk sources (that worked for me):


This is Bug-ID 6637583
Build failure on latest Solaris, source missing include of resource.h?

Kelly has built a fix that you could pull from his repository.

HTH - Tim



--- src/solaris/hpi/native_threads/src/sys_api_td.c ---
55a56,59
 > #if defined(__solaris__)
 > #include 
 > #endif
 >

Best Regards,
Alexey


Max (Weijun) Wang wrote:

Hi All

Just update my Solaris to nv82 and nightly build fails:

"/net/bounty.prc.sun.com/j2se-jsn/max/work/myjdk/jdk/src/solaris/hpi/native_threads/src/sys_api_td.c", 
line 101: syntax error before or at: limit
"/net/bounty.prc.sun.com/j2se-jsn/max/work/myjdk/jdk/src/solaris/hpi/native_threads/src/sys_api_td.c", 
line 101: warning: undefined or missing type for: limit
"/net/bounty.prc.sun.com/j2se-jsn/max/work/myjdk/jdk/src/solaris/hpi/native_threads/src/sys_api_td.c", 
line 105: undefined symbol: limit
cc: acomp failed for 
/net/bounty.prc.sun.com/j2se-jsn/max/work/myjdk/jdk/src/solaris/hpi/native_threads/src/sys_api_td.c 

gnumake[5]: *** 
[/net/bounty.prc.sun.com/j2se-jsn/armory/java/re/max_huge/b7open/solaris-sparc/tmp/java/hpi/native_threads/obj/sys_api_td.o] 
Error 2

gnumake[5]: *** Waiting for unfinished jobs
gnumake[5]: *** Waiting for unfinished jobs
gnumake[5]: Leaving directory 
`/net/bounty.prc.sun.com/j2se-jsn/max/work/myjdk/jdk/make/java/hpi/native' 



It seems that inside the file 
jdk/src/solaris/hpi/native_threads/src/sys_api_td.c, there's a line

 101:   int InitializeIO(rlim_t limit)
and the type rlim_t is not recognized.

I do a little search and find out that in my /usr/include/sys/stream.h:

#include 
#ifdef _KERNEL
#include 
#endif
#include 
#include 
#include 
#include 
#include 

While in the old versions, the sys/vnode.h line is not surrounded in 
#ifdef.


Anyone can pass this to a Solaris guy?

Thanks
Max