how to fnd why a particular object file is linked in a C++ exe

[RAMAKRISHNA SREEDHARA]

Hi,

We are building an exe with C++ compiler. It is linking in a particular object from a static library. When this object is deleted from the library, the exe builts fine.

Is there a way to know why a particular oject is linked into the exe?

Thanks
Rama

[James R. Ferguson]

Hi Rama:

See the manpages for 'ldd':

http://docs.hp.com/en/B2355-60130/ldd.1.html

Regards!

...JRF...

[RAMAKRISHNA SREEDHARA]

James,


ldd can be used for shared libraries or exe?
ex:
aCC -c a.c
aCC -c b.c
aCC -c c.c

ar q libA.a *o

aCC -L. a.o -lA
./a.out - runs fine
when I do strings on a.out, I see c.o linkage even when there is no link between a.c and c.c and also b.c and c.c.

Is there a way to find out why c.o is linked?

Thanks
Rama

[RAMAKRISHNA SREEDHARA]

It seems that lorder gives us a way to identify where a particular object file is called.

thanks

[Dennis Handly · Accepted solution]

>It is linking in a particular object from a static library.

(The correct terminology on HP-UX is archive lib.)

>When this object is deleted from the library, the exe builds fine.

You should not have junk in an archive that has unsats.

>Is there a way to know why a particular object is linked into the exe?

You need to use magic linker options, -t, -v and -y symbol.
For a first pass, you need to use -Wl,-t. This will list each object.
$ aCC -AA himom.C -Wl,-aarchive_shared -Wl,-t
Loading himom.o:
Loading /opt/aCC/lib/hpux32/libstd_v2.a[instance.o]:
...

Using -v tells you why:
$ aCC -AA himom.C -Wl,-aarchive_shared -Wl,-t,-v
...
Searching library /opt/aCC/lib/hpux32/libstd_v2.a:
Selecting /opt/aCC/lib/hpux32/libstd_v2.a[instance.o] to resolve std::basic_ostream >& __rw::__rw_insert,char const>(std::char_traits,< (NOT IMPLEMENTED) >*,long,long)
Loading /opt/aCC/lib/hpux32/libstd_v2.a[instance.o]:

>JRF: See the manpages for 'ldd':

ldd doesn't work on archive libs.

>ldd can be used for shared libraries or exe?

Yes, ldd works on load modules.

>Is there a way to find out why c.o is linked?

See the "Selecting" entries. You most likely have templates that are defined in multiple places and ld randomly picks an object out of the archive.

[RAMAKRISHNA SREEDHARA]

Thanks Dennis.

This gave us more data to look at. It seems its looking for that object to resolve descriptor. Code written in C is linking in C++ code to resolve "descriptor". Iam nto sure what king it is and we are still looking at it. Any idea would be really helpful.

Thanks

[RAMAKRISHNA SREEDHARA]

Sorry. Please ignore the previous message.

Thanks

[RAMAKRISHNA SREEDHARA]

Thanks all for your help..

This is what we found. Can you guys review the example below and advise me out why we are linking the cpp file? Iam new to C++ and donrt have much clue there.

A cpp file, pomb.cpp, has extern on a .h file, say tp.h. pomb.cpp uses a #define macro to use some define in tp.h file.
This tp.h file includes some other pub.h files used by the main in a C program new.c . So when we compile this new.c program using aCC, its linking in the pomb.cpp file too to resolve a variable defined in pub.h file.

pomb.cpp
#include<...>
extern "C" {
#include
}

#define ERRT ccout<<"err is "<
tp.h
#include
#define ERR_TP "TP"

new.c
#include
main()
{
printf("testing....\n");
}

Thanks...

[RAMAKRISHNA SREEDHARA]

I checked further more, when using a C compiler like 'cc' , the symbol is defined as weak in the symbol table.
Where as for C++ code, usnig aCC compiler it is not. Is this why the code is linked?

Any suggestions...

[Dennis Handly]

>Can you guys review the example below and advise me out why we are linking the cpp file?
>to resolve a variable defined in pub.h file.

I can only review what I can compile. And I don't see any variable?

extern "C" {
#include
}

This is not usually a good idea, especially if it includes some system header files. tp.h should be C++ified!

>when using a C compiler, the symbol is defined as weak in the symbol table.

Yes, it not initialized, they are tentative definitions. Also they don't belong in .h files.

>Where as for C++ code, it is not. Is this why the code is linked?

Possibly. Tentative definitions are ignored in archive lib searches.