Re: prlimit64: inconsistencies between kernel and userland

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxx


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux