Re: Question on symbol versioning

["Amker.Cheng" <amker dot cheng at gmail dot com>]

> The base version definition in an executable or shared library is the
> one with VER_FLG_BASE set in the vd_flags field of a Verdef structure in
> the SHT_GNU_verdef section aka the data to which DT_VERDEF/DT_VERDEFNUM
> dynamic tags point. ?VER_FLG_BASE has the value 1. ?There is a bit of
> documentation at
> http://docs.sun.com/app/docs/doc/819-0690/chapter6-93046?l=en&a=view .

Thanks, but still could not get it. I dumped version info of eglibc's
libc.so.6 for mips,
the first three entries of section ".gnu_version_d" are like:

Version definition section '.gnu.version_d' contains 19 entries:
  Addr: 0x0000000000012644  Offset: 0x012644  Link: 6 (.dynstr)
  000000: Rev: 1  Flags: BASE   Index: 1  Cnt: 1  Name: libc.so.6
 <-------------flag BASE
  0x001c: Rev: 1  Flags: none  Index: 2  Cnt: 1  Name: GLIBC_2.0
  0x0038: Rev: 1  Flags: none  Index: 3  Cnt: 2  Name: GLIBC_2.2
  0x0054: Parent 1: GLIBC_2.0

While other entries are in forms like GLIBC_2.*, why does the base one
have name "libc.so.6",
which is the libc file's name?

further more, considering a little example, test.c
like

#include "stdio.h"
FILE * func(int fd)
{
  return fdopen(fd, "a+w");
}

then generating test.so with commands:

mipsel-linux-gnu-gcc -fPIC -c -O2 test.c -o test.o
mipsel-linux-gnu-ld -shared test.o -o test.so

dumping dynamic symbol table with readelf -s:

Symbol table '.dynsym' contains 13 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     ......
    12: 00000320     0 FUNC    GLOBAL DEFAULT  UND fdopen

it's clear test.so references fdopen without versioning information.
when try running test.so on my linux system, the call to fdopen is bound
to fdopen@GLIBC_2.0 , not the latest version fdopen@GLIBC_2.2,
by dynamic linker

right now I have NO idea about this behavior and might talking overabundance.
Again thanks for your time.

-- 
Best Regards.