linux-mips
[Top] [All Lists]

Re: prlimit64: inconsistencies between kernel and userland

To: Andreas Schwab <schwab@linux-m68k.org>
Subject: Re: prlimit64: inconsistencies between kernel and userland
From: Rich Felker <dalias@aerifal.cx>
Date: Tue, 5 Nov 2013 18:55:05 -0500
Cc: "Joseph S. Myers" <joseph@codesourcery.com>, David Daney <ddaney.cavm@gmail.com>, "Pinski, Andrew" <Andrew.Pinski@caviumnetworks.com>, Andreas Barth <aba@ayous.org>, David Miller <davem@davemloft.net>, aurelien@aurel32.net, linux-mips@linux-mips.org, libc-alpha@sourceware.org
In-reply-to: <87ppqez9sh.fsf@igel.home>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20131104213756.GD18700@hall.aurel32.net> <20131104.194519.1657797548878784116.davem@davemloft.net> <Pine.LNX.4.64.1311050058580.9883@digraph.polyomino.org.uk> <20131105012203.GA24286@brightrain.aerifal.cx> <20131105085859.GE28240@mails.so.argh.org> <20131105183732.GB24286@brightrain.aerifal.cx> <52793C50.9030300@gmail.com> <Pine.LNX.4.64.1311052234420.30260@digraph.polyomino.org.uk> <20131105223953.GG24286@brightrain.aerifal.cx> <87ppqez9sh.fsf@igel.home>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.21 (2010-09-15)
On Wed, Nov 06, 2013 at 12:52:14AM +0100, Andreas Schwab wrote:
> Rich Felker <dalias@aerifal.cx> writes:
> 
> > BTW, what happens on a distro where -dev packages are separate and the
> > user compiles with old headers (not having upgraded the dev package)
> > but new libc.so? :-)
> 
> The devel package must either be self-contained or require the matching
> non-devel package.

That doesn't help. The problem is that the non-devel package gets
upgraded and ldconfig re-links the .so to the .so.X.Y.Z for the new
version. Really, the problem is ldconfig. If the .so link were
correctly created by the devel package, rather than by ldconfig, then
the headers and link-time library version would always match.

So, in short, ldconfig considered harmful.

Rich

<Prev in Thread] Current Thread [Next in Thread>