[1/1] package/libpng: allow selection of older libpng versions
diff mbox series

Message ID 20190707165224.31438-1-paul@crapouillou.net
State Rejected
Headers show
Series
  • [1/1] package/libpng: allow selection of older libpng versions
Related show

Commit Message

Paul Cercueil July 7, 2019, 4:52 p.m. UTC
By allowing building an older version of libpng, we can create Buildroot
systems that are still binary-compatible with applications compiled with
older Buildroot toolchains.

Signed-off-by: Paul Cercueil <paul@crapouillou.net>
---
 .../0001-Disable-pngfix-and-png-fix-itxt.patch    |  0
 package/libpng/Config.in                          | 15 +++++++++++++++
 package/libpng/libpng.hash                        |  2 ++
 package/libpng/libpng.mk                          | 11 +++++++++++
 4 files changed, 28 insertions(+)
 rename package/libpng/{ => 1.6.37}/0001-Disable-pngfix-and-png-fix-itxt.patch (100%)

Comments

Thomas Petazzoni July 21, 2019, 1:49 p.m. UTC | #1
Hello Paul,

+Yann, Arnout, Peter in Cc.

On Sun,  7 Jul 2019 12:52:24 -0400
Paul Cercueil <paul@crapouillou.net> wrote:

> By allowing building an older version of libpng, we can create Buildroot
> systems that are still binary-compatible with applications compiled with
> older Buildroot toolchains.
> 
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>

While I understand what you're trying to do, I'm not sure it's a
reasonable goal for Buildroot to be able to provide binary
compatibility between systems generated by different Buildroot
versions. We regularly update libraries to their latest upstream
versions, and sometimes they break the ABI compatibility. I don't think
we want to enter the game of ensuring that ABI compatibility is ensured
between Buildroot versions.

If you're building a program with a given Buildroot SDK, it should be
executed on the Buildroot system that matches that SDK.

Best regards,

Thomas
Yann E. MORIN July 21, 2019, 2:22 p.m. UTC | #2
Thomas, Paul, Al,

On 2019-07-21 15:49 +0200, Thomas Petazzoni spake thusly:
> On Sun,  7 Jul 2019 12:52:24 -0400
> Paul Cercueil <paul@crapouillou.net> wrote:
> > By allowing building an older version of libpng, we can create Buildroot
> > systems that are still binary-compatible with applications compiled with
> > older Buildroot toolchains.
> While I understand what you're trying to do, I'm not sure it's a
> reasonable goal for Buildroot to be able to provide binary
> compatibility between systems generated by different Buildroot
> versions. We regularly update libraries to their latest upstream
> versions, and sometimes they break the ABI compatibility. I don't think
> we want to enter the game of ensuring that ABI compatibility is ensured
> between Buildroot versions.

Agreed.

> If you're building a program with a given Buildroot SDK, it should be
> executed on the Buildroot system that matches that SDK.

Agreed.

Regards,
Yann E. MORIN.
Paul Cercueil July 21, 2019, 4:51 p.m. UTC | #3
Le dim. 21 juil. 2019 à 10:22, "Yann E. MORIN" 
<yann.morin.1998@free.fr> a écrit :
> Thomas, Paul, Al,
> 
> On 2019-07-21 15:49 +0200, Thomas Petazzoni spake thusly:
>>  On Sun,  7 Jul 2019 12:52:24 -0400
>>  Paul Cercueil <paul@crapouillou.net> wrote:
>>  > By allowing building an older version of libpng, we can create 
>> Buildroot
>>  > systems that are still binary-compatible with applications 
>> compiled with
>>  > older Buildroot toolchains.
>>  While I understand what you're trying to do, I'm not sure it's a
>>  reasonable goal for Buildroot to be able to provide binary
>>  compatibility between systems generated by different Buildroot
>>  versions. We regularly update libraries to their latest upstream
>>  versions, and sometimes they break the ABI compatibility. I don't 
>> think
>>  we want to enter the game of ensuring that ABI compatibility is 
>> ensured
>>  between Buildroot versions.
> 
> Agreed.

Honestly, in our case the only thing needed to support apps compiled 
with Buildroot 2014.05 with the new Buildroot 2019.02.1 is this patch, 
and a few symlinks in /lib (since libm/librt/etc. are gone). 
Thanksfully the major version of libraries doesn't change that often.


>>  If you're building a program with a given Buildroot SDK, it should 
>> be
>>  executed on the Buildroot system that matches that SDK.
> 
> Agreed.

Then that means we're stuck with a 2014.05 Buildroot and cannot 
contribute to upstream Buildroot development. It's not ideal.


> Regards,
> Yann E. MORIN.
> 
> --
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' 
> conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___      
>          |
> | +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  
> There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   
> conspiracy.  |
> '------------------------------^-------^------------------^--------------------'
Yann E. MORIN July 21, 2019, 5:15 p.m. UTC | #4
Paul, All,

