netdev - Re: [PATCH iproute2] ss: fix compilation under glibc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20190221144926.1bab45f6@shemminger-XPS-13-9360>
Date:   Thu, 21 Feb 2019 14:49:26 -0800
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Thomas De Schampheleire <patrickdepinguin@...il.com>
Cc:     netdev@...r.kernel.org,
        Thomas De Schampheleire <thomas.de_schampheleire@...ia.com>
Subject: Re: [PATCH iproute2] ss: fix compilation under glibc < 2.18

On Thu, 21 Feb 2019 08:43:08 +0100
Thomas De Schampheleire <patrickdepinguin@...il.com> wrote:

> El jue., 21 feb. 2019 a las 2:53, Stephen Hemminger
> (<stephen@...workplumber.org>) escribió:
> >
> > On Wed, 20 Feb 2019 15:41:51 +0100
> > Thomas De Schampheleire <patrickdepinguin@...il.com> wrote:
> >  
> > > From: Thomas De Schampheleire <thomas.de_schampheleire@...ia.com>
> > >
> > > Commit c759116a0b2b6da8df9687b0a40ac69050132c77 introduced support for
> > > AF_VSOCK. This define is only provided since glibc version 2.18, so
> > > compilation fails when using older toolchains.
> > >
> > > Provide the necessary definitions if needed.
> > >
> > > Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@...ia.com>  
> >
> > Not sure why you would want new iproute2 with a 5 year old version of glibc?
> > Yes that means update your tool chain.
> >  
> 
> This problem is noticed for an embedded system. It has up-to-date
> applications and libraries (built via Buildroot) but the toolchain and
> kernel are supplied by the SoC vendor (in this case Marvell, formerly
> Cavium Networks). Unfortunately their toolchain is lagging behind and
> is still using glibc 2.16.
> 
> I could handle this patch locally, but I think there may be other
> people in a similar situation which would benefit from an upstream
> fix.

OK applied, just don't want to keep lots of old cruft in the code
since it can lead to future suprise bugs.