Re: glibc 2.1 in potato

[Joel Klecker]

At 18:49 -0500 1999-03-22, Steve Dunham wrote:

I also had to tweak the rules file to leave out lddlibc4 which wasn't
built on my machine.  (It is included by the rules file if
"HAVE_LIBC5" is defined, even though it seems to be intended for
systems that have libc4.)


I have investigated this, it is a bug either in 
sysdeps/unix/sysv/linux/configure{,.in} or 
sysdeps/unix/sysv/linux/sparc/sparc32/Makefile.
configure.in includes sparc32 in the architectures that should have 
their ldd edited by a sed script (there is a configure variable 
called "ldd_rewrite_script") that adds a few lines to call the 
lddlibc4 helper program if necessary.
However, the Makefile does not add the lddlibc4 program to that which 
needs to be built and installed.
The other archs that use the sed script have something like the 
following in their respective Makefiles.


ifeq ($(subdir),elf)
sysdep-others += lddlibc4
install-bin += lddlibc4
endif
--
Joel Klecker (aka Espy) http://web.espy.org/>
mailto:[EMAIL PROTECTED]>  mailto:[EMAIL PROTECTED]>

Re: glibc 2.1 in potato

[Joel Klecker]

At 01:04 -0500 1999-03-23, Steve Dunham wrote:
>  # touch /tmp/foo
>  # perl
>  chown 0,0,"/tmp/foo";
>  perl: error in loading shared libraries: perl: symbol chown, version
>  GLIBC_2.1 not defined in file libc.so.6 with link time reference
>
>I suspect that all of the above programs will have problems when they
>call chown().  (I think tar calls both chown() and lchown() depending
>on what it's trying to do.)
>
>
>So, it looks like we're going to have to recompile a lot of stuff...

I see the issue, you need the sparc32-chown patch in libc again.

The following should be debian/patches/sparc32-chown.dpatch and you should add 
sparc32-chown to the sparc section of the patches section in debian/rules.

#! /bin/sh -e

# All lines beginning with `# DPATCH:' are a description of the patch.
# DP: chown compat

if [ $# -ne 2 ]; then
echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
exit 1
fi
case "$1" in
-patch) patch -d "$2" -f -p1 < $0;;
-unpatch) patch -d "$2" -f -R -p1 < $0;;
*)
echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
exit 1
esac
exit 0

--- glibc-pre2.1-2.0.106/sysdeps/unix/sysv/linux/sparc/sparc32.orig/chown.c 
Thu Jan  1 00:00:00 1970
+++ glibc-pre2.1-2.0.106/sysdeps/unix/sysv/linux/sparc/sparc32/chown.c  Mon Aug 
24 17:58:59 1998
@@ -0,0 +1,131 @@
+/* chown() compatibility.
+   Copyright (C) 1998 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Library General Public License as
+   published by the Free Software Foundation; either version 2 of the
+   License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Library General Public License for more details.
+
+   You should have received a copy of the GNU Library General Public
+   License along with the GNU C Library; see the file COPYING.LIB.  If not,
+   write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+   Boston, MA 02111-1307, USA.  */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+  In Linux 2.1.x the chown functions have been changed.  A new function lchown
+  was introduced.  The new chown now follows symlinks - the old chown and the
+  new lchown do not follow symlinks.
+  This file emulates chown() under the old kernels.
+*/
+
+extern int __syscall_chown (const char *__file,
+   uid_t __owner, gid_t __group);
+
+int
+__chown (const char *file, uid_t owner, gid_t group)
+{
+   int err;
+   int old_errno;
+   char link[PATH_MAX+2];
+   char path[2*PATH_MAX+4];
+   int loopct;
+   int filelen;
+   static int libc_old_chown = 0 /* -1=old linux, 1=new linux, 0=unknown */;
+   
+   if (libc_old_chown == 1)
+ return __syscall_chown (file, owner, group);
+
+   old_errno = errno;
+
+#ifdef __NR_lchown
+   if (libc_old_chown == 0)
+ {
+   err = __syscall_chown (file, owner, group);
+   if (err != -1 || errno != ENOSYS)
+{
+  libc_old_chown = 1;
+  return err;
+}
+   libc_old_chown = -1;
+ }
+#endif
+   
+   err = __readlink (file, link, PATH_MAX+1);
+   if (err == -1)
+ {
+   errno = old_errno;
+   return __lchown(file, owner, group);
+ }
+
+   filelen = strlen (file) + 1;
+   if (filelen > sizeof(path))
+ {
+   errno = ENAMETOOLONG;
+   return -1;
+ }
+   memcpy (path, file, filelen);
+
+   /* 'The system has an arbitrary limit...'  In practise, we'll hit
+  ENAMETOOLONG before this, usually.  */
+   for (loopct = 0; loopct < 128; loopct++)
+   {
+ int linklen;
+ 
+ if (err >= PATH_MAX+1)
+   {
+errno = ENAMETOOLONG;
+return -1;
+   }
+
+  link[err] = 0;  /* Null-terminate string, just-in-case.  */
+
+  linklen = strlen (link) + 1;
+  
+  if (link[0] == '/')
+   memcpy (path, link, linklen);
+  else
+   {
+ filelen = strlen (path);
+ 
+ while (filelen > 1 && path[filelen-1] == '/')
+   filelen--;
+ while (filelen > 0 && path[filelen-1] != '/')
+   filelen--;
+ if (filelen + linklen > sizeof(path))
+   {
+ errno = ENAMETOOLONG;
+ return -1;
+   }
+ memcpy (path+filelen, link, linklen);
+   }
+
+  err = __readlink(path, link, PATH_MAX+1);
+  
+  if (err == -1)
+  {  
+   errno = old_errno;
+   return __lchown(path, owner, group);
+  }
+   }
+   errno = ELOOP;
+   return -1;
+}
+
+#if defined PIC && defined DO_VERSIONING
+default_symbol_version (__chown, chown, GLIBC_2.1);
+#else
+weak_alias (__chown, chown)
+#endif
--- glibc-pre2.1-2.0.106/sysdeps/unix/sysv/linux/spar

