RE: [pooma-dev] [QMTrack] new issue kcc_auto_oneper

[Dave Nystrom]

I think the --one_per option for EDG based compilers is able to both prevent
multiple symbol definition warnings and reduce code bloat in the final
executable.  In terms of the multiple symbol definition warnings, a simple
example could be that you have two libraries which each have a .o in them
that among other things includes some templates from say vector<double>.  If
the executable references symbols in each of these .o files, then the loader
will pull them both in if static linking is being used and you will get a
multiple symbol definition warning.  However, if you use the --one_per option
then each of the vector<double> templates will be in a separate .o file and
the linker only has to pull one in.  In a similar fashion, the executable can
be smaller if you have a lot of template code because it does not have to
pull in a bunch of functions it does not need just to get one it does need.
Using library closure also prevents multiple symbol definitions in many cases
but it is not usually practical to close libraries against all the lower
level C++ libraries that you might need to link against.

Having said all that, I have an interesting story to share:-).  We just
recently tried compiling our Pooma 2 based code using static libraries and
--one_per in an effort to get around the problem of the SGI C compiler's
quadratic scaling with the size of the C file when doing unoptimized debug
builds.  We also decided not to use our explicit instantiation libraries
mainly because they were so big that they made the SGI loader croak.  The
result of all this was that we built what may very well be the world's first
multi-gigabyte library.  The size of our libphysicsbeta.a library was a hefty
2.4 gigabytes:-).  In our work, we have discovered that at least with KCC,
static libraries are bigger than shared libraries and using the --one_per
option more than doubles the size of the library.  Well, the SGI loader can't
handle a 2.4 GB library either.  So, I don't think we will be using --one_per
until SGI fixes the problem with their loader.

Dave Nystrom                    email: address@hidden
LANL X-3                        phone: 505-667-7913     fax: 505-665-3046

Julian C. Cummings writes:
 > I'm a little baffled by this because I always 
 > thought that the --oneper flag in KCC was a 
 > convenience meant to slim down executable sizes,
 > not a necessity to avoid multiple definition
 > errors.  We have not set the --oneper flag as 
 > the default in the past because it makes KCC
 > builds painfully slow.  Could you please cite
 > an example or two of things that don't build 
 > correctly in Pooma without the --oneper flag?
 > Maybe someone with access to the KCC compiler
 > could have a look and see if we are doing 
 > something fundamentally wrong when building 
 > Pooma codes under KCC.  For example, multiple
 > definition errors usually come from not properly
 > resolving object files against one another at
 > prelinking time before the actual link step.
 > 
 > Julian C.
 > 
 > 
 > > -----Original Message-----
 > > From: address@hidden [mailto:address@hidden
 > > Sent: Thursday, September 27, 2001 3:43 PM
 > > To: address@hidden
 > > Subject: [pooma-dev] [QMTrack] new issue kcc_auto_oneper
 > > 
 > > 
 > > The issue kcc_auto_oneper was created by oldham on 2001-09-27 16:43 MDT.
 > > 
 > >   Issue ID: kcc_auto_oneper
 > >   Modification Time: 2001-09-27 16:43 MDT
 > >   Modifying User: oldham
 > >   State: submitted
 > >   Summary: When Using KCC, --oneper Should Be Default
 > >   Categories: correctness
 > >   Discussion: None
 > >   Description: 
 > >       KCC needs the --one_per flag to avoid multiple template 
 > >       instantiations.  The --oneper Pooma configuration flag causes 
 > >       --one_per to be passed to KCC.  This should be the deafault for 
 > >       KCC: both Stephen and I regularly trip over this. 
 > >       
 > >       
 > >   Assignee: oldham
 > > 
 >