Patchwork gdk-pixbuf: Fix libpng determinism issues

login
register
mail settings
Submitter Colin Walters
Date April 15, 2013, 10:08 a.m.
Message ID <1366020508.2896.16.camel@localhost>
Download mbox | patch
Permalink /patch/48181/
State New
Headers show

Comments

Colin Walters - April 15, 2013, 10:08 a.m.
On Sun, 2013-04-14 at 16:33 +0100, Richard Purdie wrote:
> On Sun, 2013-04-14 at 09:02 -0400, Colin Walters wrote:
> The more interesting change is:
> 
> https://git.gnome.org/browse/gdk-pixbuf/commit/configure.ac?id=d430bc4df3314a88cd538474d26ff7764d1f408c
> 
> and following that to the bugzilla 'For this to make sense, I changed
> the order so that a version specific dep, such as libpng15 or
> libpng12,
> is found before just "libpng".'
> 
> I'm not sure I entirely follow that logic.

I added Matthias to CC as he touched this last then.

> I think the intent of the symlink is to provide the system with a
> default libpng to use in the absence of a specific version requirement.
> As the code stands today, each time a new libpng comes out, gdk-pixbuf
> will need changes before it will be able to use it. 

Right, we need configure.ac changes, but the rationale behind that is
that we'd also need *code* changes for each new major version of libpng.
But it sounds like what you're saying is that gdk-pixbuf compiles and
operates correctly with 1.6?  If that's the case, then the least
invasive change here is to simply add 1.6.

Blah, I tried changing the gnome-ostree build to fetch libpng's v1.6.1
git tag to test, but it hard requires Automake 1.13.

Anyways, if it works (looks like the latest oe-core has it), then
what about the attached?

> In the meantime, it
> will potentially link against something old, e.g. 1.2, since 1.2 is in
> the LSB 4.X spec so most LSB like systems would have 1.6 and 1.2.
> 
> If we can justify changing this upstream, that would be great :). It may
> be worth adding libpng16 into the list too so everything is covered too.

At this point I'm hoping the parade of libpng versions will
settle down, so hopefully no further tweaking of the configure script or
code will be required...
Koen Kooi - April 15, 2013, 10:14 a.m.
Op 15 apr. 2013, om 12:08 heeft Colin Walters <walters@verbum.org> het volgende geschreven:

> On Sun, 2013-04-14 at 16:33 +0100, Richard Purdie wrote:
>> On Sun, 2013-04-14 at 09:02 -0400, Colin Walters wrote:
>> The more interesting change is:
>> 
>> https://git.gnome.org/browse/gdk-pixbuf/commit/configure.ac?id=d430bc4df3314a88cd538474d26ff7764d1f408c
>> 
>> and following that to the bugzilla 'For this to make sense, I changed
>> the order so that a version specific dep, such as libpng15 or
>> libpng12,
>> is found before just "libpng".'
>> 
>> I'm not sure I entirely follow that logic.
> 
> I added Matthias to CC as he touched this last then.
> 
>> I think the intent of the symlink is to provide the system with a
>> default libpng to use in the absence of a specific version requirement.
>> As the code stands today, each time a new libpng comes out, gdk-pixbuf
>> will need changes before it will be able to use it. 
> 
> Right, we need configure.ac changes, but the rationale behind that is
> that we'd also need *code* changes for each new major version of libpng.
> But it sounds like what you're saying is that gdk-pixbuf compiles and
> operates correctly with 1.6?  If that's the case, then the least
> invasive change here is to simply add 1.6.
> 
> Blah, I tried changing the gnome-ostree build to fetch libpng's v1.6.1
> git tag to test, but it hard requires Automake 1.13.

Only for parallel unit tests, I just sent a patch to update libpng to v1.6.1 to oe-core. It doesn't fix the problems I'm having with PNGs in weston, so please test it and see if it fixed any of your problems.

regards,

Koen