On 2019-07-21 12:51 -0400, Paul Cercueil spake thusly:
> Le dim. 21 juil. 2019 à 10:22, "Yann E. MORIN" <yann.morin.1998@free.fr> a
> écrit :
> >On 2019-07-21 15:49 +0200, Thomas Petazzoni spake thusly:
> >> On Sun,  7 Jul 2019 12:52:24 -0400
> >> Paul Cercueil <paul@crapouillou.net> wrote:
> >> > By allowing building an older version of libpng, we can create
> >>Buildroot
> >> > systems that are still binary-compatible with applications compiled
> >>with
> >> > older Buildroot toolchains.
> >> While I understand what you're trying to do, I'm not sure it's a
> >> reasonable goal for Buildroot to be able to provide binary
> >> compatibility between systems generated by different Buildroot
> >> versions. We regularly update libraries to their latest upstream
> >> versions, and sometimes they break the ABI compatibility. I don't think
> >> we want to enter the game of ensuring that ABI compatibility is ensured
> >> between Buildroot versions.
> >
> >Agreed.
> 
> Honestly, in our case the only thing needed to support apps compiled with

As you said yourself, this is in *your* case. Other may have other
cases, see below...

> Buildroot 2014.05 with the new Buildroot 2019.02.1 is this patch, and a few
> symlinks in /lib (since libm/librt/etc. are gone). Thanksfully the major
> version of libraries doesn't change that often.

Well, then you'll probably also want to do the same for openssl, as
openssl 1.1 is not entirely compatible with older versions. And what is
the next library?

> >> If you're building a program with a given Buildroot SDK, it should be
> >> executed on the Buildroot system that matches that SDK.
> >
> >Agreed.
> 
> Then that means we're stuck with a 2014.05 Buildroot and cannot contribute
> to upstream Buildroot development. It's not ideal.

But then why don't you recompile your applications in the new Buildroot?

If you really, like really-really, are stuck with applications that you
can't recompile, then create a new package in your br2-external tree,
libpgn12 (or 14...) and enable that. Still in _your_ case, you are
lucky: the actual SONAME of the library is libpng16.so.16 and so will
not conflict with the real libpng (should you have to _also_ enable it).

Regards,
Yann E. MORIN.

Patch
diff mbox series

diff --git a/package/libpng/0001-Disable-pngfix-and-png-fix-itxt.patch b/package/libpng/1.6.37/0001-Disable-pngfix-and-png-fix-itxt.patch
similarity index 100%
rename from package/libpng/0001-Disable-pngfix-and-png-fix-itxt.patch
rename to package/libpng/1.6.37/0001-Disable-pngfix-and-png-fix-itxt.patch
diff --git a/package/libpng/Config.in b/package/libpng/Config.in
index b0a3646078..099492c07c 100644
--- a/package/libpng/Config.in
+++ b/package/libpng/Config.in
@@ -6,3 +6,18 @@  config BR2_PACKAGE_LIBPNG
 	  images.
 
 	  http://www.libpng.org/
+
+choice
+	prompt "libpng version series"
+	default BR2_PACKAGE_LIBPNG_16
+
+config BR2_PACKAGE_LIBPNG_16
+	bool "libpng 1.6"
+
+config BR2_PACKAGE_LIBPNG_14
+	bool "libpng 1.4"
+
+config BR2_PACKAGE_LIBPNG_12
+	bool "libpng 1.2"
+
+endchoice
diff --git a/package/libpng/libpng.hash b/package/libpng/libpng.hash
index e86b8c65ce..c4bfc812cb 100644
--- a/package/libpng/libpng.hash
+++ b/package/libpng/libpng.hash
@@ -2,5 +2,7 @@ 
 md5 015e8e15db1eecde5f2eb9eb5b6e59e9  libpng-1.6.37.tar.xz
 sha1 3ab93fabbf4c27e1c4724371df408d9a1bd3f656  libpng-1.6.37.tar.xz
 # Locally computed:
+sha256 b4635f15b8adccc8ad0934eea485ef59cc4cae24d0f0300a9a941e51974ffcc7  libpng-1.2.59.tar.xz
+sha256 8d419a8b2a5edddda5cbcb897ded92205344a3249fa7a00d6384ea23ac3ccbd8  libpng-1.4.22.tar.xz
 sha256 505e70834d35383537b6491e7ae8641f1a4bed1876dbfe361201fc80868d88ca  libpng-1.6.37.tar.xz
 sha256 bf5e22b9dce8464064ae17a48ea1133c3369ac9e1d80ef9e320e5219aa14ea9b  LICENSE
diff --git a/package/libpng/libpng.mk b/package/libpng/libpng.mk
index 5c30a4f9ad..2a89595006 100644
--- a/package/libpng/libpng.mk
+++ b/package/libpng/libpng.mk
@@ -4,8 +4,19 @@ 
 #
 ################################################################################
 
+ifeq ($(BR2_PACKAGE_LIBPNG_16),y)
 LIBPNG_VERSION = 1.6.37
 LIBPNG_SERIES = 16
+else
+ifeq ($(BR2_PACKAGE_LIBPNG_14),y)
+LIBPNG_VERSION = 1.4.22
+LIBPNG_SERIES = 14
+else
+LIBPNG_VERSION = 1.2.59
+LIBPNG_SERIES = 12
+endif
+endif
+
 LIBPNG_SOURCE = libpng-$(LIBPNG_VERSION).tar.xz
 LIBPNG_SITE = http://downloads.sourceforge.net/project/libpng/libpng$(LIBPNG_SERIES)/$(LIBPNG_VERSION)
 LIBPNG_LICENSE = Libpng-2.0