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

[Yann E. MORIN <yann.morin.1998@free.fr>]

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.

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