Bug 410 - Why are the binaries so HUGE
Summary: Why are the binaries so HUGE
Status: CLOSED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Build environment (show other bugs)
Version: 3.0.0preX
Hardware: All Windows NT
: P3 normal
Target Milestone: none
Assignee: Tim Potter
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-09-05 07:10 UTC by Christer Matson
Modified: 2005-11-14 09:30 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Christer Matson 2003-09-05 07:10:02 UTC 
Am I the only one having this problem? The sizes of my samba 3 binaries are in
the tens of MegaBytes as reported by my file system. I have tried setting all
debug info flags to no, but no difference.

Here are some examples of the file sizes:
/bin/net        28.3 Mibyte
/bin/testparm   11.9 Mibyte
/sbin/smbd      43.0 Mibyte
/sbin/nmbd      21.1 Mibyte

What have I done wrong, or what might be wrong?

Christer
Comment 1 Gerald (Jerry) Carter (dead mail address) 2003-09-05 07:27:55 UTC 
the binaries were probably compiled with -g.
Run `strip /usr/local/samba/*bin/*`
Comment 2 Tim Potter 2003-09-05 17:30:16 UTC 
If you are using gcc 3.x then you need to compile with -gstabs instead of just
-g.  In newer versions of gcc a lot (i.e an extra 18MB) more debugging
information is generated.  Using -gstabs lets you keep debugging information you
lose by stripping but keeps the executables a reasonable size.

If you configure Samba with ./configure.developer instead of ./configure then
-gstabs is put in for you.
Comment 3 Gerald (Jerry) Carter (dead mail address) 2005-02-07 09:05:41 UTC 
originally reported against one of the 3.0.0rc[1-4] releases.
Cleaning up non-production versions.
Comment 4 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:19:18 UTC 
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.
Comment 5 Gerald (Jerry) Carter (dead mail address) 2005-11-14 09:30:24 UTC 
database cleanup