Web lists-archives.com

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 
%p\n",file_name,fp);	 fflush(flog);

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 
with the
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 
what flag
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.


David Mathog
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:
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe