Quantcast

Using mingw's libpng?

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Using mingw's libpng?

mathog
Are there some special command line switches needed to build a program
with the libpng dll in mingw?

Using this test program:

   http://zarb.org/~gc/resource/libpng-short-example.c

on a Centos box:

gcc -o png-test libpng-short-example.c -lpng -lz -lm
./png-test testcase.png foo.png

and the program ran.  It dumps the data pixel by pixel and copies the
image
from the first to the 2nd file.

However on Mingw with the same compile line and input data it does:

$ ./png-test testcase.png killme.png

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
libpng error: invalid after png_start_read_image or png_read_update_info
[read_png_file] Error during read_image

This was done on two Mingw systems, an old XP one with a years old
Mingw, and a Windows 7 that was installed a month or so ago with the
current Mingw.  Both behaved exactly the same way.  They also did the
same thing with "-lpng16" instead of "-lpng".

This inquiry started when a much more complex program was crashing at
   png_write_info()

which led to

   
http://stackoverflow.com/questions/34309014/libpng-crashes-on-png-write-into-windows-10-vs2013-self-built-all-tests-pass

which in turn led to this:

   
http://stackoverflow.com/questions/22774265/libpng-crashes-on-png-read-info

Is there maybe a similar issue here?  What flags were used when libpng
was compiled?

Inkscape builds in this environment, and its png works, but it is worth
noting that it uses a different libpng, from its own devlibs package,
not the one that comes with Mingw.

Thanks,

David Mathog
[hidden email]
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.
http://sdm.link/attshape
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using mingw's libpng?

Eli Zaretskii
> Date: Fri, 01 Jul 2016 18:13:23 -0700
> From: mathog <[hidden email]>
>
> Are there some special command line switches needed to build a program
> with the libpng dll in mingw?

That should be stated in the pkg-config file that comes with the
libpng distribution you are using.

> Using this test program:
>
>    http://zarb.org/~gc/resource/libpng-short-example.c
>
> on a Centos box:
>
> gcc -o png-test libpng-short-example.c -lpng -lz -lm
> ./png-test testcase.png foo.png
>
> and the program ran.  It dumps the data pixel by pixel and copies the
> image
> from the first to the 2nd file.
>
> However on Mingw with the same compile line and input data it does:
>
> $ ./png-test testcase.png killme.png
>
> This application has requested the Runtime to terminate it in an unusual
> way.
> Please contact the application's support team for more information.
> libpng error: invalid after png_start_read_image or png_read_update_info
> [read_png_file] Error during read_image

Before you make any conclusions, please try this build of libpng:

  https://sourceforge.net/projects/ezwinports/files/libpng-1.6.12-w32-bin.zip/download

The switches required to compile and link against the library are
specified in the file lib/pkgconfig/libpng.pc included with this
build, and all the dependency DLLs are also included.

------------------------------------------------------------------------------
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.
http://sdm.link/attshape
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using mingw's libpng?

mathog
On 02-Jul-2016 00:45, Eli Zaretskii wrote:
>> Date: Fri, 01 Jul 2016 18:13:23 -0700
>> From: mathog <[hidden email]>
>>
>> Are there some special command line switches needed to build a program
>> with the libpng dll in mingw?
>
> That should be stated in the pkg-config file that comes with the
> libpng distribution you are using.

It is.  I meant in addition to that, because that set produced a binary
that failed as described.  The config file's contents (the part that
matters) are:

version="1.6.22"
prefix="/c/progs/mingw"
exec_prefix="${prefix}"
libdir="${exec_prefix}/lib"
includedir="${prefix}/include/libpng16"
libs="-lpng16"
all_libs="-lpng16 -lz "
I_opts="-I${includedir}"
L_opts="-L${libdir}"
R_opts=""
cppflags=""
ccopts=""
ldopts=""


