Re: [Mingw-users] Using mingw's libpng?
- Date: Tue, 05 Jul 2016 16:54:07 -0700
- From: mathog <mathog@xxxxxxxxxxx>
- Subject: Re: [Mingw-users] Using mingw's libpng?
On 05-Jul-2016 09:55, Eli Zaretskii wrote:
Using fprintf() statements and multiple rebuilds of libPNG placed into
/usr/local, the location of the failure was tracked to
check = fwrite(data, 1, length, (png_FILE_p)(png_ptr->io_ptr));
in png_default_write_data() in pngwio.c. The call does not set the
check value, it blows up, as does a call to fprintf() or putc() when
given the same pointer as a FILE * in the final parameter. That final
parameter is a pointer with the same value as that seen when the file
was opened many levels above with:
fp = fopen(file_name, "wb");
fprintf(flog," DEBUG MyPng fopened using %s with fp
fprintf(fp,"DEBUG from MyPNG.c\n"); fflush(fp);
fprintf(flog," DEBUG wrote DEBUG line to file with fprintf\n");
That all worked correctly and put the expected string into the binary
However, as stated above, none of fwrite, putc, or fprintf will do so
same pointer value (albeit passed as a "png_FILE_p") when invoked within
the dll, for instance, like so:
FILE *flog = fopen("pngwio2.log","w");
FILE *outf = (png_FILE_p)(png_ptr->io_ptr);
fprintf(flog,"DEBUG mark 10 writing DEBUG to png file\n");
int status = fprintf(outf,"DEBUG from pngwio.c\n"); fflush(outf);
fprintf(flog," DEBUG wrote DEBUG line to file with fprintf with
status %d\n",status); fflush(flog);
In this series the first 3 execute correctly, the 4th explodes, and the
5th is not reached. Notice that IO works as expected when the fopen and
fprintf are in the same function, probably that is also true if they are
in the same library.
There seems to be some sort of mysterious fatal mismatch between file
opened outside of the DLL, with standard C IO functions invoked on that
pointer within the DLL.
This sounds just like:
but since it isn't the Visual build environment it isn't obvious to me
to use on the library build so that the "/MD" equivalent matches between
Python and the dll. I tried "-mthreads" on CFLAGS,CCASFLAGS, and
LDFLAGS in the makefile for the pnglib build and install. Also added
"-mthreads" for the compile line for the MyPNG.c (which calls libPNG)
and the "link" (I guess) that
builds _cmd.pyd. It didn't help.
I think what I really need here is a variant of "png_init_io()" that
takes a filename instead of a FILE *. There doesn't seem to be one now.
To get out of this mess I may have to add one.
Manager, Sequence Analysis Facility, Biology Division, Caltech
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
MinGW-users mailing list
This list observes the Etiquette found at
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.
You may change your MinGW Account Options or unsubscribe at: