From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-hacker-return-5595-listarch-libc-hacker=sourceware.cygnus.com@sources.redhat.com>
Received: (qmail 23677 invoked by alias); 18 Sep 2002 18:34:05 -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 23661 invoked from network); 18 Sep 2002 18:34:04 -0000
Received: from unknown (HELO gateway.sf.frob.com) (64.160.53.101)
  by sources.redhat.com with SMTP; 18 Sep 2002 18:34:04 -0000
Received: from magilla.sf.frob.com (unknown [198.49.250.228])
	by gateway.sf.frob.com (Postfix) with ESMTP
	id 59F3D357E; Wed, 18 Sep 2002 11:34:00 -0700 (PDT)
Received: (from roland@localhost)
	by magilla.sf.frob.com (8.11.6/8.11.6) id g8IIY3k07883;
	Wed, 18 Sep 2002 11:34:03 -0700
Date: Wed, 18 Sep 2002 11:34:00 -0000
Message-Id: <200209181834.g8IIY3k07883@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 09:29:49 -0400 <20020916092949.A12870@devserv.devel.redhat.com>
X-Zippy-Says: 
   I'm young..  I'm HEALTHY..  I can HIKE THRU CAPT GROGAN'S LUMBAR REGIONS!
X-SW-Source: 2002-09/txt/msg00053.txt.bz2

> Nope, I mean -Wr. If libc.so doesn't have any R_386_GLOB_DAT __ctype_b

Ah, I see the problem now.  Always forgetting about those pesky copy relocs.

I inserted compat_symbol (i.e. .symver) decls in lc-ctype.c where the
variables are set, and that gets those relocs bound early to the versioned
name and thus proper GLOB_DAT relocs in the shared object.

This exposed a trivial ld.so bug in handling relocs referring to
non-default versioned symbols defined in the same object, which I fixed.

I think this puts this problem to rest.  The only thing I don't know is if
older binutils versions have any problem producing the right output with
this usage.  I would tend to doubt off hand that it's a problem with the
new straightforward usage of the symbols by their versioned names.