On Mon, 4 Nov 2013, David Miller wrote: > From: Aurelien Jarno <aurelien@xxxxxxxxxxx> > Date: Mon, 4 Nov 2013 22:37:56 +0100 > > > Any news about this issue? It really starts to causes a lot of issues in > > Debian. I have added a Cc: to libc people so that we can also hear their > > opinion. > > I had the same exact problem on sparc several years ago, I simply fixed > the glibc header value, it's the only way to fix this. > > Yes, that means you then have to recompile applications and libraries > that reference this value. Surely you can create new symbol versions for getrlimit64 and setrlimit64, with the old versions just using the 32-bit syscalls (or otherwise translating between conventions, but using the 32-bit syscalls is the simplest approach)? I see no need to break compatibility with existing binaries. As I noted in <https://sourceware.org/ml/libc-ports/2006-05/msg00020.html>, at that time the value of RLIM64_INFINITY for o32/n32 was purely a glibc convention the kernel didn't see at all. It's only with the use of newer syscalls that this glibc convention is any sort of problem. -- Joseph S. Myers joseph@xxxxxxxxxxxxxxxx
