This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: prlimit64: inconsistencies between kernel and userland


On Tue, 5 Nov 2013, Rich Felker wrote:

> On Tue, Nov 05, 2013 at 10:36:24PM +0000, Joseph S. Myers wrote:
> > On Tue, 5 Nov 2013, David Daney wrote:
> > 
> > > Why can't the default version of the functions in question be fixed so that
> > > they do the right thing?  That way you wouldn't have to rebuild old binaries.
> > > 
> > > Do we really need new function versions at all?
> > 
> > If we change RLIM64_INFINITY to match the kernel, then the right thing for 
> > at least getrlimit64 depends on whether it's an old or new binary (for old 
> > binaries it should return the old value of RLIM64_INFINITY and for new 
> > ones it should return the new value).
> 
> 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? :-)

That's a bug in the distribution packaging that it allows such 
inconsistent versions.  glibc only supports the case when the static-link 
stage happens against the same glibc version as the headers that were used 
(static libraries built with old headers are expected to break whenever 
there's some ABI change made through symbol versioning).

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]