From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-hacker-return-5574-listarch-libc-hacker=sourceware.cygnus.com@sources.redhat.com>
Received: (qmail 28861 invoked by alias); 16 Sep 2002 13:22:56 -0000
Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:libc-hacker-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/libc-hacker/>
List-Post: <mailto:libc-hacker@sources.redhat.com>
List-Help: <mailto:libc-hacker-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: libc-hacker-owner@sources.redhat.com
Received: (qmail 28839 invoked from network); 16 Sep 2002 13:22:54 -0000
Received: from unknown (HELO gateway.sf.frob.com) (64.160.53.101)
  by sources.redhat.com with SMTP; 16 Sep 2002 13:22:54 -0000
Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228])
	by gateway.sf.frob.com (Postfix) with ESMTP
	id 0C5B23583; Mon, 16 Sep 2002 06:22:47 -0700 (PDT)
Received: (from roland@localhost)
	by magilla.sf.frob.com (8.11.6/8.11.6) id g8GC3wa02139;
	Mon, 16 Sep 2002 05:03:58 -0700
Date: Mon, 16 Sep 2002 06:22:00 -0000
Message-Id: <200209161203.g8GC3wa02139@magilla.sf.frob.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Roland McGrath <roland@redhat.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Andreas Jaeger <aj@suse.de>,
	GNU libc hacker <libc-hacker@sources.redhat.com>
Subject: Re: problems with ctype...
In-Reply-To: Jakub Jelinek's message of  Monday, 16 September 2002 11:22:20 +0200 <20020916112220.C1013@sunsite.ms.mff.cuni.cz>
X-Zippy-Says: I'll eat ANYTHING that's BRIGHT BLUE!!
X-SW-Source: 2002-09/txt/msg00032.txt.bz2

> Actually, looking at it again, what is in CVS doesn't work at all.

Works just fine for me.

> Just readelf -Wr libc.so | grep __ctype to find out.

You mean -Ws, no doubt.  Here are just the __ctype_b matches in mine:

  1721: 00021f98   114 FUNC    GLOBAL DEFAULT   11 __ctype_b_loc@@GLIBC_2.3
  2013: 00112a34     4 OBJECT  GLOBAL DEFAULT   16 __ctype_b@GLIBC_2.0
  3595: 00112a34     4 OBJECT  LOCAL  DEFAULT   16 __ctype_b
  6681: 00021f98   114 FUNC    GLOBAL DEFAULT   11 __ctype_b_loc
  6973: 00112a34     4 OBJECT  GLOBAL DEFAULT   16 __ctype_b@GLIBC_2.0

> If it was supposed to work, it would have to have __ctype_b@GLIBC_2.0 
> (or __ctype_b@@GLIBC_2.0) etc. dynamic relocs.

???  Must be too early in the morning, else it's too late for me.  There
are no relocs referring to these symbols because the references resolve
internally.  There are dynamic symbol table entries as there should be.