Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

libpng with OW 1.9

38 views
Skip to first unread message

Michael Kraemer

unread,
May 13, 2011, 11:19:55 AM5/13/11
to
Hello,
I wonder whether anybody has compiled the latest version of libpng
with one of the later OW versions. I'm getting type errors, which I
cannot quickly trace to their roots, even though I suspect some weird
coding of setjmp in the libpng. The compiler complains that (__watcall
*) is different to (__cdecl *), which is probably correct. I would
appreciate if anyone who already fixed the problem, could give me a
quick hint. It would perhaps help to relax type checking temporarily,
because at the end, each pointer is 32-bits.
Thanks,
Michael

Mat Nieuwenhoven

unread,
May 13, 2011, 1:28:31 PM5/13/11
to

It is probably the default calling convention. Try option -ecc if you are
using wcc386 .

Mat Nieuwenhoven


tim_c

unread,
May 15, 2011, 7:43:17 AM5/15/11
to

1.2.44 is working here

The 1.5 series is probably broken for ow.

http://www.libpng.org/pub/png/libpng.html

Michael Kraemer

unread,
May 16, 2011, 11:44:24 AM5/16/11
to
> 1.2.44 is working here
>
> The 1.5 series is probably broken for ow.
>
> http://www.libpng.org/pub/png/libpng.html

I'm still using 1.2.35 and thought it would be a good idea to migrate
to a newer version, but as you say, it is broken. Thanks also to Mat,
but -ecc is not working, unfortunately. I like libpng, but I'm not
inclined to fix it, so I'll stay with the old version, at least for
now.

Jiri Malak

unread,
May 16, 2011, 2:15:32 PM5/16/11
to
C:\src\lpng152\lpng152>wmake -f scripts\makefile.watcom
Open Watcom Make Version 1.9
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
wcl386 -zq pngtest.obj libpng.lib ..\zlib\zlib.lib
pngtest.exe

Testing libpng version 1.5.2
with zlib version 1.2.3

libpng version 1.5.2 - March 31, 2011
Copyright (c) 1998-2011 Glenn Randers-Pehrson
Copyright (c) 1996-1997 Andreas Dilger
Copyright (c) 1995-1996 Guy Eric Schalnat, Group 42, Inc.
library (10502): libpng version 1.5.2 - March 31, 2011

pngtest (10502): libpng version 1.5.2 - March 31, 2011

Testing pngtest.png:
Pass 0: rwrwrwrwrwrwrwrwrw
Pass 1: rwrwrwrwrwrwrwrwrw
Pass 2: rwrwrwrwrwrwrwrw
Pass 3: rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw
Pass 4: rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw
Pass 5: rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw
rwrwrwrw
Pass 6: rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw
rwrwrwrwrw
PASS (9782 zero samples)
Filter 0 was used 21 times
Filter 1 was used 15 times
Filter 2 was used 52 times
Filter 3 was used 10 times
Filter 4 was used 33 times
tIME = 7 Jun 1996 17:58:08 +0000
libpng passes test

C:\src\lpng152\lpng152>

tim_c

unread,
May 16, 2011, 4:00:01 PM5/16/11
to
On 16/05/2011 19:15, Jiri Malak wrote:

> Testing libpng version 1.5.2
> with zlib version 1.2.3
>
> libpng version 1.5.2 - March 31, 2011

Ah, good, 1.5, can't remember what went wrong when I tried.

This means that either of 1.2 or 1.5 series current version can be used.

Jiri Malak

unread,
May 17, 2011, 3:28:44 AM5/17/11
to
>
>> Testing libpng version 1.5.2
>> with zlib version 1.2.3
>>
>> libpng version 1.5.2 - March 31, 2011
>
> Ah, good, 1.5, can't remember what went wrong when I tried.
>
> This means that either of 1.2 or 1.5 series current version can be used.

You must take into account that you must recompile both libraries by Open
Watcom.
You can not use distributed libraries because they are incompatible with
Open Watcom calling convention and OW CRTL.

Jiri


Michael Kraemer

unread,
May 17, 2011, 11:58:13 AM5/17/11
to
On 16 Mai, 20:15, "Jiri Malak" <malak.j...@gmail.com> wrote:
> C:\src\lpng152\lpng152>wmake -f scripts\makefile.watcom

That was a good hint, thank you. I used the IDE to make the library.
Now I found the difference is the "build target", the -bt option. In
the makefile, it is -bt=DOS, while it is -bt=NT in my IDE project.
That makes the difference! If I modify the makefile, i.e. set the
target OS to NT (line 21/22), then the error is back also in the
makefile.
Now the question is, if I can generate the library for a DOS build
target and link it to a Windows project. I'll have to investigate, but
if someone knows the answer right away, please let me know.