Re: glibc 2.1 in potato

[Steve Dunham]

Steve Dunham <[EMAIL PROTECTED]> writes:

> This should explain the error that you are seeing, but it doesn't
> explain why I don't see the problem on my test machine.  

I'm using tar 1.12-7, btw. 

> Wait - I am seeing the problem with other programs. 

Sorry, typed C-c C-c in the wrong window. 

I can't telnet in (hostnames changed):

  Trying 10.0.0.1...
  Connected to foo.bar.domain.
  Escape character is '^]'.
  in.telnetd: fatneck.cse.msu.edu [xterm]: error in loading shared libraries: 
in.telnetd: fatneck.cse.msu.edu [xterm]: symbol chown, version GLIBC_2.1 not 
defined in file libc.so.6 with link time reference
  Debian GNU/Linux 2.1 jocoque.cse.msu.edu

ssh doesn't work either.  (I restarted it, and I can now connect and
authenticate - it logs a completed RSA authentication - then it
exits.)

It also looks like man is broken too.

We may have a big problem here.  The following bash magic scans the
current directories for possible problems:

for i in *;do 
  if objdump -T $i 2>/dev/null|grep chown|grep -q GLIBC_2.1; then 
echo $i; 
  fi;
done

In /usr/sbin I find:

  exim gdm in.rlogind in.telnetd rmail rsmtp runq sendfiled 
  sendmail sshd sshd1 visudo

In /bin:

  cpio gunzip gzip tar uncompress zcat

In /sbin:

  getty slattach

In /usr/bin:

  apropos bitchx catman checkpc dpkg editor elm ex fdlist fdmount 
  fdmountd fdumount lockfile mailq man mandb manpath mc mcedit mcserv 
  nex nvi nview objcopy perl perl5.00404 procmail rdistd rn slogin
  slrn sperl5.00404 ssh ssh1 strip sudo suidperl trn vi view whatis


And example of the problem:

  # touch /tmp/foo
  # perl
  chown 0,0,"/tmp/foo";
  perl: error in loading shared libraries: perl: symbol chown, version 
GLIBC_2.1 not defined in file libc.so.6 with link time reference

I suspect that all of the above programs will have problems when they
call chown().  (I think tar calls both chown() and lchown() depending
on what it's trying to do.)


So, it looks like we're going to have to recompile a lot of stuff...


Steve
[EMAIL PROTECTED]

Re: glibc 2.1 in potato

[Steve Dunham]

Ben Collins <[EMAIL PROTECTED]> writes:

> Ok, I've gotten glibc 2.1.1-0.1 compiled. No real problems (atleast no
> C++ libs problems like i386 is having).

> Only thing I see wrong is tar broke:

