From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10650 invoked by alias); 16 Sep 2002 06:52:39 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 10634 invoked from network); 16 Sep 2002 06:52:38 -0000 Received: from unknown (HELO Cantor.suse.de) (213.95.15.193) by sources.redhat.com with SMTP; 16 Sep 2002 06:52:38 -0000 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id E987C1435A; Mon, 16 Sep 2002 08:52:37 +0200 (MEST) Received: from aj by arthur.inka.de with local (Exim 3.34 #1) id 17qpkK-00048i-00; Mon, 16 Sep 2002 08:52:36 +0200 Mail-Copies-To: never To: Roland McGrath Cc: GNU libc hacker Subject: Re: problems with ctype... References: <200209160512.g8G5CUF04935@dhcp187.sf.frob.com> From: Andreas Jaeger Date: Sun, 15 Sep 2002 23:52:00 -0000 In-Reply-To: <200209160512.g8G5CUF04935@dhcp187.sf.frob.com> (Roland McGrath's message of "Sun, 15 Sep 2002 22:12:30 -0700") Message-ID: User-Agent: Gnus/5.090008 (Oort Gnus v0.08) XEmacs/21.4 (Artificial Intelligence, i386-suse-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-09/txt/msg00022.txt.bz2 Roland McGrath writes: > It certainly works fine for me, but I am not using the same tools. > I am using GCC 3.2 with RH modifications and binutils is also a RH version. I just tried it with newer binutils (2.12.90.0.15 20020717) and that worked fine. We might need to document the minimal supported binutils version. > > In my build the libc.so.6 symbol table contains (this is readelf -s output): > > 988: 00112a40 4 OBJECT GLOBAL DEFAULT 16 __ctype_toupper@GLIBC_2.0 > 3865: 00112a40 4 OBJECT LOCAL DEFAULT 16 __ctype_toupper gromit:/builds/glibc/gcc-3.3:[2]$ readelf -s libc.so.6 |grep ctype_toupper [From dynsym:] 696: 0010fb2c 4 OBJECT GLOBAL DEFAULT 16 __ctype_toupper@@GLIBC_2.0 989: 0010fb2c 4 OBJECT GLOBAL DEFAULT 16 __ctype_toupper@GLIBC_2.0 1923: 00022692 114 FUNC GLOBAL DEFAULT 11 __ctype_toupper_loc@@GLIBC_2.3 [From .symtab] 5647: 0010fb2c 4 OBJECT GLOBAL DEFAULT 16 __ctype_toupper 5940: 0010fb2c 4 OBJECT GLOBAL DEFAULT 16 __ctype_toupper@GLIBC_2.0 6874: 00022692 114 FUNC GLOBAL DEFAULT 11 __ctype_toupper_loc > and the dynamic symbol table contains: > > 5948: 00112a40 4 OBJECT GLOBAL DEFAULT 16 __ctype_toupper@GLIBC_2.0 > > In libc_pic.a, lc-ctype.os has: > > 25: 00000000 0 NOTYPE GLOBAL DEFAULT UND __ctype_toupper > > and ctype/ctype-info.os has: > > 32: 0000000c 4 OBJECT GLOBAL DEFAULT 10 __ctype_toupper > 39: 0000000c 4 OBJECT GLOBAL DEFAULT 10 __ctype_toupper@GLIBC_2.0 These looks the same for me. > > Those are the only __ctype_toupper references. How does this compare with > the symbols in your build? > > Perhaps the ld behavior is different. I don't know what the *IND* magic in > the linker error message is. I presume that your libc.so.6 symbol tables > must look different from mine, or the error doesn't make sense. > I'm not sure if it's supposed to be the case that the references in > lc-ctype.os uses the versioned name when it's being linked -shared with the > object that defines the non-default versioned name. But I think not, since > there is also a plain global __ctype_toupper defined in ctype-info.os. I > could understand the multiple definition error more if it came up doing the > ld -shared instead. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj