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

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%)

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

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.

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

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.