Difference in size for an object file for the same source built in different directories.

[Raghava_1]

Hi,

Am working on an HPUX IA 64 machine [machine details and compiler details below]

As seen, the object file for even a simple src containing just 'int main() { return 0;}' differs in size when compiled (/opt/aCC/bin/aCC -c) in different directories. Is this the expected behaviour of aCC?

This results in difference in size of the resulting shared object built too.

Is this an anomaly? or it this the normal behaviour? If so, is there any specific reason behind this phenomenon.

Kindly help me understand the issue/details involved.

Am a newbie with regard to HPUX, so kindly be elaborate in the answers so that I could follow the same.

Thnx in advance!

Details:

$/opt/aCC/bin/aCC --version
aCC: HP C/aC++ B3910B A.06.12 [Nov 03 2006]
$uname -a
HP-UX thebox B.11.31 U ia64 1270485177 unlimited-user license

other details derived thru machinfo
-----------------------------------
Platform info:
Model: "ia64 hp server rx6600"

OS info:
Nodename: thebox
Release: HP-UX B.11.31
Version: U (unlimited-user license)
Machine: ia64
ID Number: 1270485177
vmunix _release_version:
@(#) $Revision: vmunix: B.11.31_LR FLAVOR=perf

[Raghava_1]

Sample run:

> cat > a.c
int main(){ return 0;}
> /opt/aCC/bin/aCC -c a.c
> cd c2
/c2> /opt/aCC/bin/aCC -c ../a.c
/c2> cd c3
/c2/c3> /opt/aCC/bin/aCC -c ../../a.c
/c2/c3> cd c4
/c2/c3/c4> /opt/aCC/bin/aCC -c ../../../a.c
/c2/c3/c4> cd c5
/c2/c3/c4/c5> /opt/aCC/bin/aCC -c ../../../../a.c
/c2/c3/c4/c5> cd ../../../../
> find ./ -name a.o |xargs ls -lrt
-rw-r--r-- 1 u33 u33 2448 Feb 25 20:15 ./a.o
-rw-r--r-- 1 u33 u33 2472 Feb 25 20:15 ./c2/a.o
-rw-r--r-- 1 u33 u33 2488 Feb 25 20:15 ./c2/c3/a.o
-rw-r--r-- 1 u33 u33 2512 Feb 25 20:15 ./c2/c3/c4/a.o
-rw-r--r-- 1 u33 u33 2532 Feb 25 20:16 ./c2/c3/c4/c5/a.o
>

[Steven Schweda]

strings ./a.o
strings ./c2/c3/c4/c5/a.o

man strip

Why do you care?

[Dennis Handly]

>Is this the expected behaviour of aCC?

Yes, the PWD and file paths are recorded in the object file.

[Raghava_1]

@steven: Thnx!

imho, stripping symbol table and debug information off the binaries does not result in same size. (as checked)

output from 'strings' for different .o files doesn't have a diff too. (as redirected to a file and diff -bw 'd)

@dennis: Thnx!
Cool! But, should not this be taken off when we run the binaries through strip? This behaviour is not seen in gcc/any other compiler, if am right. Any binary security related funda involved? /* to prevent address prediction etc, apart from the standard PIC stuff */
Please correct me if am wrong!

Thnx n Rgds!
_raghava_

[Dennis Handly · Accepted solution]

>stripping symbol table and debug information off the binaries does not result in same size.

If you use strip(1) on objects, you should use "strip -l".

>should not this be taken off when we run the binaries through strip?

Unfortunately no. .note sections aren't strippable. (I have already filed an enhancement on that.)
elfdump -dc a.o

>Any binary security related fundamentals involved? /* to prevent address prediction

Possibly IP issues.