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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