Re: Undo setrlimit patch for 2.1.3

[Thorsten Kukuk <kukuk at suse dot de>]

On Sun, Jan 23, H . J . Lu wrote:

> 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.

No. The only external symbol with a new VERSION number is setrlimit,
getrlimit, setrlimit64 and getrlimit64. No others. It works perfect
without this new versions. The other functions are only for internal
use by linuxthreads. So, if you use the same libc/libpthread version,
binaries compiled on glibc 2.1.3 will now run again with glibc 2.1.2,
because the interface is binary compatible between this both versions.
Breaking this for one function without new functionality with current,
stable kernels is something we can avoid here.

The only, good reason for this break is, if you say glibc 2.1.3 will
be the very last version of 2.1.x, and glibc 2.2 will not come this
year. But I hope glibc 2.2 will be ready at the time kernel 2.4 is
released (and we should try this because of 32bit uid_t).

  Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/       kukuk@suse.de
SuSE GmbH            Schanzaeckerstr. 10            90443 Nuernberg
Linux is like a Vorlon.  It is incredibly powerful, gives terse,
cryptic answers and has a lot of things going on in the background.