Tom Rodriguez wrote:
> Could you be more specific about what bits you are running, i.e. which
> changeset of hotspot? The official openjdk bits run fine for me with at
> least b30-b33.
>
It seems b33.
[EMAIL PROTECTED]:~/mp/interfaces/OpenJDK/jdk7/hotspot$ hg log | head -n 6
changeset: 241:5
On Wed, 2008-08-27 at 14:49 -0700, Martin Buchholz wrote:
> 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.
IcedTea has a list and configure tries to find the appro
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
Hi Jonathan (and hi CC compiler-dev, which I hope is the right
mailinglist for these javah/jni questions),
Maybe you saw these questions/discussion already around the openjdk
javah JNI headers generated for static final constant fields. Which
fields are eligible and which encoding is used in the g
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
c
Hi Mark,
Thanks for pointing this. Actually, the patch existing in the IcedTea
seems to have two potential issues that we at Sun are worried about:
1. The patch cuts off the embedded versions of these libraries from
OpenJDK source code. In fact, there may exist systems where these
libraries
Mark,
I'll see what I can find out for you.
-- Jon
On Aug 28, 2008, at 2:27 AM, Mark Wielaard wrote:
Hi Jonathan (and hi CC compiler-dev, which I hope is the right
mailinglist for these javah/jni questions),
Maybe you saw these questions/discussion already around the openjdk
javah JNI header
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 teste
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 f
Hi Anthony,
On Thu, 2008-08-28 at 14:23 +0400, Anthony Petrov wrote:
> 1. The patch cuts off the embedded versions of these libraries from
> OpenJDK source code. In fact, there may exist systems where these
> libraries are not installed. And currently OpenJDK runs perfectly on
> these systems s
On Thu, 2008-08-28 at 09:48 -0700, Martin Buchholz wrote:
> 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.
Yeah, it would be interesting to look into that. A
On 28.08.08 19:41, Mark Wielaard wrote:
Embedding
the sources seem a bit fragile and apparently hard to update inside
openjdk because of sun legal issues.
There is a legal review process associated with dragging in new external
code, just like
there is a process for that at the FSF - but i
Bringing in an updated version is fairly lightweight.
I recently did this for a fontconfig header file.
There's a web-based form where you fill in the info, confirming the
license hasn't changed, and it gets a short review by a lawyer
and that's about it. Filling in the form takes about 20 mins ma
I built a copy of hotspot from b33 on ubuntu with gcc 4.2 and I'm
seeing the same failure you are. I believe this is the same issue
covered by 6741642 which was found and fixed by the IcedTea folks.
Applying the fix to a copy of b33 allowed dacapo to complete
normally. 6741642 is in the
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
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 mani
16 matches
Mail list logo