>
>> Using this test program:
>>
>>    http://zarb.org/~gc/resource/libpng-short-example.c
>>
>> on a Centos box:
>>
>> gcc -o png-test libpng-short-example.c -lpng -lz -lm
>> ./png-test testcase.png foo.png
>>
>> and the program ran.  It dumps the data pixel by pixel and copies the
>> image
>> from the first to the 2nd file.
>>
>> However on Mingw with the same compile line and input data it does:
>>
>> $ ./png-test testcase.png killme.png
>>
>> This application has requested the Runtime to terminate it in an
>> unusual
>> way.
>> Please contact the application's support team for more information.
>> libpng error: invalid after png_start_read_image or
>> png_read_update_info
>> [read_png_file] Error during read_image
>
> Before you make any conclusions, please try this build of libpng:
>
>
> https://sourceforge.net/projects/ezwinports/files/libpng-1.6.12-w32-bin.zip/download

Exactly the same.
>
> The switches required to compile and link against the library are
> specified in the file lib/pkgconfig/libpng.pc included with this
> build, and all the dependency DLLs are also included.

It also fails with a brand new libpng build.
1.  get source, expand, CD to that directory

All the rest are in an MSYS window:

2.  ./configure
     ./make
     ./make install
3.   gcc -o png-test libpng-short-example.c
-I/usr/local/include/libpng16 -lpng16 -lz -lm -L/usr/local/bin
4.  Hide the libpng that was already present by
mv /c/progs/mingw/bin/libpng16.dll
/c/progs/mingw/bin/__HIDE_libpng16.dll

5. ./png-test testcase.png foo.png

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
libpng error: invalid after png_start_read_image or png_read_update_info
[read_png_file] Error during read_image

Dependency walker shows that DOS/Windows cannot find libpng16.dll, since
that is
tucked away in a location that only MSYS knows about (MSYS's path is:

PATH='.:/usr/local/bin:/mingw/bin:/bin:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/mingw/bin'
)

The DOS path is:

Path=C:\Windows\system32;C:\Windows;C:\progs\mingw\bin

