It is probably the default calling convention. Try option -ecc if you are
using wcc386 .
Mat Nieuwenhoven
1.2.44 is working here
The 1.5 series is probably broken for ow.
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.
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>
> 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
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
> 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.
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
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
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
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
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
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>
> 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
The difference between what IS done
& what COULD be done is relational to
what you ARE doing & what you COULD be doing!
John Bowler <jbowler @ acm.org>