Directories Searched by the Runtime Linker

Similar Threads:

1.runtime linker failing to load symbols on some machines

Hello,

I'm having an odd problem where an executable fails to find a symbol
in a shared library.  The missing symbol is the map of maps x3 seen
in the header below.

Using the exact same executable and library, the problem is only seen
on some of our machines.  The 5.1 ML4 machine that it is compiled
on fails to load the object, another 5.1 and now a 5.3 base
level machine.  But it runs on a 5.2 and other 5.3 ML1 machines.
This code has been around for a while and has only started showing
having rtl errors in recent builds.

Any help would be appreciated.

TIA

Gary Bak

Here is the last part of the error and the files below:

<...snip>
_5_Node_v was referenced
      from module ./libtestShared.a(testShared.o), but a runtime
definition
      of the symbol was not found.

rtld: 0712-002 fatal error: exiting.


--------------------File: testLib.h -------------------
#include <map>
#include <string>
#include <vector>

void test();

std::map<std::string, std::map<std::string, std::map<std::string,
std::vector<unsigned int> > > > mapCacheOffsetByConfigSectionAndKeyID;

--------------------File: testLib.cpp -------------------
#include "testLib.h"
void test()
{

}

--------------------File: main.cpp -------------------
#include "testLib.h"
main()
{
   test();
}

--------------------File: Makefile -------------------
CPP             = xlC_r
AR              = ar

%.o:    %.cpp
        $(CPP) $(CPPFLAGS) $(BUILD_OPTIONS) $(ADD_OPTIONS)
$(INCLUDE_PATH) $(ADD_INCLUDES) -c -o $@ $<

libtestLib.a:   testLib.o
        rm -f $@
        $(AR) rcs $@ $<

testShared.o:   libtestLib.a
        $(LD) -r -o tmp.o -L. -ltestLib
        $(CPP) -G  -bernotok -qtwolink -qnamemangling=v5 -qmkshrobj
-bloadmap:loadmap.out -o$@ tmp.o

libtestShared.a:        testShared.o
        $(AR) -rv $@ $<

runme:  main.o libtestShared.a
        $(CPP) -brtl -qtwolink -bloadmap:loadmap.out -o$@ main.o -L. -l
testShared

all:    runme
clean:
        rm -f *.a *.o

2.Runtime linker reports missing symbols

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

3.Looking for some help understanding action of the runtime dynamic linker

Application A , a 32 bit application, is linked with -R
/path/to/vendors/32/bit/library -L/path/to/vendors/32/bit/library
-lclient

Before the application runs, a tool is run that sets a series of
environmental variables, including making certain that LD_LIBRARY_PATH
contains all necessary directories. This includes
/path/to/vendors/library .

In the path, that library was 32 bit. With the latest generation of
software, /path/to/vendors/library happens to be a 64 bit set of
libraries with the identical name to the 32 bit libraries.

The weird thing we are seeing is that ldd isn't pointing (incorrectly)
to the 64 bit libraries, but instead appears to be ignoring the
LD_LIBRARY_PATH and pointing to the 32 bit versions of the libraries.

I've read the ld, ld.so.1, and crle man pages, but it doesn't really
cover this level of complexity. Good old vendor shared libraries...

My hypothesis is that as the runtime linker goes looking, it realises
it is dealing with a 32 bit application, and so ignores the 64 bit
libraries and keeps looking.

Does that make sense?

4.Looking for some help understanding action of the runtime dynamic linker

Rich Teer wrote:
> On Tue, 1 Aug 2006, Larry W. Virden wrote:

>
> > Before the application runs, a tool is run that sets a series of
> > environmental variables, including making certain that LD_LIBRARY_PATH
> > contains all necessary directories. This includes
> > /path/to/vendors/library .
>
> Well for starters, LD_LIBRARY_PATH should be empty (not even defined);
> by using -L and -R, it looks like the app is built correctly.


Alas, not my decision. System admins set the path so that vendor
programs, etc. do not generate an error when applications are executed.

Or are you saying that during the compile step, one should empty the
LD_LIBRARY_PATH?



>
> > In the path, that library was 32 bit. With the latest generation of
> > software, /path/to/vendors/library happens to be a 64 bit set of
> > libraries with the identical name to the 32 bit libraries.
>
> Those 64-bit libs shouldn't be there; they should be in a subdirectory
> called 64 (so /path/to/vendors/libs/64).

I agree. Alas, what the vendor ships is what I have, and given the size
of the vendor, and my past requests for things like specifying
subdependencies when they create the libclnt library, etc. apparently
being ignored, I face dealing with the reality, rather than the ideal.


>
> > My hypothesis is that as the runtime linker goes looking, it realises
> > it is dealing with a 32 bit application, and so ignores the 64 bit
> > libraries and keeps looking.
>
> That could be the case.

Thanks for looking over it. Is there a manual or a tutorial to which I
could refer the vendor, etc. with (doomed to disappointment) hope they
might decide that the world doesn't revolve around the O* database
environment?

5.find files in one directory to use to search through another directory

HI,
I'm a beginner to intermediate user.

Here's what I am trying to do. I have a directory (call it X) with many
sub-directories with many .h files.
I want to use the names of the .h files in directory X to search
through another directory (call it Y) and see where the .h files from X
are included in the .h and .cpp files in Y.

In directory X I used the following command to find all the .h files:
find . -name "*.h"

The above command generates a list of all the .h files, but with the
path name. I don't want the path names, only the name of the file.h

Then I want to do a grep in directory Y and search in every .cpp and .h
file in Y to see if any of the .h files from X are used.

Thanks
Jami

6. Compiler/Linker option to search for .so library

7. Linker Default Search Path Additions

8. Mozilla Upgrade: Cannot find runtime directory