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
>

Reply via email to