Hi all,

I encountered a problem with a runtime-linked shared object which was
accidently compiled using profiling. The object could not be loaded
because the main module itself was not compiled with the -p option and
so references to __mcount could not be resolved. (The reason for this
mistake was funny: xlc was used with compiler options intended for
gcc, and they included '-mcpu=powerpc'. There is no such xlc option
but there are options -m, -c, -p, and -u. As -u even takes an argument
you get no compiler error. Murhpy at its best.)

I read aix_ll.pdf and Gary R. Hook's tutorials and was able to figure
out the problem, but there are remaining some mysteries for me:

Linking the object with "ld -bexpall -G test.o -o test.so" resulted
to:
# dump -HTv test.so |grep __mcount
[76] 0x00000000 undef IMP DS EXTref .. __mcount

But when linking with "-bnoentry -bexpall -bM:SRE -brtllib -bnortllib
-berok -bnosymbolic -bnoautoexp", which should be equivalent to "-G"
according to the ld man page, __mcount gets deferred:
# dump -HTv test.so |grep __mcount
[76] 0x00000000 undef IMP DS EXTref [noIMid] __mcount

Even more confusing: Using "xlc -bnoentry -bexpall -bM:SRE -brtllib
-bnortllib -berok -bnosymbolic -bnoautoexp test.o -o test.so" results
in no reference to __mcount at all, whereas "xlc -G ..." is equivalent
to "ld -G ...".

Can someone explain this behaviour of the linker to me? How does the
linker decide if a symbol has to be bind at loadtime or should be
deferred?

Johannes