size of binaries/libraries are almost 2.5 times then other platforms

[pramodsharma]

Hi ,
I am using GCC 4.1 to compile my source code on HPUX 11.23 and result is libraries/binaries size are 2.5 times then other platforms(like Linux/Solaris).

Below is the way I am compiling my source code.

.o compilation
g++ -Wall -c -fPIC -D_REENTRANT -D_PSTAT64 -DPTHREAD_COMPAT_MODE -DREENTRANT

shared library
gcc -liconv -fPIC -shared -o libtest.sl. -Wl,+s,+nodefaultrpath,+b/opt/install/lib -lgcc_s -lpthread test.o -lpthread;

executable
g++ -Wl,+s,+nodefaultrpath,+b/opt/install/lib-D_PSTAT64 -lgcc_s -lstdc++ -lpthread -o test executable.o -ltest


Can anyone please let me know other than increasing the optimization level any methods/flags to decrease the size of libraries and binaries. ?

Or while releasing can I decrease the size ?

Thanks in advance ,
Pramod

[Steven Schweda]

I wonder if the hardware has something to do
with this. (If you're running on an IA64
system, try it on a PA-RISC system.)

[pramodsharma]

No it's PA-RISC architecture only. As of now we are not supporting IA architecture.

[pramodsharma]

A quick help will be appreciated as we are near to release and suddenly size is becoming issue now.

[Dennis Handly]

>I am using GCC 4.1 to compile my source code on HPUX 11.23 and result is libraries/binaries size are 2.5 times then other platforms(like Linux/Solaris).

I would expect this even more so with IPF.
How are you comparing the sizes? With size(1) or ll(1)? The SOM format has a lot of bloat, that won't show up in size(1).

If it isn't in size(1) text and data, you may want to just ignore the size increase. This bloat isn't loaded into memory.
For a better picture, you can use "odump -sommap" on a executable or shlib.

Increasing the opt level may decrease the text size but higher levels may increase it with lots of inlining or loop unrolling.

You can't decrease data.

Have you tried compiling with aC++ do see if it has the same size increase?

You can of course strip these but that would decrease debuggability and supportability.

>suddenly size is becoming issue now?

Why? You need two CDs? You could gzip things and gunzip when you install. swinstall supports that.

[pramodsharma]

Thanks. But I am already doing the stripping of my binaries/libraries.

I got your point about the text data segments. I will be looking at the size after increasing the optim level.

[Dennis Handly]

>I got your point about the text data segments. I will be looking at the size after increasing the optim level.

So how does the output of size(1) compare for each of the 3 values, for PA-RISC and other architectures?

[pramodsharma]

That I had not done yet. Will update once I go thorugh it.

[pramodsharma]

Dennis,
Do you see any issue here especially
"00001000 0fc51a 36.1% subspace 0 ($SHLIB_INFO$)" ?

What does this means and taking the maximum size?

Output of odump -sommap

