Conference turris::digital_unix

9633.0. "Large object/binary executeables, dynamic??" by KERNEL::PULLEY (Come! while living waters flow) Mon Apr 28 1997 07:09

Hi,

I've a customer using Digital UNIX v4.0b, C++ v5.5-004.
This is based on notes c_plus_plus 3500.*.
He gets large object and binary files E.g., >30 meg for a binary file for
one of his small programs.

Rather than sending us lots of code, he's cut it down to a small example,
but in doing so has made an assumption.
I.e., real but not very big programs give him large files, so a really small
example giving sizeable object & executeable, could be showing the same
problem.
This smallest example we've been working with is:-
#include <vector>
int main(){}

With that example, using the GNU compiler he got an object file of 1K--with
DEC's compiler he got an object of 24K.
(Again here we're assuming that a bigger object file, would lead to a bigger
executeable).

I've posted a note here for a couple of reasons:-
Though it does look to me quite C++ish, I'm not sure if there's some UNIX
I'm missing, particularly as I've heard the comment that dynamic executeables
are more likely to be smaller.
In the tests below it is not.
Also they've come out not stripped, does that simply mean I didn't use the
-compress on the compilation or is there another way of stripping files?
The tests below are on Digital UNIX v3.2 148--I haven't got a v4.0b with C++
to hand yet, so I can't use -compress anyway.
Is the difference between the object size on disk, and data+text from the size
command, just telling me howmany symbols C++ thinks it needs or something?

Thanks for any comments or suggestions,
Steve.

csh> cxx -K -g0 -O1 -nocleanup -noinline -non_shared -om -o tm.out tm.cxx
csh> ls -l tm.*
-rw-r--r--   1 sjp      system        35 Apr 11 15:38 tm.cxx
-rw-r--r--   1 sjp      system     20000 Apr 25 15:16 tm.o
-rwxrwxr-x   1 sjp      system    362760 Apr 25 15:16 tm.out
csh> size tm.o
text    data    bss     dec     hex
3536    2320    48      5904    1710
csh> file tm.out
tm.out: COFF format alpha demand paged executable or object module not stripped 
- version 3.11-8 
csh> cxx -K -g0 -O1 -nocleanup -noinline -om -o tm.out tm.cxx
Warning: -om doesn't work -call_shared.  -om switch is ignored.
csh> ls -l tm.*
-rw-r--r--   1 sjp      system        35 Apr 11 15:38 tm.cxx
-rw-r--r--   1 sjp      system     20000 Apr 25 15:24 tm.o
-rwxrwxr-x   1 sjp      system     49152 Apr 25 15:25 tm.out
csh> size tm.o
text    data    bss     dec     hex
3536    2320    48      5904    1710
csh> file tm.out
tm.out: COFF format alpha dynamically linked, demand paged executable or object 
module not stripped - version 3.11-8 

        <<< TURRIS::DISK$NOTES_PACK:[NOTES$LIBRARY]C_PLUS_PLUS.NOTE;2 >>>
                                    -< C++ >-
================================================================================
Note 3500.7      Large objects/executable images, small source??          7 of 7
DECCXX::MITCHELL                                     38 lines  28-APR-1997 15:00
               -< Probably we're not looking at the right thing >-
--------------------------------------------------------------------------------
I think we might be chasing down a rabbit hole here.  

DIGITAL UNIX 9633 says:

              <<< TURRIS::DISK$NOTES_PACK2:[NOTES$LIBRARY]DIGITAL_UNIX.NOTE;1 >>>
                                   -< DIGITAL UNIX >-
    ===========================================================================
    Note 9633.0        Large object/binary executeables, dynamic??        No re
    KERNEL::PULLEY "Come! while living waters flow"      59 lines  28-APR-1997 
    ---------------------------------------------------------------------------
    Hi,

    I've a customer using Digital UNIX v4.0b, C++ v5.5-004.
    This is based on notes c_plus_plus 3500.*.
    He gets large object and binary files E.g., >30 meg for a binary file for
    one of his small programs.

    Rather than sending us lots of code, he's cut it down to a small example,
    but in doing so has made an assumption.
    I.e., real but not very big programs give him large files, so a really small
    example giving sizeable object & executeable, could be showing the same
    problem.

This probably isn't a good assumption.

I think it would make more sense to try to find out what's going on with
the large application.

I noticed in DIGITAL UNIX 9633 that the compilation is done with -g0.  What sizes
does the customer see when compiling with and without -g?

DIGITAL UNIX 9633 also says:

    Also they've come out not stripped, does that simply mean I didn't use the
    compress on the compilation or is there another way of stripping files?

-compress affects the size of object files, not executables.  Executables can be 
stripped using strip.  What this does is remove the debug symbol table information.