[Mingw-users] MinGW headers gcc parse error

[Soren A. <sor...@sp...>]

Hello,

I greet all those old friends -- Paul, Mumit, Earnie, Paul, etc -- who have 
generously helped in the past with responses to my inquiries. I have been 
off the List for many months (going on years).

I signed up again today in order to ask a question. I am getting a 
maddening parse error while trying to build an application. I have 
discovered that the source compiles cleanly under Cygwin but not under 
MinGW. The app is "pngcrush", a rather niche-interest but nonetheless 
valuable command-line tool for getting best compression on PNG images:
http://sourceforge.net/projects/pmt/

It's developer is Glenn Randers-Pehrson, one of the key figures in libPNG 
development. There's a strong relationship between pngcrush and libPNG.

The pngcrush version is 1.5.8. This affects older versions too. OK, 
background done: here's the trouble...

The trouble is in the source file {pngcrush.c} where a macro is used like 
this:
--------------------------------
#if CLOCKS_PER_SEC <= 100
#  define TIME_T long
#else
#  define TIME_T float
#endif
--------------------------------
The first line there is a parse error. Checking the value assigned to the 
identifier CLOCKS_PER_SEC in the minGW universe, that turns out to be
#define CLOCKS_PER_SEC ((clock_t)1000)
(the value that cpp lists under MinGW, when simulating processing by doing 
"gcc -E -dM [etc]").
and the Cygwin header's value is
#define CLOCKS_PER_SEC 1000

I'd really appreciate it if somebody with knowledge and grasp would look 
into this discrepancy and I'd love to find out why this simple little thing 
is so incompatible between these two Win32-ish platforms. I've hacked 
myself a way to cope with it for now using some source modification and 
some Makefile voodoo to substitute a redefined value as a -D argument to 
gcc. But this is a stopgap fix.

---------------------------------------

I also want to mention a plan to publicly (on this List) announce an 
"ambidextrous build-workflow packaging" for building jpeg-6b (libjpeg) with 
versioning control in the naming of executables (like Cygwin is doing in 
its libjpeg package), an enhanced config.in, etc.

By "ambidextrous" I mean that it will build oob using standard 
configuration and building invocations without special efforts on the part 
of the user, on both MinGW and Cygwin. Since I am aware of existing 
packagings of jpeg-6b for MinGW in the repository site I am referring to 
this as an "alternate packaging". Motivation for this is related to my 
concern over the multiplicity of different jpeg-6b packagings out there 
(each with some shortcomings or narrow specificity); this is an attempt to 
unify them, incorporating good build features, and especially to benefit 
users of the Win32-gcc dev platforms (MinGW and Cygwin, as contrasted with 
MSVC, which I am not incorporating any support for). This is NOT anything 
to do with any new modifications to the IJG source that affect performance. 
That's why I am stressing that its merely a "repackaging."

I am not going to be seeking any official status at minGW or Cygwin 
whatsoever for this work (again, 
vis-a-vis the existing package[s]), merely to let possible beneficiaries 
know of its existance. I guess I will be putting it up on some Website 
space somewhere. I am sounding off now, in advance, in order to test 
interest levels.

  Best regards,
    Soren Andersen
-- 
Server poetry: "404 File Not Found"

I ate your Web page.
Forgive me. It was juicy
And tart on my tongue.

    - found at: http://www.mit.edu