aCC large .o files

[Miguel Silva Rentes]

Hi all!

I've been compiling a simple C++ class and checked the size of the object file. In HP-UX 11.23 (64-bit architecture) I have a size of 18 KB but in a Compaq Tru64 5.1A system (also 64-bit architecture) I get a 1.2 KB!

I checked several other object files in HP-UX and in Tru64 and in HP-UX all object files are bigger (a lot bigger if I have more bigger files).

I can't seem to explain this, can you help me?

This is the simple .cpp file I tested in both systems:

//////

#include

using namespace std;

class CBase { virtual void dummy() {} };
class CDerived: public CBase { int a; };

int main () {
CBase * cBas = new CDerived();
CDerived& cDer = dynamic_cast (*cBas);
}

//////

I compiled in HP-UX with:

aCC -v +DD64 -O -c testDynaCast.cpp

and in Tru64 with:

cxx -v -c testDynaCast.cpp

Any help would be great at this point, thanks.

Best regards,

Miguel Rentes

[Pete Randall]

Keep an eye on this other, very similar thread:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1201805


Pete

[Dennis Handly]

>I've been compiling a simple C++ class and checked the size of the object file.

You shouldn't compare trivial sources. Instead you should use your real sources. And compare the output from size(1).

>I checked several other object files in HP-UX and in Tru64 and in HP-UX all object files are bigger

It is expected for the code part to be twice as big as PA, using -AA.

>This is the simple .cpp file I tested in both systems:

Using A.06.15, I get 13.7 Kb.
size(1) returns: 1034 + 184 + 9 = 1227

[Miguel Silva Rentes]

Using size(1) I get the following:

- in a Compaq Tru64 5.1A:

text data bss dec hex
208 384 0 592 250

- in a HP-UX 11.23:

1787 + 336 + 9 = 2132

In Tru64 the .o file has 1306 bytes and in HP-UX the generated .o file has 18312 bytes.

Does anybody have a clue about why this is happening or, on the other hand, if this is ok and there's nothing I can do?

Best regards

[James R. Ferguson]

HI:

> In Tru64 the .o file has 1306 bytes and in HP-UX the generated .o file has 18312 bytes.

Why does this worry you? Unless you are packaging your binaries onto something like a CDROM and limits really matter...

You could slightly reduce the size of your binary with 'strip(1)' if debugging isn't of interest.

Regards!

...JRF...

[Dennis Handly]

>- in a HP-UX 11.23:

You haven't mentioned your architecture nor compiler version. Is it PA or Integrity? (I'm assuming the latter.)

>Does anybody have a clue about why this is happening or, on the other hand, if this is ok and there's nothing I can do?

(Naturally I have a clue. :-)
There is nothing you can do about it if you are already using A.06.15.
The important thing is using size(1) on your load modules, not individual object files.

Is there any reason you need to use +DD64 and make your application 64 bit? Apples to oranges?

[Dennis Handly]

>JRF: You could slightly reduce the size of your binary with strip(1) if debugging isn't of interest.

Unfortunately it isn't slightly. A large aC++ application like ecom/ctcom is half the size when "strip -l" is done. I wouldn't recommend stripping all the way.

[Miguel Silva Rentes]

> You haven't mentioned your architecture nor compiler version. Is it PA or Integrity? (I'm assuming the latter.)

My architecture is Integrity and my HP-UX aCC compiler version is A.06.13

> Is there any reason you need to use +DD64 and make your application 64 bit? Apples to oranges?

Our main application was migrated from Compaq Tru64 Unix 5.1A, which using its C++ compiler (cxx), compiles in 64 bits by default. So I had to use the +DD64 flag to produce the same effect in HP-UX. Do you see any reason why I shouldn't use this +DD64 and compile in 64 bits?

[Dennis Handly · Accepted solution]

>my HP-UX aCC compiler version is A.06.13

(The latest version is A.06.16.)

>Our main application was migrated from Compaq Tru64 Unix 5.1A, which using its C++ compiler (cxx), compiles in 64 bits by default. So I had to use the +DD64 flag to produce the same effect in HP-UX. Do you see any reason why I shouldn't use this +DD64 and compile in 64 bits?

If you don't need the expanded address space, using 64 bit pointers/longs will bloat your data size. With only a trivial decrease in code size. Other issues are the availability of 64 bit shlibs from third parties.

So if you have kept your code clean in regards to 32 or 64 bit, you should use the 32 bit default. Otherwise, you'll need to continue using +DD64.

[Miguel Silva Rentes]

Thanks everyone for your help!

I'll check the whole source code to find out if I can compile it for 32 bits. If so, there's no need to create such big .o files.

Best regards,

Miguel Rentes

[Dennis Handly]

>if I can compile it for 32 bits. If so, there's no need to create such big .o files.

This isn't going to make the .o files that much smaller. I was worried about the executables where N users multiples any R/W data increase.