This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: problems with ctype...

From: Roland McGrath <roland at redhat dot com>
To: Jakub Jelinek <jakub at redhat dot com>
Cc: Andreas Jaeger <aj at suse dot de>,GNU libc hacker <libc-hacker at sources dot redhat dot com>
Date: Mon, 16 Sep 2002 05:03:58 -0700
Subject: Re: problems with ctype...

> 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.

References:
- Re: problems with ctype...
  - From: Jakub Jelinek

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]