Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-02-24 17:03:17


I'm trolling for expertise here. Boost.Python (v2) modules are shared
libraries on Windows and Unix, and the size differences of the resulting
libraries are astounding.

Actually, why don't I just give some numbers for a particular extension
(BUILD=release <optimization>space <inlining>on):

                 Raw Stripped
Cygwin-3.0.3 1768330 274944
MinGW-2.95-3 363237 140288
gcc-3.0.3/linux 244585 174292
KCC on OSF 212296 147520
Intel-Win32 69632
CodeWarrior7/Win 58880
MSVC6 49152

I'm not /too/ concerned about what I'm seeing with Cygwin/MinGW since there
are other options on that platform, though I'd still very much like to see
some improvement. One point that may be playing a factor is that these
extension modules have a single exported entry point on Windows, so the
compiler should be able to compile-away unreferenced code, whereas Unices
typically assume everything needs to be exported. AFAIK, though, the only
code which could conceivably fit the "compilable-away" category is generated
by templates (and thus referenced by definition).

My questions are:

1. Does anyone know of a "magic bullet" for decreasing the size of C++
shared libs on Unix (and secondarily, with GCC on any platform)?

2. It looks like Unix linkers generally admit "-s" as an option which
indicates that symbols should be stripped from the result. Does it make
sense to apply this whenever <optimization>space is specified?


                  David Abrahams
      C++ Booster ( O__ ==
      Pythonista ( c/ /'_ ==
  resume: (*) \(*) ==
          email: david.abrahams_at_[hidden]

Boost list run by bdawes at, gregod at, cpdaniel at, john at