swupdate: switch to local config librt dependency

Upstream rejected[1] the patch added in commit 6a1aa4e2daf0 (swupdate: fix
build with older glibc). Instead of carrying this patch going forward, make
librt an extra library dependency in the Buildroot local swupdate .config.

This solution is somewhat less optimal than the patch, because it always adds
librt regardless of whether SURICATTA_HAWKBIT is enabled. In theory we could
add a test for (BR2_PACKAGE_JSON_C && BR2_PACKAGE_LIBCURL), which are the
SURICATTA_HAWKBIT dependencies, and edit .config at build time. But this adds
much complexity for little gain.

[1] https://groups.google.com/forum/?hl=en#!topic/swupdate/77QWIka27es

Cc: Jörg Krause <joerg.krause@embedded.rocks>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---

With glibc 2.17 being 4.5 years old, upstream maintainers start to push back
on these librt patches. Is it time to stop support for external toolchains
with older glibc? This means retiring CodeSourcery x86 and SH toolchains.
---
 ...ags-SURICATTA_HAWKBIT-needs-librt-under-o.patch | 34 ----------------------
 package/swupdate/swupdate.config                   |  2 +-
 2 files changed, 1 insertion(+), 35 deletions(-)
 delete mode 100644 package/swupdate/0002-Makefile.flags-SURICATTA_HAWKBIT-needs-librt-under-o.patch

Hello,

On Thu,  8 Jun 2017 19:29:06 +0300, Baruch Siach wrote:
> Upstream rejected[1] the patch added in commit 6a1aa4e2daf0 (swupdate: fix
> build with older glibc). Instead of carrying this patch going forward, make
> librt an extra library dependency in the Buildroot local swupdate .config.
> 
> This solution is somewhat less optimal than the patch, because it always adds
> librt regardless of whether SURICATTA_HAWKBIT is enabled. In theory we could
> add a test for (BR2_PACKAGE_JSON_C && BR2_PACKAGE_LIBCURL), which are the
> SURICATTA_HAWKBIT dependencies, and edit .config at build time. But this adds
> much complexity for little gain.
> 
> [1] https://groups.google.com/forum/?hl=en#!topic/swupdate/77QWIka27es
> 
> Cc: Jörg Krause <joerg.krause@embedded.rocks>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>

Applied. Thanks!

> With glibc 2.17 being 4.5 years old, upstream maintainers start to push back
> on these librt patches. Is it time to stop support for external toolchains
> with older glibc? This means retiring CodeSourcery x86 and SH toolchains.

That's a good question. I think supporting relatively old
configurations is a strength of Buildroot, so I try to be careful when
removing support for old stuff. But maybe glibc 2.17 is now really too
old.

Thoughts of other developers?

Best regards,

Thomas

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 >> With glibc 2.17 being 4.5 years old, upstream maintainers start to push back
 >> on these librt patches. Is it time to stop support for external toolchains
 >> with older glibc? This means retiring CodeSourcery x86 and SH toolchains.

 > That's a good question. I think supporting relatively old
 > configurations is a strength of Buildroot, so I try to be careful when
 > removing support for old stuff. But maybe glibc 2.17 is now really too
 > old.

 > Thoughts of other developers?

As always, it is a tradeoff. We have already removed gcc 4.8 (released
March 2013) even though older bootloader/kernels tend to break when
built with "too new" gcc versions.

I don't recall the same level of breakage when moving to newer glibc
versions. Is there any reason to stay with 2.17 instead of newer
version (incompatibility/bloat/..)? 2.17 presumably is also missing a
number of security fixes and nice new features.

I suggest we stop caring about these ancient <= 2.17 glibc versions when
we introduce 2.26, especially if upstream doesn't want these fixes any
more.

Hi Peter,

On Thu, Jun 08, 2017 at 09:59:47PM +0200, Peter Korsgaard wrote:
> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>  >> With glibc 2.17 being 4.5 years old, upstream maintainers start to push back
>  >> on these librt patches. Is it time to stop support for external toolchains
>  >> with older glibc? This means retiring CodeSourcery x86 and SH toolchains.
> 
>  > That's a good question. I think supporting relatively old
>  > configurations is a strength of Buildroot, so I try to be careful when
>  > removing support for old stuff. But maybe glibc 2.17 is now really too
>  > old.
> 
>  > Thoughts of other developers?
> 
> As always, it is a tradeoff. We have already removed gcc 4.8 (released
> March 2013) even though older bootloader/kernels tend to break when
> built with "too new" gcc versions.
> 
> I don't recall the same level of breakage when moving to newer glibc
> versions. Is there any reason to stay with 2.17 instead of newer
> version (incompatibility/bloat/..)? 2.17 presumably is also missing a
> number of security fixes and nice new features.
> 
> I suggest we stop caring about these ancient <= 2.17 glibc versions when
> we introduce 2.26, especially if upstream doesn't want these fixes any
> more.

A small correction: only glibc versions < 2.17 are affected. glibc 2.17 is 
fine.

As far as I understand, the only change we need to do in Buildroot code itself 
if we are to stop support for glibc older than 2.17, is to drop CodeSourcery 
x86 and SH toolchains. That would leave us with no external toolchain for 
these architectures. Is that OK?

baruch

>>>>> "Baruch" == Baruch Siach <baruch@tkos.co.il> writes:

Hi,

 >> I suggest we stop caring about these ancient <= 2.17 glibc versions when
 >> we introduce 2.26, especially if upstream doesn't want these fixes any
 >> more.

 > A small correction: only glibc versions < 2.17 are affected. glibc 2.17 is 
 > fine.

Sorry, so then we're looking at 2.16 from mid-2012.

 > As far as I understand, the only change we need to do in Buildroot code itself 
 > if we are to stop support for glibc older than 2.17, is to drop CodeSourcery 
 > x86 and SH toolchains. That would leave us with no external toolchain for 
 > these architectures. Is that OK?

It is not perfect, but only offering these ancient toolchains aren't
really either. I don't think it is really bad as buildroot can build
nice modern toolchains for those archs, but if we could find some newer
external toolchains then that would certainly be a plus.