Package Details: mingw-w64-libpng 1.6.37-1

Git Clone URL: (read-only, click to copy)
Package Base: mingw-w64-libpng
Description: A collection of routines used to create PNG format graphics (mingw-w64)
Upstream URL:
Licenses: custom
Submitter: ekpyron
Maintainer: xantares
Last Packager: xantares
Votes: 24
Popularity: 0.088458
First Submitted: 2012-03-22 22:58 (UTC)
Last Updated: 2019-10-23 17:19 (UTC)

Latest Comments

drakkan commented on 2019-09-07 17:27 (UTC)

Can you please fix the PKGBUILD replacing

patch -p0 -i "${srcdir}/libpng-$_apngver-apng.patch"


zcat "${srcdir}/libpng-$_apngver-apng.patch" | patch -p0

as suggested before? thanks

donotdont commented on 2019-07-06 11:10 (UTC) (edited on 2019-07-06 11:11 (UTC) by donotdont)

i click download file on "Download snapshot" and run this commands:

makepkg -Acs

to fix error: extract file "src/libpng-1.6.37-apng.patch.gz" -> "libpng-1.6.37-apng.patch"

for me it's working.

luntik2012 commented on 2019-05-31 11:47 (UTC)

zcat "${srcdir}/libpng-$_apngver-apng.patch" | patch -p0

worked for me

pingplug commented on 2019-05-26 01:22 (UTC)

makepkg did not extract patch any more...

==> Extracting sources...
  -> Extracting libpng-1.6.37.tar.xz with bsdtar
==> Starting prepare()...
patch: **** Can't open patch file /tmp/makepkg/mingw-w64-libpng/src/libpng-1.6.37-apng.patch : No such file or directory
==> ERROR: A failure occurred in prepare().

gamezelda commented on 2019-05-23 19:07 (UTC)

Hello, the build (both yay and manual) is failing for me due to the 'patch' command in prepare() not finding the uncompressed patch file.

Not sure why the patch is not actually uncompressed, because I know makepkg uncompresses sources in some cases.

Anyway, I fixed the build by replacing the 'patch' command in prepare with:

zcat "${srcdir}/libpng-$_apngver-apng.patch" | patch -p0

xantares commented on 2014-11-14 14:03 (UTC)

and with regular packages archlinux sets its own flags too, hence the 'buildflags' option, as they're not compatible with mingw

ekpyron commented on 2014-11-14 13:09 (UTC)

Well, I do understand the flags - basically they are all about hardening security and as such are actually reasonable - I was just wondering where they were coming from and why one would set them automatically instead of letting users set them as they like, but I suppose Fedora is a reasonable reference, yes, so I'll start using them for my packages as well, thanks.

xantares commented on 2014-11-14 13:03 (UTC)

I don't know the significance of all "-g -O2" is obvious, FORTIFY_SOURCE adds security to basic libc function against overflow etc, ... Basically it's the ones of Fedora, and it's doesn't seem unreasonable flags. xan.

ekpyron commented on 2014-11-14 12:02 (UTC)

Although you put them there yourself... I'd still like to know what's the reasoning behind using these flags and especially why it makes sense to force users to set these flags...

ekpyron commented on 2014-11-14 11:48 (UTC)

OK, they are suggested in the MinGW package guidelines... well I suppose it can't hurt...

ekpyron commented on 2014-11-14 11:27 (UTC)

@xantares What makes you say that the flags you're setting in your mingw-w64-configure script are the "right compilation flags"? I see no reason why it would be "right" to use those...

xantares commented on 2014-11-14 10:56 (UTC)

hi, would you mind using the mingw-w64-configure script ? it would set the right compilation flags, thanks. xan.

stativ commented on 2014-06-03 10:30 (UTC)

mingw-w64-libpng-static merged to mingw-w64-libpng

Schala commented on 2013-11-02 05:57 (UTC)

mingw-w64-libpng already has a static lib in addition to a DLL import lib

ant32 commented on 2013-10-28 23:39 (UTC)

!libtool isn't needed anymore since it is the default now.

ekpyron commented on 2013-10-07 13:11 (UTC)

@xantares Thank you, I added !libtool to options, so they should be gone now.

xantares commented on 2013-10-07 12:36 (UTC)

Hi, There are useless libtool (.la) files in arch/lib x.

Schala commented on 2013-07-23 21:27 (UTC)

Well I suppose having wine is a temporary workaround.

ekpyron commented on 2013-07-23 21:15 (UTC)

@Schala, yes I know, but as I modified the package, the flag was unset again. I didn't update to 1.6.3 earlier, because libpng had not yet been updated in [core]. I now updated the package, but I'm experiencing a (mild) problem with it: it seems to try and execute some target executable (wine is started in my case) while building. As so far it doesn't look like this is actually interfering with the build, I still update the package, but I don't have the time to have a detailed look at this right now. I'd appreciate any comments.

Schala commented on 2013-07-23 20:48 (UTC)

It's not that the download link isn't working. I flagged it because 1.6.3 is out

ant32 commented on 2013-07-23 15:54 (UTC)

I'm really sorry. I had meant to post it to the mingw32-libpng repo

ekpyron commented on 2013-07-23 15:27 (UTC)

For me the xz archive is working... Is the package "xz" installed on your system? I think it is normally installed, that's why I used the smaller package... I added it to the makedepends to be sure...

ant32 commented on 2013-07-23 13:40 (UTC)

The download link is not working for me. Could you please verify? This link is working for me$pkgver.tar.gz