Start Size % Area
-------- ------ ----- ----
00000000 000080 0.0% SOM Header
00000080 000064 0.0% Aux Header
000000e4 00003c 0.0% Init Pointers
00000120 000048 0.0% Space Dict
00000168 000398 0.0% Subspace Dict
00000500 00016c 0.0% Space Strings
0000066c 000994 0.1% (unused)
00001000 0fc51a 36.1% subspace 0 ($SHLIB_INFO$)
000fd51a 000002 0.0% (unused)
000fd51c 000950 0.1% subspace 1 ($MILLICODE$)
000fde6c 000004 0.0% (unused)
000fde70 01fec8 4.6% subspace 2 ($CODE$)
0011dd38 01e5d8 4.4% subspace 3 ($CODE$)
0013c310 000004 0.0% (unused)
0013c314 0205ac 4.6% subspace 4 ($CODE$)
0015c8c0 000004 0.0% (unused)
0015c8c4 01fc04 4.5% subspace 5 ($CODE$)
0017c4c8 01caf8 4.1% subspace 6 ($CODE$)
00198fc0 000004 0.0% (unused)
00198fc4 02025c 4.6% subspace 7 ($CODE$)
001b9220 0201b8 4.6% subspace 8 ($CODE$)
001d93d8 000004 0.0% (unused)
001d93dc 02050c 4.6% subspace 9 ($CODE$)
001f98e8 000004 0.0% (unused)
001f98ec 02030c 4.6% subspace 10 ($CODE$)
00219bf8 000004 0.0% (unused)
00219bfc 02028c 4.6% subspace 11 ($CODE$)
00239e88 020288 4.6% subspace 12 ($CODE$)
0025a110 000004 0.0% (unused)
0025a114 0167c4 3.2% subspace 13 ($CODE$)
002708d8 016200 3.2% subspace 14 ($UNWIND_START$)
00286ad8 00ef50 2.1% subspace 15 ($UNWIND_END$)
00295a28 000004 0.0% subspace 16 ($RECOVER_END$)
00295a2c 0005d4 0.1% (unused)
00296000 000004 0.0% subspace 17 ($SHORTDATA$INIT$)
00296004 000004 0.0% subspace 18 ($SHORTDATA$FINI$)
00296008 006088 0.9% subspace 19 ($DLT$)
0029c090 0089f8 1.2% subspace 20 ($PLT$)
002a4a88 015040 3.0% subspace 21 ($DATA$)
002b9ac8 000538 0.0% (unused)

[Dennis Handly]

>Do you see any issue here especially
"00001000 0fc51a 36.1% subspace 0 ($SHLIB_INFO$)"?
>What does this mean and taking the maximum size?

This is in text. It contains the names of all exported and imported symbols and their relocations. If you had a symbol definition that was only used in the lib, if you hid it, it wouldn't be there.

You really should provide the ll(1) and size(1) sizes so we can see if it is worth worrying about this lib.

If you add up all of the text you'll see that $SHLIB_INFO$ is less than half:
(gdb) p 0x0fc51a
$1 = 1033498
(gdb) p 0x296000- 0x1000
$2 = 2707456

This should give you the size(1) values:
$ odump -init /usr/lib/libc.2
Initialization pointers for /usr/lib/libc.2:
Ind Sp AC HRIL Loc/Init InitLn Start
0 0 2c H..L 0006d000 1487e4 00001000
1 1 1f H..L 001b6000 008000 40001000
2 1 1f .... 00000000 00ada0 40009000

[pramodsharma]

Hmm , Now I am learning something.

These are the outputs.
bash-3.2# ls -lrta libtest.sl.4.0
-rwx------ 1 root root 2859008 Nov 27 23:31 libtest.sl.4.0

bash-3.2# ll libtest.sl.4.0
-rwx------ 1 root root 2859008 Nov 27 23:31 libtest.sl.4.0

bash-3.2# size libtest.sl.4.0
text data bss dec hex filename
2706695 146800 6936 2860431 2ba58f libtest.sl.4.0

bash-3.2# odump -init libtest.sl.4.0

Initialization pointers for libtest.sl.4.0:

Ind Sp AC HRIL Loc/Init InitLn Start

0 0 2c H..L 00001000 294d24 00001000
1 1 1f H..L 00296000 024000 40001000
2 1 1f .... 00000000 001888 40025000

bash-3.2#

[Dennis Handly]

>These are the outputs.
>rwx------ 1 2859008 libtest.sl.4.0

If you don't make it executable to everyone, that will cost you performance, PID faults.

>2706695 146800 6936 2860431 libtest.sl.4.0

So there is little difference between ll and size, no fluff.

>0 0 2c 00001000 294d24
>1 1 1f 00296000 024000
>2 1 1f 00000000 001888

Converting to decimal:
(gdb) p 0x294d24 $1 = 2706724
(gdb) p 0x024000 $2 = 147456
(gdb) p 0x001888 $3 = 6280
Rounded up values from size(1) above. Hmm, except for BSS.