I'm getting this error from the runtime linker when I launch my executable:

rtld: 0712-001 Symbol _Init__Q2_3std5_TreeX...<snip> (over 2048 chars)
from module /services/Development/Build/Server/Lib/libPersistence.a
(AccountSimplePersistenceCache.o), but a runtime definition of
the symbol was not found.

There are about 27 more of these errors, most with different symbols but all
from the same shared object, AccountSimplePersistenceCache.o.

I did an nm on the shared object, but it is impossible to find the missing
symbol by hand. The symbol spit out by the rtld is also mangled and I'm
unable to demangle it.

There are 33 other shared objects in the libPersistence.a archive, all
built the exact same way as the failing object and I don't see any errors
from the other objects. I'm not sure if this is just the first, or if
it's the only one with problems.

I do not have this problem when I build the objects without the -O compiler
option.

I'm using an updated version of the 5.0.2 compiler. IBM sent me a
compilerPTF instafix to enable me to compile code with the -O option, and
I'm not sure if the problems are related.

I'm building the shared object from an object archive based on a tip
I saw in the document C_and_C++_Application_Development_on_AIX:

ld -r -o tmp.o -L<bla bla> -lAccountSimplePersistenceCache
-l<various libs to satisfy link>
xlC -G -qmkshrobj -bloadmap:loadmap.out -oAccountSimplePersistenceCache.o
tmp.o -l<same here>


I've killed a day on this problem and I'm no closer to a solution now.

Any help would be appreciated.


Gary

Gary wrote:

> rtld: 0712-001 Symbol _Init__Q2_3std5_TreeX...<snip> (over 2048 chars)
> from module /services/Development/Build/Server/Lib/libPersistence.a
> (AccountSimplePersistenceCache.o), but a runtime definition of
> the symbol was not found.

This error means:
1. Those symbols need to be rebounded (resolved) at program load-time.
2. Loader couldn't find definitions of those symbols in any of the
modules (libraries/shared objects) linked with the main program.

>
> There are about 27 more of these errors, most with different symbols but all
> from the same shared object, AccountSimplePersistenceCache.o.
>
> I did an nm on the shared object, but it is impossible to find the missing
> symbol by hand. The symbol spit out by the rtld is also mangled and I'm
> unable to demangle it.

Run 'dump -THv ' on AccountSimplePersistenceCache.o
".." in the IMPid column means the corresponding symbol needs to be
rebounded at the program load-time.

>
> There are 33 other shared objects in the libPersistence.a archive, all
> built the exact same way as the failing object and I don't see any errors
> from the other objects. I'm not sure if this is just the first, or if
> it's the only one with problems.

It's the only one. My test shows rtld should report all the missing
definition before exiting.

> I do not have this problem when I build the objects without the -O compiler
> option.

Compare the output of "dump -HTv" output of executable(main program) and
AccountSimplePersistenceCache.o in both cases ( w/ and w/o -O ).

> I'm building the shared object from an object archive based on a tip
> I saw in the document C_and_C++_Application_Development_on_AIX:
>
> ld -r -o tmp.o -L<bla bla> -lAccountSimplePersistenceCache
> -l<various libs to satisfy link>
> xlC -G -qmkshrobj -bloadmap:loadmap.out -oAccountSimplePersistenceCache.o
> tmp.o -l<same here>

What is "AccountSimplePersistenceCache" in the first command?
What's the relation between tmp.o and AccountSimplePersistenceCache.o?
Why use ".o", not ".so" for "AccountSimplePersistenceCache"?

I don't know much about C++. Other people might have better idea.

Tao

Gary wrote:
> I'm getting this error from the runtime linker when I launch my executable:
>
> rtld: 0712-001 Symbol _Init__Q2_3std5_TreeX...<snip> (over 2048 chars)
> from module /services/Development/Build/Server/Lib/libPersistence.a
> (AccountSimplePersistenceCache.o), but a runtime definition of
> the symbol was not found.

Some module needs to export the required symbol. It's up to you to
figure out where the symbol definition is supposed to live (i.e. what
object file it lives in). See the documentation on "ld" for details.

> I did an nm on the shared object, but it is impossible to find the missing
> symbol by hand. The symbol spit out by the rtld is also mangled and I'm
> unable to demangle it.

/usr/vacpp/bin/c++filt


> There are 33 other shared objects in the libPersistence.a archive, all
> built the exact same way as the failing object and I don't see any errors
> from the other objects. I'm not sure if this is just the first, or if
> it's the only one with problems.

