Re: problems with ctype...

[Andreas Jaeger <aj at suse dot de>]

Roland McGrath <roland@redhat.com> 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