> tar: error in loading shared libraries: tar: symbol chown, version
> GLIBC_2.1 not defined in file libc.so.6 with link time reference

> GLIBC_2.1 is defined (atleast it shows when I grep strings libc.so.6)
> in libc.

> The `chown' comand works fine, however, and nothing else seems to be
> affected. Could this be a bad compile of tar or was the previous glibc
> 2.1pre's compiled with some strange symbols?

Hmm, it looks like 2.0.105 has a version 2.1 chown:

# objdump -T /lib/libc-2.0.105.so | grep chown 
000a88a8 gDF .text  00a4  GLIBC_2.1   chown
000a894c gDF .text  001c (GLIBC_2.0)  chown
000a8968  w   DF .text    GLIBC_2.0   fchown
000a899c  w   DF .text    GLIBC_2.0   lchown
000a88a8 gDF .text  00a4  GLIBC_2.1   __chown

But the new one doesn't:

# objdump -T libc.so |grep chown
00095008  w   DF .text    GLIBC_2.0   fchown
0009503c  w   DF .text    GLIBC_2.0   lchown
00094fd4  w   DF .text    GLIBC_2.0   chown

Looking at "tar":

# objdump -T /bin/tar |grep chown
0003f5a0  DF *UND*  00a4  GLIBC_2.1   chown
0003f9fc  w   DF *UND*    GLIBC_2.0   lchown

And "chown":

# objdump -T /bin/chown |grep chown
/bin/chown: file format elf32-sparc
00022080  w   DF *UND*    GLIBC_2.0   chown

This should explain the error that you are seeing, but it doesn't
explain why I don't see the problem on my test machine.  


Wait - I am seeing the problem with other programs. 




Steve
[EMAIL PROTECTED]

Re: glibc 2.1 in potato

[Ben Collins]

On Mon, Mar 22, 1999 at 09:34:41PM -0500, Ben Collins wrote:
> Ok, I've gotten glibc 2.1.1-0.1 compiled. No real problems (atleast no
> C++ libs problems like i386 is having).
>
> Only thing I see wrong is tar broke:
>
> tar: error in loading shared libraries: tar: symbol chown, version
> GLIBC_2.1 not defined in file libc.so.6 with link time reference
>
> GLIBC_2.1 is defined (atleast it shows when I grep strings libc.so.6)
> in libc.
>
> The `chown' comand works fine, however, and nothing else seems to be
> affected. Could this be a bad compile of tar or was the previous glibc
> 2.1pre's compiled with some strange symbols?

Just a note, I really need to reboot before I strike these as
persistent problems, but since I wasn't able to restart sshd or reboot
the system before my dial-up droped me, I will have to wait till
tomorrow morning when I go into work.

--
--- -  -   ---  -  - - ---   
Ben Collins <[EMAIL PROTECTED]>  Debian GNU/Linux
OpenLDAP Core - [EMAIL PROTECTED] [EMAIL PROTECTED]
UnixGroup Admin - Jordan Systems The Choice of the GNU Generation
-- -- - - - ---   --- --  -  - ---  -  --

Re: glibc 2.1 in potato

[Ben Collins]

Ok, I've gotten glibc 2.1.1-0.1 compiled. No real problems (atleast no
C++ libs problems like i386 is having).

Only thing I see wrong is tar broke:

tar: error in loading shared libraries: tar: symbol chown, version
GLIBC_2.1 not defined in file libc.so.6 with link time reference

GLIBC_2.1 is defined (atleast it shows when I grep strings libc.so.6)
in libc.

