Re: glibc 2.1 progress

[Steve Dunham <dunham@cse.msu.edu>]

Ben Collins <bmc@visi.net> writes:

(The big problems are at the end.)

> Well, after finding out that this new glibc 2.1 without the chown patch
> will also break X, I've changed my opinion slightly.

Does it break X if you recompile X?  (I would doubt it, since X works
with 2.1.1 on Red Hat.)

> I'm going to apply the patch and see how it works with that.

We could have a problem here:

# objdump -T redhat/libc-2.1.1.so |grep chown
0000000000098938  w   DF .text  0000000000000000  GLIBC_2.0   fchown
000000000009896c  w   DF .text  0000000000000000  GLIBC_2.0   lchown
0000000000098904  w   DF .text  0000000000000000  GLIBC_2.0   chown
#

where "redhat/libc-2.1.1.so" is from Red Hat's 5.9 sparc distribution.
If you apply the patch, binaries compiled on Debian systems will not
run on Red Hat systems.  (We will then have to tell people like
netscape that they should compile on Red Hat systems.)


For the sake of completeness, I did:

  # objdump -T redhat/libc-2.1.1.so | \
     sed '/GLIBC/\!d;s/^.*\(GLIBC_.*\)$/\1/' >RH.out

  # objdump -T debian/libc-2.1.1.so | \
     sed '/GLIBC/\!d;s/^.*\(GLIBC_.*\)$/\1/' >DEB.out

  # diff RH.out DEB.out

without the "chown" patch, the two files were identical.  

With the patch, programs compiled on Debian will fail on Red Hat when
they call chown().  (This is the status quo, btw.)

(BTW, there are a _lot_ of differences between libc-2.0.105 and
libc-2.1.1 on Debian, but they all involve "__" symbols, so they
shouldn't cause problems with real programs.)


Well these are the issues - is there a consensus on what we should do?
Recompile half of the distribution, or retain a one-way incompatiblity
with Red Hat?  (We can run RH stuff, but they can't run our stuff.)

(A nice solution would be to find a way to force the linker to use the
GLIBC_2.0 symbol while still making the GLIBC_2.1 symbol available to
the loader, but I don't think that is possible.)


Steve
dunham@cse.msu.edu