The runtime lib will list all errors it finds, exhaustively. If there
are no other complaints, then there are no other problems.

> I do not have this problem when I build the objects without the -O compiler
> option.

This implies that there is some other difference in the way
the code is compiled.

> I'm using an updated version of the 5.0.2 compiler. IBM sent me a
> compilerPTF instafix to enable me to compile code with the -O option, and
> I'm not sure if the problems are related.

Unlikely.

>
> I'm building the shared object from an object archive based on a tip
> I saw in the document C_and_C++_Application_Development_on_AIX:
>
> ld -r -o tmp.o -L<bla bla> -lAccountSimplePersistenceCache
> -l<various libs to satisfy link>
> xlC -G -qmkshrobj -bloadmap:loadmap.out -oAccountSimplePersistenceCache.o
> tmp.o -l<same here>

Try removing the -G option and adding -bscalls:<filename>. The
scalls file can show you which .o file is requiring the missing
symbol, and then you can go back and look at the original source
to figure out what is happening.

--
Gary R. Hook / AIX PartnerWorld for Developers / These opinions are MINE
__________________________________________________ ______________________

"Gary R. Hook" <nospam@nospammers.net> wrote in message news:<kjMvb.422$uj3.365526063@newssvr11.news.prodi gy.com>...

> > I'm building the shared object from an object archive based on a tip
> > I saw in the document C_and_C++_Application_Development_on_AIX:
> >
> > ld -r -o tmp.o -L<bla bla> -lAccountSimplePersistenceCache
> > -l<various libs to satisfy link>
> > xlC -G -qmkshrobj -bloadmap:loadmap.out -oAccountSimplePersistenceCache.o
> > tmp.o -l<same here>
>
> Try removing the -G option and adding -bscalls:<filename>. The
> scalls file can show you which .o file is requiring the missing
> symbol, and then you can go back and look at the original source
> to figure out what is happening.

Thanks for the replies.

I removed the -G option and added the -bscalls while building the
shared objects; all three shared libraries build fine. I then
rebuild the executable and it runs fine as well.

When I rebuild the shared objects with the -G option, and relink
the executable the executable fails with the same error as before:

rtld: 0712-001 <very long symbol> from module <build
dir>/Server/Lib/libAPSPersistence.a(AccountSimplePersistenceCache. o),
but a runtime definition of the symbol was not found.


The -G is the only difference between the two builds. I run
slibclean; delete the shared archives, delete all the temporary
object files (objects that get archived) and the executable between
each build.

I've also verified that the correct object is being loaded by
the runtime linker:
d5263160 a1d05
/services/Development/Build/Server/Lib/libAPSPersistence.a/
AccountSimplePersistenceCache.o

Still not sure why this symbol is a problem and the only problem.

TIA

Gary Bak

Gary Bak wrote:
> Still not sure why this symbol is a problem and the only problem.

Add -qtwolink. Too much code (including static constructors and
what-not) is being pulled into your shared modules. Let us know
if -G -qtwolink helps.

--
Gary R. Hook / AIX PartnerWorld for Developers / These opinions are MINE
__________________________________________________ ______________________

"Gary R. Hook" <nospam@nospammers.net> wrote in message news:<zt1Cb.503
> Add -qtwolink. Too much code (including static constructors and
> what-not) is being pulled into your shared modules. Let us know
> if -G -qtwolink helps.

Ok, now I'm confused.

I built the shared objects with both the -G and -qtwolink option and
the runtime linker still failed to find the objects.

One thing that I found is that if I remove the -brtl flag from the
executable compile/link the program runs correctly.

I looked up the -brtl flag in the documentation and it says
that it A) allows you to use -l and -L for linking in shared objects
contained in an archive and B) enables the runtime linker.

Here is where it gets confusing...

Why did my program still build if I removed the -brtl flag. I would think
I'd get a linker error, since all my shared objects are in archives. And
if the rtl is disabled, when I renamed the archive libAPSPersistence.a and
ran the program, it failed for missing symbols, but why would that happen
if rtl is disabled. (Wouldn't think that the objects would get staticly
linked though.)

What is with this bizarre behavior?


Just for a recap.

Does not work:

so: xlC -G -qmkshrobj
exe: xlC -brtl

OR

so: xlC -G -qmkshrobj -qtwolink
exe: xlC -brtl


Does work:

so: xlC -qmkshrobj
exe: xlC -brtl

OR

so: xlC -G -qmkshrobj
exe: xlC


Thanks

Gary Bak