Jiri Malak

unread,
May 17, 2011, 4:31:05 PM5/17/11
to
It is nonsense. You must create library for your target.
Take into account that you must setup OW environment properly for your target.
What exactly you get as error?

Jiri


Michael Kraemer

unread,
May 18, 2011, 2:55:57 AM5/18/11
to
> It is nonsense. You must create library for your target.
Yes, I thought so.

> Take into account that you must setup OW environment properly for your target.
> What exactly you get as error?

The error message is "(__watcall *) is different to (__cdecl *). Why
is this error only produced, when the build target is NT, not when it
is DOS? I begin to suspect a flaw in OW.


Jiri Malak

unread,
May 18, 2011, 4:10:44 AM5/18/11
to
Problem is not in OW.
There are bugs in libpng related to calling convention, which you get if you compile it by OW.
Difference between DOS and NT target is nice example of these bugs.
For WIN32 target is defined PNGCAPI calling convention but it is not defined for DOS target (use
compiler default).
Due to DOS compilation is OK but WIN32 report problem.

I added bug report to libpng bug tracker about one bug.

You can fix it manualy in png.h file if you change following lines
typedef PNG_FUNCTION(void, (PNGCAPI *png_longjmp_ptr), PNGARG((jmp_buf, int)),
PNG_PTR_NORETURN);
#endif
to
typedef PNG_FUNCTION(void, (*png_longjmp_ptr), PNGARG((jmp_buf, int)),
PNG_PTR_NORETURN);
#endif

Jiri


Michael Kraemer

unread,
May 18, 2011, 8:39:14 AM5/18/11
to
> You can fix it manualy in png.h file if you change following lines
> typedef PNG_FUNCTION(void, (PNGCAPI *png_longjmp_ptr), PNGARG((jmp_buf, int)),
>    PNG_PTR_NORETURN);
> #endif
> to
> typedef PNG_FUNCTION(void, (*png_longjmp_ptr), PNGARG((jmp_buf, int)),
>    PNG_PTR_NORETURN);
> #endif
>
> Jiri

Thanks a lot, that helps. But meantimes I found the "official"
solution to the problem. It is described in the makefile, one just has
to find and to read it: "copy scripts/pnglibconf.h.prebuilt, delete
the first line and change the definition of PNG_API_RULE from 0 to 2."
Again a RTFM case, sorry.

Michael

E. S. Fabian

unread,
May 18, 2011, 9:07:29 AM5/18/11
to
Michael Kraemer:

Actually, it is the author who ought to have done that with a preprocessor
test for compiler, setting it appropriately, instead of requiring source
code change. The current method requires you to change the source code each
time you obtain a new version, and makes it difficult to match your versions
with the author's versions. Preprocessor tests for compiling and target
environment had been a common method even before the first standard for C
was proposed decades ago.
--
Steve


Michael Kraemer

unread,
May 18, 2011, 9:52:06 AM5/18/11
to
> Actually, it is the author who ought to have done that with a preprocessor
> test for compiler, setting it appropriately, instead of requiring source
> code change. The current method requires you to change the source code each
> time you obtain a new version, and makes it difficult to match your versions
> with the author's versions. Preprocessor tests for compiling and target
> environment had been a common method even before the first standard for C
> was proposed decades ago.

I would never blame somebody, who offers something for free. Like OW,
libpng or zlib, I'm happy and thankful that people publish their work
for free use. It's me who should have read the doc...

Michael

Jiri Malak

unread,
May 18, 2011, 9:53:11 AM5/18/11
to
PNG_API_RULE switch calling convention used by png library API only.
PNG_API_RULE parameter only mask primary bug similar as DOS target, it is not solution.
I do not have to use __watcall calling convention with OW if I want to use __cdecl or other.
It is nothing magic you can select whatever you need and all must be going OK.
Primary problem is that png_longjmp_ptr prototype is wrong.
It is pointer to ANSI function but in png library it is defined as C calling convention function
even if ANSI doesn't define any calling convention.
It is non-portable code.

Jiri


E. S. Fabian

unread,
May 18, 2011, 12:03:46 PM5/18/11
to
|| Actually, it is the author who ought to have done that ...

|
| I would never blame somebody, who offers something for free. Like OW,
| libpng or zlib, I'm happy and thankful that people publish their work
| for free use. It's me who should have read the doc...

