[Updated: 04/07/2006] Much accurate information is available in a better format at:
Reducing Symbol Scope with Sun Studio C/C++
__________________

Lets add one more local method called "addtentomyage()" in hidden.h

hidden.h
---------
bpte4500s001:/sunbuild1/giri/testcases/symbol-hiding/%cat hidden.c

#include
#include "hidden.h"

int age = 25;

int addtentomyage(int age)
{
return ((int) age + 10);
}

char *lastname(char *firstname)
{
return ((char *)"mandalika");
}

char firstchar(char *strings)
{
return (*strings);
}

int agefunc()
{
int finalage = 0;

finalage = addtentomyage(age);
return (finalage);
}

Create libhidden.so and run the driver program

bpte4500s001:/sunbuild1/giri/testcases/symbol-hiding/% CC -c hidden.c ; CC -G -o libhidden.so hidden.o ; CC -lhidden -o driver driver.c

bpte4500s001:/sunbuild1/giri/testcases/symbol-hiding/%./driver

lname = mandalika
age = 35
first char = c

Cool; got the expected result

Now lets introduce one more library called "libgeneric" with a buggy implementation for addtentomyage()

bpte4500s001:/sunbuild1/giri/testcases/symbol-hiding/%cat generic.c

#include "hidden.h"

int addtentomyage(int age)
{
return ((int) age + 100);
}

Compile & create a new library called "libgeneric"

bpte4500s001:/sunbuild1/giri/testcases/symbol-hiding/%CC -c generic.c ; CC -G -o libgeneric.so generic.o

Now link the new library (libgeneric) with the driver executable as follows (observe that libgeneric is placed before libhidden in the compile line):

bpte4500s001:/sunbuild1/giri/testcases/symbol-hiding/%CC -o driver -lgeneric -lhidden driver.c

Run the driver program and observe the result:
bpte4500s001:/sunbuild1/giri/testcases/symbol-hiding/%./driver

lname = mandalika
age = 125
first char = c

That's not good; the expected age was 35, but got 125! What's wrong?

Even though there is an implementation available inside the libhidden module itself, linker picked up the implementation from libgeneric by blindly following the left to right rule (ref: Linker & Libraries guide by Sun Microsystems). And in general references to global symbols within shared objects are not bound until runtime, even if definitions are available, so that definitions of the same symbol in an executable or other shared object can override the object's own definition

The tool "ldd" will be useful for dumping the dependency ordering

bpte4500s001:/sunbuild1/giri/testcases/symbol-hiding/%ldd driver
libgeneric.so => /sunbuild1/giri/testcases/symbol-hiding/libgeneric.so
libhidden.so => /sunbuild1/giri/testcases/symbol-hiding/libhidden.so
libCstd.so.1 => /usr/lib/libCstd.so.1
libCrun.so.1 => /usr/lib/libCrun.so.1
libm.so.1 => /usr/lib/libm.so.1
libw.so.1 => /usr/lib/libw.so.1
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
/usr/lib/cpu/sparcv8plus/libCstd_isa.so.1
/usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1

Advantage:
The application can take advantage of interposing libraries i.e., if needed, the application can enjoy an alternate implementation for the same set of interfaces if available

Disadvantage:
Name collisions (just like the one shown in the example); due to the collision the application may break (our example shows that broken part - expected value: 35, but the returned value is: 125)

How to override this default behavior and make it pick the right implementation?

(to be continued ..)