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
s
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 fi
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/Make
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
Hi Mark,
On 08/28/2008 09:35 PM Mark Wielaard wrote:
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
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
Hi Martin,
The AWT folks think we need to guard this CPPFLAGS setting with the
following condition:
ifneq ($(PLATFORM), windows)
...
endif
We don't use gcc on Windows, and everything works just fine with MS VS.
Please feel free to submit the patch with this change, and please add
OpenJDK us
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
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
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
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
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
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
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
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
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,
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
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 requ
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 Ub
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 th
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 b
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
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 declarati
What's the point of these changes?
> -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 =
24 matches
Mail list logo