The `chown' comand works fine, however, and nothing else seems to be
affected. Could this be a bad compile of tar or was the previous glibc
2.1pre's compiled with some strange symbols?

--
--- -  -   ---  -  - - ---   
Ben Collins <[EMAIL PROTECTED]>  Debian GNU/Linux
OpenLDAP Core - [EMAIL PROTECTED] [EMAIL PROTECTED]
UnixGroup Admin - Jordan Systems The Choice of the GNU Generation
-- -- - - - ---   --- --  -  - ---  -  --

Re: glibc 2.1 in potato

[Ben Collins]

On Mon, Mar 22, 1999 at 06:49:36PM -0500, Steve Dunham wrote:
Build is just starting (30 minutes into it) for glibc 2.1.1-0.1 source.
Haven't seen any problems yet.

> Also, a completely unrelated question: "ldbmcat" segfaults on Sparc
> machines (works fine on i386).  I don't have a debug build lying
> around, so I can't debug it more.  (Do you see the same behaviour?)

Which version? I have noticed the same problem but have been
attributing it to a db2 problem. Seems to be fixed in the upcoming
1.2.1 package I will upload RSN.

--
--- -  -   ---  -  - - ---   
Ben Collins <[EMAIL PROTECTED]>  Debian GNU/Linux
OpenLDAP Core - [EMAIL PROTECTED] [EMAIL PROTECTED]
UnixGroup Admin - Jordan Systems The Choice of the GNU Generation
-- -- - - - ---   --- --  -  - ---  -  --

Re: glibc 2.1 in potato

[Steve Dunham]

Ben Collins <[EMAIL PROTECTED]> writes:

> On Mon, Mar 22, 1999 at 05:45:07PM -0500, Steve Dunham wrote:
> > Ben Collins <[EMAIL PROTECTED]> writes:
> >
> > > On Mon, Mar 22, 1999 at 02:15:50PM -0500, Steve Dunham wrote:
> >
> > > > If you want, I can take care of compiling this.  (I did it once about
> > > > a month ago, but that was with an older, broken version of egcc, so
> > > > crypt didn't work and, hence, I didn't upload anything.)
> >
> > > It's fine, I'll get it uploaded tonight.
> >
> > What kernel headers are you compiling against?  (2.1.125?)  It needs
> > to be compiled against 2.1.x or newer kernel headers.

> I'm using the 2.2.1 headers since that is the latest kernel in the
> system (and the same one that i386 was compiled against).

Ok, just double checking.  (If 2.0.x headers are used, then features
are missing.)  I had a couple of problems with the compile - I had to
define __NR_vfork (I set it to 66) in
  "sysdeps/unix/sysv/linux/sparc/sparc32/sysdeps.h " to get it to
compile (without an undefined __NR_vfork).  Apparently, this constant
is not defined in the 2.1.125 or 2.2.1 headers, even though the
syscall is on the list.

I also had to tweak the rules file to leave out lddlibc4 which wasn't
built on my machine.  (It is included by the rules file if
"HAVE_LIBC5" is defined, even though it seems to be intended for
systems that have libc4.)

Did you see these problems?


Also, a completely unrelated question: "ldbmcat" segfaults on Sparc
machines (works fine on i386).  I don't have a debug build lying
around, so I can't debug it more.  (Do you see the same behaviour?)


Steve
[EMAIL PROTECTED]

Re: glibc 2.1 in potato

[Ben Collins]

On Mon, Mar 22, 1999 at 05:45:07PM -0500, Steve Dunham wrote:
> Ben Collins <[EMAIL PROTECTED]> writes:
>
> > On Mon, Mar 22, 1999 at 02:15:50PM -0500, Steve Dunham wrote:
>
> > > If you want, I can take care of compiling this.  (I did it once about
> > > a month ago, but that was with an older, broken version of egcc, so
> > > crypt didn't work and, hence, I didn't upload anything.)
>
> > It's fine, I'll get it uploaded tonight.
>
> What kernel headers are you compiling against?  (2.1.125?)  It needs
> to be compiled against 2.1.x or newer kernel headers.

I'm using the 2.2.1 headers since that is the latest kernel in the
system (and the same one that i386 was compiled against).

--
--- -  -   ---  -  - - ---   
Ben Collins <[EMAIL PROTECTED]>  Debian GNU/Linux
OpenLDAP Core - [EMAIL PROTECTED] [EMAIL PROTECTED]
UnixGroup Admin - Jordan Systems The Choice of the GNU Generation
-- -- - - - ---   --- --  -  - ---  -  --

Re: glibc 2.1 in potato

[Steve Dunham]

Ben Collins <[EMAIL PROTECTED]> writes:

> On Mon, Mar 22, 1999 at 02:15:50PM -0500, Steve Dunham wrote:

> > If you want, I can take care of compiling this.  (I did it once about
> > a month ago, but that was with an older, broken version of egcc, so
> > crypt didn't work and, hence, I didn't upload anything.)

> It's fine, I'll get it uploaded tonight.

What kernel headers are you compiling against?  (2.1.125?)  It needs
to be compiled against 2.1.x or newer kernel headers.




Steve
[EMAIL PROTECTED]

Re: glibc 2.1 in potato

[Ben Collins]

On Mon, Mar 22, 1999 at 02:15:50PM -0500, Steve Dunham wrote:
> Stephen Zander <[EMAIL PROTECTED]> writes:
>
> > > "Ben" == Ben Collins <[EMAIL PROTECTED]> writes:
> > Ben> I have a nice Debian Ultra Sparc 1 box setup now and was
> > Ben> going to compile glibc 2.1.1-0.1 (from potato). Are we ready
> > Ben> to make this upgrade in the dist yet? If so I can NMU it
> > Ben> afterwards.
> >
> > Given that we've been running pre2.1 glibc forever, why not?
>
> I was wondering if anybody was going to do this.  A few caveats:
>
> Install the latest sparc egcs first (2.91.60-5 works fine - i ).
> Otherwise the "crypt()" functions will be broken. (The test case is
> attached.  Not that gcc is still broken, but glibc uses egcs.)
>
> After you compile and install glibc, compile and install the latest
> egcs from potato.  (This will probably entail compiling and installing
> the latest dejagnu from experimental - this might not be 100%
> necessary if they didn't add any versioned symbols since 2.0.105.)
>
> Then test everything.  Make sure apt and dselect work (good tests of
> C++ stuff).  Note that compatibility isn't guaranteed between 2.1
> betas and 2.1, but I think 2.0.105 is late enough to be fully
> compatible.

Noted.

> If you want, I can take care of compiling this.  (I did it once about
> a month ago, but that was with an older, broken version of egcc, so
> crypt didn't work and, hence, I didn't upload anything.)

It's fine, I'll get it uploaded tonight.

--
--- -  -   ---  -  - - ---   
Ben Collins <[EMAIL PROTECTED]>  Debian GNU/Linux
OpenLDAP Core - [EMAIL PROTECTED] [EMAIL PROTECTED]
UnixGroup Admin - Jordan Systems The Choice of the GNU Generation
-- -- - - - ---   --- --  -  - ---  -  --

Re: glibc 2.1 in potato

[Stephen Zander]

> "Steve" == Steve Dunham <[EMAIL PROTECTED]> writes:
Steve> I was wondering if anybody was going to do this.  A few
Steve> caveats:

[snip]

Ben, are you going to go through Steve's list?  I can probably get to
this late this week but I'll be on a SS5/170 so someone with a faster
system will probably be done quicker.

-- 
Stephen
---
Long noun chains don't automatically imply security. - Bruce Schneier

Re: glibc 2.1 in potato

[Steve Dunham]

Stephen Zander <[EMAIL PROTECTED]> writes:

> > "Ben" == Ben Collins <[EMAIL PROTECTED]> writes:
> Ben> I have a nice Debian Ultra Sparc 1 box setup now and was
> Ben> going to compile glibc 2.1.1-0.1 (from potato). Are we ready
> Ben> to make this upgrade in the dist yet? If so I can NMU it
> Ben> afterwards.
> 
> Given that we've been running pre2.1 glibc forever, why not?

I was wondering if anybody was going to do this.  A few caveats:

Install the latest sparc egcs first (2.91.60-5 works fine - i ).
Otherwise the "crypt()" functions will be broken. (The test case is
attached.  Not that gcc is still broken, but glibc uses egcs.)

After you compile and install glibc, compile and install the latest
egcs from potato.  (This will probably entail compiling and installing
the latest dejagnu from experimental - this might not be 100%
necessary if they didn't add any versioned symbols since 2.0.105.)

Then test everything.  Make sure apt and dselect work (good tests of
C++ stuff).  Note that compatibility isn't guaranteed between 2.1
betas and 2.1, but I think 2.0.105 is late enough to be fully
compatible.


If you want, I can take care of compiling this.  (I did it once about
a month ago, but that was with an older, broken version of egcc, so
crypt didn't work and, hence, I didn't upload anything.)


Steve
[EMAIL PROTECTED]

Re: glibc 2.1 in potato

[Stephen Zander]

> "Ben" == Ben Collins <[EMAIL PROTECTED]> writes:
Ben> I have a nice Debian Ultra Sparc 1 box setup now and was
Ben> going to compile glibc 2.1.1-0.1 (from potato). Are we ready
Ben> to make this upgrade in the dist yet? If so I can NMU it
Ben> afterwards.

Given that we've been running pre2.1 glibc forever, why not?

-- 
Stephen
---
Long noun chains don't automatically imply security. - Bruce Schneier