Re: the setrlimit changes in glibc 2.1.3

[Jakub Jelinek <jakub at redhat dot com>]

On Thu, Jan 13, 2000 at 09:35:15AM -0500, Cristian Gafton wrote:
> On Thu, 13 Jan 2000, Mark Kettenis wrote:
> 
> >    No way. I don't see why I should do that.
> > 
> > Because mixing modules that use interfaces that are binary
> > incompatible is dangerous.  In the case of setrlimit, the rlim_t type
> > changed.  If both the shared library and an application that links
> > with that library use rlim_t in their communication, bad things may
> > happen if the library is using the old type and the application is
> > using the new type.
> > 
> > By the way, you should not simply rebuild the shared lib, but also
> > check if the interfaces it provides didn't change because of the
> > changes to the interface in libc.  If the interfaces did change, you
> > must bump the lib's soname or version the symbols in your library
> > itself.
> 
> All fine and dandy, now think big-time vendors and tell me how to tell
> them that all their dveelopment libraries they have put out are now
> useless. It is quite of a challenge to deal with the big folks as it is;
> if we pull a fast one like this on them it is going to become increasingly
> difficult.

Actually, it would be probably better to keep the old definitions and signed
rlim_t type in 2.1.3 and make the interface change in 2.1.90 only to avoid
the trouble.
2.1.3 setrlimit/getrlimit should internally use the old setrlimit/getrlimit
calls.
People can use setrlimit64/getrlimit64 if they need to play with limits
between 2G and 4G and 2.1.3 setrlimit64/getrlimit64 should internally use
the new setrlimit/getrlimit calls if they are available.

If people agree on this, I can post a patch.

Cheers,
    Jakub
___________________________________________________________________
Jakub Jelinek | jakub@redhat.com | http://sunsite.mff.cuni.cz/~jj
Linux version 2.3.39 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________