Re: Undo setrlimit patch for 2.1.3

["H . J . Lu" <hjl at lucon dot org>]

On Sun, Jan 23, 2000 at 06:21:06PM +0100, Thorsten Kukuk wrote:
> > 
> > I thought it was handled by the symbol versioning and I had fixed the
> > linker to do the right thing. Do you have a testcase to show that
> > glibc 2.1.3 is binary incompatible with glibc 2.1.2? Are you talking
						         ^^^^^^^^^^^^^^
> > about binaries compiled against glibc 2.1.3 won't run with glibc 2.1.2?
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > As you may know, it is true even if the setrlimit changes are backed
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > out, due to those new symbols with version GLIBC_2.1.3.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Try the following: Compile bash with glibc 2.1.3 and let them run on
> a glibc 2.1.2 system. It complains about setrlimit 2.1.3.
> But there is no difference between this setrlimit versions, since 
> distributors uses linux kernel 2.2.x, not unstable 2.3.x.
> The other problem is, that a software vendor, if he uses glibc 2.1.3,

I know. That has been true for glibc 2.0, 2.1, 2.1.1, and 2.1.2. It
will be true for 2.1.3 and 2.2. Everytime when we introduce a new
symbol version, it will happen. Removing the setrlimit change won't
help you on that since there are many other symbols using GLIBC_2.1.3.

> cannot sell his software for 2.1.2 or 2.1.1. He needs an old system
> with glibc 2.1 for compiling.
> 

You didn't answer my question. Please read my email again. I
have highlighted it for you.


H.J.