and it fails the same way when run from DOS (after the libpng16.dll from
/usr/local/bin is copied to the same directory as png-test.

The programs that were built by the libpng make all seem to work - and
dependency walker doesn't show any of them linked to the DLL.  Looking
at the log of the build one finds:

gcc -DHAVE_CONFIG_H -I.     -I/usr/local/include -MT pngtest.o -MD -MP
-MF $depbase.Tpo -c -o pngtest.o pngtest.c &&\
/bin/sh ./libtool  --tag=CC   --mode=link gcc  -I/usr/local/include  
-L/usr/local/lib -o pngtest.exe pngtest.o libpng16.la -lz

and

libtool: link: gcc -I/usr/local/include -o .libs/pngtest.exe pngtest.o  
-L/usr/local/lib ./.libs/libpng16.dll.a -lz -L/usr/local/lib

Dependency walker shows the final one as having a link to libpng16.dll,
and this version works if run from the top directory like:

.libs/pngtest

The copy of libpng16.dll it is using (according to dependency walker,
probably MSYS does things differently) is the one in .libs, not the one
in /usr/local/lib.

So, build pngtest.c (from libpng) using the simplest possible command
line:

cd .libs
  gcc -o /c/temp/pngtest pngtest.c  -lpng16 -lz -lm
cp pngtest.png /c/temp
cd /c/temp
./pngtest

and it runs normally.  It should not have.  The dll it is supposedly
using from /ming/bin is still hidden.  Hide the one in /usr/local/bin
too and then pngtest fails.  UnHide (remove the __HIDE_) from the one in
/mingw/bin and pngtest works again.

So great, we have one set of programs which work exactly like they do
under linux (the test programs that come with libpng) and another set
that blow up mysteriously when linked to this library (the small test
program from my original post and the module from a much bigger package
which triggered this line of inquiry.)

Perhaps this is some version incompatibility between the code in the
ones that do not work and the current libpng?  Check back on the Linux
systems I used, the one for the build of the larger package, and the one
for the smaller test program, are both using libpng1.2.  Could be that
all I need to get the problem ones to work is to install that older
version (too).

Regards,

David Mathog
[hidden email]
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.
http://sdm.link/attshape
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using mingw's libpng?

Eli Zaretskii
> Date: Mon, 04 Jul 2016 16:05:39 -0700
> From: mathog <[hidden email]>
> Cc: [hidden email]
>
> So great, we have one set of programs which work exactly like they do
> under linux (the test programs that come with libpng) and another set
> that blow up mysteriously when linked to this library (the small test
> program from my original post and the module from a much bigger package
> which triggered this line of inquiry.)

You might be having a DLL hell.  When you tried using the ezwinports
binaries, did you put all of the DLLs that came with the zip file in
the same directory as the test program?  If not, you should try that:
that's the only way to make sure a consistent set of DLLs is used that
you mean the program to use.

All I can say is that the ezwinports build is being actively used in
several programs built by MinGW, by me and others, so it is certainly
correct and usable.

Btw, what version of the MinGW headers and libraries do you have
installed?

> Perhaps this is some version incompatibility between the code in the
> ones that do not work and the current libpng?  Check back on the Linux
> systems I used, the one for the build of the larger package, and the one
> for the smaller test program, are both using libpng1.2.  Could be that
> all I need to get the problem ones to work is to install that older
> version (too).

It could be, but only if the program uses something the newer versions
don't support, in which case I'd expect the compiler to uncover that.
IOW, it's unlikely.

------------------------------------------------------------------------------
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.
http://sdm.link/attshape
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using mingw's libpng?

mathog
In reply to this post by mathog
On 05-Jul-2016 09:55, Eli Zaretskii wrote:
> You might be having a DLL hell.

Definitely some form of hell.

After installing a freshly built libpng12 into /usr/local I was able to
get this to work:

gcc -Wall -o png-test libpng-short-example.c  
-I/usr/local/include/libpng12 -L/usr/local/lib -lpng12 -lz -lm

but not this

gcc -Wall -o png-test libpng-short-example.c  
-I/c/progs/mingw/include/libpng16  -lpng16 -lz -lm

However, the program I really care about, which is PyMOL, doesn't run
when linked
with libpng12 either.

The more I look at this the more I think that it is somehow related to
threaded vs. nonthreaded versions of the libraries as invoked by Python
when PyMOL runs.
A version of libpng16 was built with "-mthreads" set for both compile
and link.
Unfortunately it failed in the same place.  In Visual Studio (which I
don't have)
they discuss the threaded flags:

https://msdn.microsoft.com/en-us/library/aa278396%28v=vs.60%29.aspx

Sadly I don't know how to examine a dll made by MingW to see what
corresponds to what for these threaded configurations.  Unless somebody
can tell me how to get gdb to attach to a dll started by Python I may
have to track this problem down with print statements in a test dll to
find where it is going wrong.

It is really hard to know which libraries are actually being used since
there isn't a single binary produced which can be viewed with Dependency
Walker.  For all I know Python may be picking up a libPNG from somewhere
I don't even know about during the run time.

Thanks,

David Mathog
[hidden email]
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.
http://sdm.link/attshape
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using mingw's libpng?

mathog
In reply to this post by Eli Zaretskii
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");
fflush(flog);

That all worked correctly and put the expected string into the binary
file.

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");
fflush(flog);
    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
pointers
opened outside of the DLL, with standard C IO functions invoked on that
pointer within the DLL.

This sounds just like:

http://stackoverflow.com/questions/34309014/libpng-crashes-on-png-write-into-windows-10-vs2013-self-built-all-tests-pass

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.

Regards,

David Mathog
[hidden email]
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.
http://sdm.link/attshape
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using mingw's libpng?

Keith Marshall
In reply to this post by mathog
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/07/16 02:13, mathog wrote:
> Inkscape builds in this environment, and its png works, but it is
> worth noting that it uses a different libpng, from its own devlibs
> package, not the one that comes with Mingw.

I don't want to derail any useful discussion, which may arise out of
this, but could you please clarify what you mean by "the [libpng] that
comes with MinGW"?

AFAIK, there is no such thing.  I do see a (rather ancient) mingwPORT
of libpng-1.2.8, hidden away here:
https://sourceforge.net/projects/mingw/files/Other/mingwPORT/Current%20Releases/

but that's a very much "build-it-yourself" offering, which is not, and
never has been formally supported by any MinGW.org developer; I would
hardly classify it as "the libpng that comes *with* MinGW".

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJXfP9ZAAoJEMCtNsY0flo/fUwQAKxXb37IvJWi68KCcxvLEJmc
GFfGdcbavS2oLwj6vqiKAxw/M+95ZSOHWjlk2D/Fr9o9EsqB28tRHo8P3VDDuNmb
oeBoKuWmSYLfBcHz4+xg1nbRXi/CHoWna+X4Lypq0g/F2a52kpT1KeAALsPkC+HJ
XgryXZS/4JITTfp2kgxoyLKlXMbot4YId9qE+QOq/1j0BD5ZCF1oQ7XEVdSA0q2H
BLN3dotYt6Uk80QEAoGc9KArjBgmf3NKWAa/POkISRLGifUAy2Y57c9/JK6S4a/Q
/P/GbKF9MVuyAoZM5cpo4xkb6GeXJCX6kFLjl96bh/yy1UG5KqkZvDFeyyyFrNDp
1+HhWjpfR0iivbcno5NEuf8igfckipwZ96Vmp9eUomFhqHsaNqc3/NZx4m1lnE51
3h/pHKSz1K6FyanoifA8JYpCcCnIW0+S1UaandCZ3C0rwdRiwZ2B6KBjKcm/YhU2
WABatcF45a9AC543BRghhBEE7/Di35tCiQ+tCwVju/KgvQGZLKCufJvQK5HcdSzZ
VND7kDuI7rllMmSgjE12z505S1C7a39rHacYeMFIc45yxABqKLunMqwtFdIKB39Q
WGXGL8Csj7ZHDJjNQKDy7QGw+k7m8yZ7/0zx+pP0i286QcEEghZ0Pux1qEdMuq6o
OnMEqsFHmnX6tgmiAsDG
=9Wse
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
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.
http://sdm.link/attshape
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using mingw's libpng?

Eli Zaretskii
In reply to this post by mathog
> Date: Tue, 05 Jul 2016 16:54:07 -0700
> From: mathog <[hidden email]>
> Cc: [hidden email]
>
> 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");
> fflush(flog);
>
> That all worked correctly and put the expected string into the binary
> file.
>
> 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");
> fflush(flog);
>     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);

Are you saying that a FILE * pointer is being created in a DLL, and
then being used outside of that DLL?  That is a no-no on MS-Windows
(and also on other platforms), so that could definitely be part of the
problem.

> 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
> pointers
> opened outside of the DLL, with standard C IO functions invoked on that
> pointer within the DLL.

It isn't mysterious at all, it's one of those things one should never
do when working with dynamic libraries.  The problem is that the DLL
records the dependency libraries it was linked against, and will only
dynamically link to those same libraries at run time, which might be
different from the libraries used by the main program.  If the stdio
functions used by Python, libpng, and the main functions are not the
same, you cannot use file descriptors and pointers created by one in
code that runs in the other one.

> 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.

Yes, something like that.  The important thing is: the file pointers
should be used in the same library/program as the one that creates
them.  They cannot be passed across DLLs.

------------------------------------------------------------------------------
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.
http://sdm.link/attshape
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using mingw's libpng?

mathog
On 06-Jul-2016 07:46, Eli Zaretskii wrote:

> Are you saying that a FILE * pointer is being created in a DLL, and
> then being used outside of that DLL?  That is a no-no on MS-Windows
> (and also on other platforms), so that could definitely be part of the
> problem.
>

Apparently.  The setup.py for the application builds something called
_cmd.pyd
on Windows which I had taken to be some sort of a Python launched
executable but now that I look carefully at the several thousand
character long command line which builds it, "-mdll" appears, so it is
indeed a DLL.   The code in this tells libpng where to write the file in
the usual manner:

          FILE *fp = fopen("filename","wb");
          png_init_io(png_ptr, fp);

In this build environment that doesn't work.

> Yes, something like that.  The important thing is: the file pointers
> should be used in the same library/program as the one that creates
> them.  They cannot be passed across DLLs.

Which does make one wonder how this code ever works on any platform, or
why libpng does not come with a

         png_init_io_by_filename()

to avoid this problem.  On linux setup.py builds the expected _cmd.so,
also a shared library, and it uses exactly the same code, and this
section of code works without a hiccup there.

Regards,

David Mathog
[hidden email]
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.
http://sdm.link/attshape
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using mingw's libpng?

mathog
In reply to this post by Keith Marshall
On 06-Jul-2016 05:53, Keith Marshall wrote:
> I don't want to derail any useful discussion, which may arise out of
> this, but could you please clarify what you mean by "the [libpng] that
> comes with MinGW"?

I must have installed it separately from mingw, judging from the date
stamps, but I don't recall if it was downloaded as a binary from
somewhere or built from source.  It was long enough ago that the details
have faded from my memory and I assumed that it came with Mingw.

Regards,

David Mathog
[hidden email]
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.
http://sdm.link/attshape
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using mingw's libpng?

Eli Zaretskii
In reply to this post by mathog
> Date: Wed, 06 Jul 2016 10:06:31 -0700
> From: mathog <[hidden email]>
> Cc: [hidden email]
>
> The code in this tells libpng where to write the file in the usual
> manner:
>
>           FILE *fp = fopen("filename","wb");
>           png_init_io(png_ptr, fp);

So this opens a file in the Python DLL, and then passes the FILE
pointer to the libpng DLL to use.  That's exactly what should not be
done.

> Which does make one wonder how this code ever works on any platform

Because the code is careless, and was probably only tested on a single
OS, where there's only one standard C library.  On Windows, there are
at least a dozen of different versions of C runtime, and Python
specifically is built with MSVC, so almost certainly uses a runtime
different from the MinGW default (which is msvcrt.dll).

> or why libpng does not come with a
>
>          png_init_io_by_filename()
>
> to avoid this problem.

Someone should suggest that to them.

But the real problem is in the Python module, they do something that
is extremely unportable.

> On linux setup.py builds the expected _cmd.so, also a shared
> library, and it uses exactly the same code, and this section of code
> works without a hiccup there.

On GNU/Linux, _cmd.so will be linked against the same libc.so as the
main program and libpng, so the problem is never seen.  Like I said:
unportable code.

------------------------------------------------------------------------------
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.
http://sdm.link/attshape
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using mingw's libpng?

mathog
On 06-Jul-2016 10:29, Eli Zaretskii wrote:
> On Windows, there are
> at least a dozen of different versions of C runtime, and Python
> specifically is built with MSVC, so almost certainly uses a runtime
> different from the MinGW default (which is msvcrt.dll).

This was evident once I built a zip file to run on another person's
machine.
Both msvcrt.dll and msvcr90.dll were needed.

Regards,

David Mathog
[hidden email]
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.
http://sdm.link/attshape
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using mingw's libpng?

Paul Moore
On 6 July 2016 at 20:18, mathog <[hidden email]> wrote:
> On 06-Jul-2016 10:29, Eli Zaretskii wrote:
>> On Windows, there are
>> at least a dozen of different versions of C runtime, and Python
>> specifically is built with MSVC, so almost certainly uses a runtime
>> different from the MinGW default (which is msvcrt.dll).
>
> This was evident once I built a zip file to run on another person's
> machine.
> Both msvcrt.dll and msvcr90.dll were needed.

As Eli said, Python uses the MSVC CRT (msvcr90.dll in your case - it
depends on the Python version). Building Python extensions should
normally only be done with the same C compiler as Python used, to
avoid precisely this sort of issue. In this case, there are *three*
pieces of code involved, Python itself, the extension (the .pyd file)
and the PNG library. They should all be built with MSVC.

If you are very, very, careful, you can build Python extensions with
mingw, but you have to take care not to pass CRT data (such as FILE
pointers) across the DLL boundaries. Clearly this care isn't being
taken here. Probably because libpng doesn't expose a "safe" API that
uses a filename rather than a FILE*. So the extension author probably
had little choice. The decision is reasonable, as mixing compilers
isn't supported anyway, as you've found out.

If you want to go down this route (again, not advised and not
supported!) then your best bet would be to build the extension with
mingw, and statically link a copy of libpng that was also built with
mingw. The Python-extension boundary is designed to be "relatively"
safe in this situation - it's not too likely you'll experience
crashes. You will still need both CRTs installed on the machines that
use the code.

Paul

------------------------------------------------------------------------------
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.
http://sdm.link/attshape
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using mingw's libpng?

mathog
On 06-Jul-2016 15:58, Paul Moore wrote:
> If you are very, very, careful, you can build Python extensions with
> mingw, but you have to take care not to pass CRT data (such as FILE
> pointers) across the DLL boundaries. Clearly this care isn't being
> taken here. Probably because libpng doesn't expose a "safe" API that
> uses a filename rather than a FILE*. So the extension author probably
> had little choice. The decision is reasonable, as mixing compilers
> isn't supported anyway, as you've found out.

In theory it should be possible to build these extensions with mingw
using
something like:

   gcc hello.c -nostdlib -lmsvcr90 -lgcc -o hello.exe

In practice with a few minutes futzing around along those lines I did
not stumble upon a combination of flags which would work for a test case
which is the code from here

  http://www.lemoda.net/c/write-png/

saved as "fruit.c" and then compiled like:

$ gcc  -Wall -o killme fruit.c   -I/c/progs/mingw/include/libpng16
-L/c/progs/mingw/libs -lpng16 -lz -lm

works and the program produced runs and works OK.  However...

$ gcc  -Wall -o killme fruit.c   -I/c/progs/mingw/include/libpng16
-L/usr/local/libs -lpng16 -lz -lm -nostdlib -lgcc  -lmsvcr90
ertr000001.o:(.rdata+0x0): undefined reference to
`_pei386_runtime_relocator'
collect2: ld returned 1 exit status

$ gcc  -Wall -o killme fruit.c   -I/c/progs/mingw/include/libpng16
-L/usr/local/libs -lpng16 -lz -lm -nostdlib -lmsvcr90 -lgcc
c:/progs/mingw/bin/../lib/gcc/mingw32/4.6.2/libgcc.a(__main.o):(.text+0x52):
undefined reference to `atexit'
c:/progs/mingw/bin/../lib/gcc/mingw32/4.6.2/libgcc.a(__main.o):(.text+0xb6):
undefined reference to `atexit'
collect2: ld returned 1 exit status

moving the last 3 "-l" parameters forward, before -png16 didn't help
either.

Admittedly the libpng it is trying to link to was built with msvcrt.dll,
so possibly it is missing one of these pieces, but adding -lmsvcrt onto
the end
didn't resolve either error message.  Perhaps it would work if the whole
libpng was built first with those flags.

I really doubt it though, because when tested with the simplest possible
code:

cat >hello.c <<EOD
#include <stdlib.h>
#include <stdio.h>
int main(void){
   printf("Hello\n");
   exit(EXIT_SUCCESS);
}
EOD

These gave the same errors as above:
gcc -Wall -o killme hello.c  -nostdlib -lgcc  -lmsvcr90
gcc -Wall -o killme hello.c  -nostdlib  -lmsvcr90 -lgcc


Regards,

David Mathog
[hidden email]
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.
http://sdm.link/attshape
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using mingw's libpng?

Eli Zaretskii
In reply to this post by Paul Moore
> From: Paul Moore <[hidden email]>
> Date: Wed, 6 Jul 2016 23:58:14 +0100
> Cc: Eli Zaretskii <[hidden email]>
>
> If you want to go down this route (again, not advised and not
> supported!) then your best bet would be to build the extension with
> mingw, and statically link a copy of libpng that was also built with
> mingw.

I don't think this can be done on Windows.  Can you show a command
line that does this and works?

------------------------------------------------------------------------------
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.
http://sdm.link/attshape
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using mingw's libpng?

Paul Moore
On 7 July 2016 at 03:40, Eli Zaretskii <[hidden email]> wrote:

>> From: Paul Moore <[hidden email]>
>> Date: Wed, 6 Jul 2016 23:58:14 +0100
>> Cc: Eli Zaretskii <[hidden email]>
>>
>> If you want to go down this route (again, not advised and not
>> supported!) then your best bet would be to build the extension with
>> mingw, and statically link a copy of libpng that was also built with
>> mingw.
>
> I don't think this can be done on Windows.  Can you show a command
> line that does this and works?

I'm afraid I can't, for Python extensions most of the work is done by
distutils. But I believe that some extension projects (some of the
scientific Python stack) do this. As noted by mathog, though,
distutils forces -lmsvcr90, which avoids most, if not all, of the CRT
incompatibility issues - something I'd forgotten, it's been a long
time since I did anything with the distutils mingw support..

Paul

------------------------------------------------------------------------------
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.
http://sdm.link/attshape
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using mingw's libpng?

Keith Marshall
In reply to this post by mathog
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/07/16 01:05, mathog wrote:
> In theory it should be possible to build these extensions with
> mingw using something like:
>
> gcc hello.c -nostdlib -lmsvcr90 -lgcc -o hello.exe
                        ^^^^^^^^^

This is unsupported, and quite simply asking for trouble, because
MinGW's GCC implicitly adds -lmsvcrt to that command, and you are then
linking with two (effectively incompatible) versions of the MSVC runtime.

If you need to use MSVCR90.DLL, then you should NOT link with
- -lmsvcrt, and to achieve that, you need to play tunes with the GCC
specs file, as described in
http://www.mingw.org/wiki/SpecsFileHOWTO#comment-106

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJXfhsWAAoJEMCtNsY0flo/MFsP/iIhpEDKPfKOVksEU6JyP9pu
GVr1oDhLAcJd+3USelGde+J5Sho8i3lIECzbfRmotHKslN0Ft/RmS8IY+lHDrZxg
ZntiR0ytk2EtkDGMNzWgCC/WoWO2sOGfrbkU1cj4RAvM5587MwtB2+qp89EUFfef
lDIw68riJAz+fsIBoMxzoNLD9ZMTwLRjctTbdKroh5u8gsyelQHAapM3zpBx1We8
fn1ccJkdtAf9WaurzAAJA8O1v/7XXBiDc8G/5n8+j6Umx5K9qmSTszqWEf/LWWL8
b71nqDKYg4sGbxoHj4xmtHCz4TipCLdSP+2zClQjzbWDiyzBHQkCpqmzbCA6okRA
3dBKabFDSfReYOkQVrfRdZHibo2GfExvvt3MoPjn6eEQ8D6TPVOyOMWtXz7mM7FT
o0Chir9/jICTvEftU5ACoFoGKdpgbu75ndwbOCn/AACtOuOBCUQeVth8wjLVAwkn
uKH43XZo7IsBoSCDwxelGl+zeIfaRPSSDIunUqj2fd7MH8AaUMrKLpMZxcFvE6iI
n6hK3Hsd+ay2gRp+peQzQxyOi9NbrUCWQkx19IfaG3lg26CvcLIHfP3qxNK9Va6y
YlFOHvxQlzRUQIlKeeZTHo1hGziSa2gwlG1WH0U3KTItc4+7lyNS7XbZ09tlphmQ
fM0Bk2JhLUjqi6LPTbAL
=yHW/
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
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.
http://sdm.link/attshape
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using mingw's libpng?

Eli Zaretskii
In reply to this post by Paul Moore
> From: Paul Moore <[hidden email]>
> Date: Thu, 7 Jul 2016 09:01:20 +0100
> Cc: [hidden email], Mingw <[hidden email]>
>
> On 7 July 2016 at 03:40, Eli Zaretskii <[hidden email]> wrote:
> >> From: Paul Moore <[hidden email]>
> >> Date: Wed, 6 Jul 2016 23:58:14 +0100
> >> Cc: Eli Zaretskii <[hidden email]>
> >>
> >> If you want to go down this route (again, not advised and not
> >> supported!) then your best bet would be to build the extension with
> >> mingw, and statically link a copy of libpng that was also built with
> >> mingw.
> >
> > I don't think this can be done on Windows.  Can you show a command
> > line that does this and works?
>
> I'm afraid I can't, for Python extensions most of the work is done by
> distutils. But I believe that some extension projects (some of the
> scientific Python stack) do this. As noted by mathog, though,
> distutils forces -lmsvcr90, which avoids most, if not all, of the CRT
> incompatibility issues - something I'd forgotten, it's been a long
> time since I did anything with the distutils mingw support..

I think the GNU linker will refuse to link a DLL against a static
library, but maybe I'm mistaken.  Libtool certainly does, AFAIR.

------------------------------------------------------------------------------
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.
http://sdm.link/attshape
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using mingw's libpng?

Earnie Boyd
On 7/7/2016 11:22 AM, Eli Zaretskii wrote:
>
> I think the GNU linker will refuse to link a DLL against a static
> library, but maybe I'm mistaken.  Libtool certainly does, AFAIR.
>

>From what I remember the binutils linker for Windows doesn't care.
Libtool does because it tries to provide portability and doing so isn't
portable.

--
Earnie

------------------------------------------------------------------------------
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.
http://sdm.link/attshape
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Using mingw's libpng?

Keith Marshall
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/07/16 18:19, Earnie wrote:
> On 7/7/2016 11:22 AM, Eli Zaretskii wrote:
>>
>> I think the GNU linker will refuse to link a DLL against a
>> static library, but maybe I'm mistaken.  Libtool certainly does,
>> AFAIR.
>
> From what I remember the binutils linker for Windows doesn't care.
>  Libtool does because it tries to provide portability and doing so
> isn't portable.

Well, I guess if you build any DLL with MinGW, you're linking with
libmingw32.a, and libmingwex.a, (at the very least), and both of these
are static libraries, so I don't understand the postulate.  As for
libtool, well, I've always found it to be unnecessarily troublesome
when building Windows libraries, anyway.

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJXfqNuAAoJEMCtNsY0flo/hcEQAIRRhtxBRHcBjAu6Co/AtxVJ
oDwOWDUR9L15FiJfRVWyZyzeWQSxN7zjcBX5BW0L5mkQfvoe9rN2Ldb4a7kbgOPi
6Y1V2R9EBiIYTqgBf5mCeyDeN5ErjwdA2/BVSx7pVqMyIQRrTAeN7SwZ+rU79vc0
rNpqIG2TqJDZtTYsy5b2ZBNI/8zMnRzh8BDr4fMs4XrFAZxz8vimpQ9GNVe169gI
Jiyu3aY/9+vhmGRqx8Fz+L5vbXwMcs8giCz2vqZsaj2kPbIyT9BQpye24qtlMuUB
D04MYrmAhNKYgXQGnYD3miYnggxE1rXtbQtx8lwuHT4o4q7t6GQL33zfQx3P6SPs
hEJUrEiI+Ep5y4qxFyH+Lfmy21pp4IGE39Ms0s3pxver5Y8HFM61JxAynuHlcG1Y
Qcz39FVPmzuQayFiIkQzpcBzweD/7aMJZRnXYJefvlZrtj1Oa3tpnyVJZq/IXWIU
0t/cd2VC0WQaFD1eV7iRgORsaJetNdn4ZxlcMyvXifbiymkD6fB/pPRl1otc4H97
ZCUBjoeINr143+NCHDuni/iSQCDRf9fUoyGsztZOsq3an4lnjNrIL+0OCvocdA4+
dbpNGa6ND/yaf023+4gTbAHpVb8d8WA/pXn2paR4uSMvVxELr1qxdSkmBscN/pJf
bwh3tO4IvEl9iVRvt9/Z
=mRiz
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
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.
http://sdm.link/attshape
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Loading...