> 
> Anyways, if it works (looks like the latest oe-core has it), then
> what about the attached?
> 
>> In the meantime, it
>> will potentially link against something old, e.g. 1.2, since 1.2 is in
>> the LSB 4.X spec so most LSB like systems would have 1.6 and 1.2.
>> 
>> If we can justify changing this upstream, that would be great :). It may
>> be worth adding libpng16 into the list too so everything is covered too.
> 
> At this point I'm hoping the parade of libpng versions will
> settle down, so hopefully no further tweaking of the configure script or
> code will be required...
> 
> 
> <0001-build-We-also-support-libpng16.patch>_______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Richard Purdie - April 15, 2013, 11:31 a.m.
On Mon, 2013-04-15 at 06:08 -0400, Colin Walters wrote:
> On Sun, 2013-04-14 at 16:33 +0100, Richard Purdie wrote:
> > On Sun, 2013-04-14 at 09:02 -0400, Colin Walters wrote:
> > The more interesting change is:
> > 
> > https://git.gnome.org/browse/gdk-pixbuf/commit/configure.ac?id=d430bc4df3314a88cd538474d26ff7764d1f408c
> > 
> > and following that to the bugzilla 'For this to make sense, I changed
> > the order so that a version specific dep, such as libpng15 or
> > libpng12,
> > is found before just "libpng".'
> > 
> > I'm not sure I entirely follow that logic.
> 
> I added Matthias to CC as he touched this last then.
> 
> > I think the intent of the symlink is to provide the system with a
> > default libpng to use in the absence of a specific version requirement.
> > As the code stands today, each time a new libpng comes out, gdk-pixbuf
> > will need changes before it will be able to use it. 
> 
> Right, we need configure.ac changes, but the rationale behind that is
> that we'd also need *code* changes for each new major version of libpng.
> But it sounds like what you're saying is that gdk-pixbuf compiles and
> operates correctly with 1.6?  If that's the case, then the least
> invasive change here is to simply add 1.6.

It compiles and operates correctly as far as we can tell, yes.

Given that rationale, I'd suggest "libpng" should be dropped from the
list.

> Blah, I tried changing the gnome-ostree build to fetch libpng's v1.6.1
> git tag to test, but it hard requires Automake 1.13.
> 
> Anyways, if it works (looks like the latest oe-core has it), then
> what about the attached?

It will make our builds work again for now until the next time someone
upgrades libpng and and then it will potentially silently start using an
old version in some builds :(.

We're therefore probably going to get stuck carrying a patch for
this :/.

> > In the meantime, it
> > will potentially link against something old, e.g. 1.2, since 1.2 is in
> > the LSB 4.X spec so most LSB like systems would have 1.6 and 1.2.
> > 
> > If we can justify changing this upstream, that would be great :). It may
> > be worth adding libpng16 into the list too so everything is covered too.
> 
> At this point I'm hoping the parade of libpng versions will
> settle down, so hopefully no further tweaking of the configure script or
> code will be required...

Its the case things silently break that really worry me.

Cheers,

Richard

Patch

From 829379cfa2b48e966125df2d070d2af40cb3f990 Mon Sep 17 00:00:00 2001
From: Colin Walters <walters@verbum.org>
Date: Mon, 15 Apr 2013 05:59:09 -0400
Subject: [PATCH] build: We also support libpng16

See http://lists.linuxtogo.org/pipermail/openembedded-core/2013-April/038321.html
---
 configure.ac |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/configure.ac b/configure.ac
index 8ec8b1f..106fab1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -586,7 +586,7 @@  fi
 
 dnl Test for libpng
   if test x$with_libpng != xno && test -z "$LIBPNG"; then
-    for l in libpng15 libpng14 libpng12 libpng13 libpng10 libpng ; do
+    for l in libpng16 libpng15 libpng14 libpng12 libpng13 libpng10 libpng; do
       AC_MSG_CHECKING(for $l)
       if $PKG_CONFIG --exists $l ; then
         AC_MSG_RESULT(yes)
-- 
1.7.1