I am not blaming (I did not write "the author's fault"), but I learned
decades ago to include controls for all platforms to which my code could be
ported. Even for my own use! That's why I have lots of utilities coded in
C90 that I compiled and run on a variety of platforms, from Unix System V
(on a variety of hardware) to Solaris to VAX-VMS to Intel 8080 to the latest
MS Windows with no source change. It behooves one who provides software for
others to use, whether free or not, to make its use easy. BTW, I noted
Jiri's comment that the source code changed referred to actually masks a
bug, instead of correcting it. In your place I'd send the corrected source
back to the author, so it could be incorporated into the next version,
making it more protable.
--
Steve


John Bowler

unread,
May 18, 2011, 2:32:04 PM5/18/11
to
The openwatcom support in libpng is, at best, a stub. One stub is
obvious - the 'echo' in scripts/makefile.watcom. The other is much
more important - it's the real support in scripts/pnglibconf.dfa at
line 140.

What I'm hearing is that DOS and NT support use different calling
conventions for the compiler longjmp implementation, and that means
the current stub (in pnglibconf.dfa) won't work. What is needed here
is support from someone who understands the IDE, the mindset of
OpenWatcom users and the macros the compiler defines related to the
actual calling convention. I wasn't even able to work out how to copy
a file, let along run sed or awk.

What needs to happen is that at the time the *library* is built the
actual calling convention assumed for the internal library calls to
*png_struct::longjmp_fn needs to be recorded in pnglibconf.h. This
ensures that when the application calls the library it either works or
gets a meaningful warning message because its longjmp pointer is
wrong.

Just as important, someone needs to work out how to run 'awk' -
otherwise pnglibconf.dfa can't be processed and library configuration
is pretty much impossible. The alternative to this is to simply hack
the correct defintion of PNGCAPI into pnglibconf.h when the library is
built.

Defining PNGCAPI empty basically means the library can't be
distributed or installed - because if it is some other poor user will
end up debugging the installer/distributors mistake. If there was
just one system library with one longjmp implementation and one
calling convention it would be easy (and the current compiler specific
test would work), but apparently there are multiple system libraries
and much confusion.

If configure can be made to run all these problems become much more
soluble, so long as configure can find a working awk.

Bear in mind that calls via a function pointer are fundamentally non-
portable to any architecture that has multiple calling conventions and
does not automagically implement wrappers. (For an analogous
situation that is implemented correctly look at how the ARM, which has
multiple instruction sets, is able to cross-call functions coded in a
different instruction set, and how this even works with function
pointers.) The longjmp function recorded by libpng must accept the
system longjmp implementation, regardless of the compiler calling
convention options or defaults passed to the app compilation, or it
must fail at compile time. (Link time failures just get us bug
reports.)

John Bowler <jbo...@acm.org>

Hans-Bernhard Bröker

unread,
May 18, 2011, 5:54:16 PM5/18/11
to
On 18.05.2011 18:03, E. S. Fabian wrote:

> I am not blaming (I did not write "the author's fault"), but I learned
> decades ago to include controls for all platforms to which my code could be
> ported.

The problem with that plan, for an extremely widely used package like
libpng, is that its "all platforms" is an _awful_ lot of platforms.
More than any exhaustive list can possibly handle.

Which is why the GNU folks decided to abandon this approach completely
--- it just doesn't work, because by definition it routinely fails the
moment the code gets used on a platform the original developer didn't
know (or care) about. So they test for features rather than platforms.
The source code, at the least, ends up cleaner. You get

#if HAVE_FEATURE_X

instead of

#if (defined(PLATFORM_X) && !defined(PlATFORM_X_VERSION_2)) || \
defined(PLATFORM_Y) || \
defined(PLATFORM_Z_VERSION_4_AT_LEAST_PATCHLEVEL_4) || \
SOLARIS_VERSION > 7

The price you pay for that is autofoo.

Dee Sharpe

unread,
May 18, 2011, 11:33:07 PM5/18/11
to
True, but in many cases, autofoo's not really practical. I'm not a
stranger to the *nix world & way of doing things, but autofoo is out of
place in the world of OS/2 & Windows. In many cases, for the purposes of
assimilation, it's best to leave autofoo to the *nix crowd.

--

Dee Sharpe

The difference between what IS done
& what COULD be done is relational to
what you ARE doing & what you COULD be doing!

John Bowler

unread,
May 19, 2011, 12:52:57 AM5/19/11
to
autotools is the whipping boy; there really is no credible
alternative.

John Bowler <jbowler @ acm.org>

Dee Sharpe

unread,
May 20, 2011, 3:56:30 AM5/20/11
to
Then, perhaps it's time for our common platforms to come up with an
alternative & create a standard around it.
0 new messages