www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Striping unused code

reply Tiago Gasiba <tiago.gasiba gmail.com> writes:
Hi all,

  Is it possible to strip unused code from an executable, during compilation?
  In gcc it was possible to include something like: -ffunction-sections
-fdata-sections -Wl,--gc-sections
  Look at the following example:

--- lib.d ---
module lib;

import std.c.stdio;

void func1( int x ){
  printf("%d\n",x);
}

int func2( int x ){
  printf("%d\n",x);
  return x;
}


--- test.d ---
import std.c.stdio;
import lib;

int main(){
  func1(2);
}


-----------------
Compilation:

dmd test.d lib.d   - generates a 292651 byte file!!! (why so big?)

-> func2() is NOT used, but is included into the code:
nm test |grep func2
0804bb2c T _D3lib5func2FiZi

After stripping the code, I still obtain a 157444 byte file!!! (still large...)

Question: How can I remove unused code, such that my executable does not grow
too much in size?
(I'm almost sure that inside the executable there are still many internal and
non-used functions also)

Thanks!

Best,
Tiago Gasiba



-- 
Tiago Gasiba (M.Sc.) - http://www.gasiba.de
Everything should be made as simple as possible, but not simpler.
Nov 21 2005
next sibling parent Chris <ctlajoie yahoo.com> writes:
On Mon, 21 Nov 2005 17:26:50 +0100, Tiago Gasiba
<tiago.gasiba gmail.com> wrote:


After stripping the code, I still obtain a 157444 byte file!!! (still large...)


I tested this once myself, with a simple "int main() return 0" and the
file was excessively large. I would think unused library code could be
excluded from the file. The GC isn't *that* large.

I'm an amateur though and don't know diddly compared to you or most
anyone else in this NG. hopefully someone else can provide some
insight.

Chris
Nov 21 2005
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Tiago Gasiba wrote:

 Hi all,
 
   Is it possible to strip unused code from an executable, during compilation?
   In gcc it was possible to include something like: -ffunction-sections
-fdata-sections -Wl,--gc-sections
   Look at the following example:
 
 --- lib.d ---
 module lib;
 
 import std.c.stdio;
 
 void func1( int x ){
   printf("%d\n",x);
 }
 
 int func2( int x ){
   printf("%d\n",x);
   return x;
 }
 
 
 --- test.d ---
 import std.c.stdio;
 import lib;
 
 int main(){
   func1(2);
 }
 
 
 -----------------
 Compilation:
 
 dmd test.d lib.d   - generates a 292651 byte file!!! (why so big?)


Much of Phobos appears to be linked in whether you use it or not.  When 
I try this against Ares the resulting executable is 64,028 bytes.


 Question: How can I remove unused code, such that my executable does not grow
too much in size?
 (I'm almost sure that inside the executable there are still many internal and
non-used functions also)


Isn't there a version of strip for Win32?  I could have sworn I saw one 
at some point.


Sean
Nov 21 2005
next sibling parent reply Chris <ctlajoie yahoo.com> writes:
On Mon, 21 Nov 2005 10:03:56 -0800, Sean Kelly <sean f4.ca> wrote:

Isn't there a version of strip for Win32?  I could have sworn I saw one 
at some point.


I am not aware of strip, but does it do something similar to upx?
http://upx.sourceforge.net
I haven't tested upx on D programs yet, but I know it's very well
known for making VB apps about 15% of their original size.

Chris
Nov 21 2005
parent reply James Dunne <james.jdunne gmail.com> writes:
Chris wrote:

 On Mon, 21 Nov 2005 10:03:56 -0800, Sean Kelly <sean f4.ca> wrote:
 

Isn't there a version of strip for Win32?  I could have sworn I saw one 
at some point.


 
 
 I am not aware of strip, but does it do something similar to upx?
 http://upx.sourceforge.net
 I haven't tested upx on D programs yet, but I know it's very well
 known for making VB apps about 15% of their original size.
 
 Chris


UPX is an executable compressor, not a symbol stripper.  It guarantees 
no data loss in the compressed data.  It does this by compressing the 
executable code and data and redirecting the executable's main entry 
point to a pre-cooked decompression routine which decompresses all the 
data into memory and then resumes execution at the normal entry point. 
*phew*
Nov 21 2005
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
James Dunne wrote:

 Chris wrote:
 

 On Mon, 21 Nov 2005 10:03:56 -0800, Sean Kelly <sean f4.ca> wrote:


 Isn't there a version of strip for Win32?  I could have sworn I saw 
 one at some point.




 I am not aware of strip, but does it do something similar to upx?
 http://upx.sourceforge.net
 I haven't tested upx on D programs yet, but I know it's very well
 known for making VB apps about 15% of their original size.

 Chris


 
 
 UPX is an executable compressor, not a symbol stripper.  It guarantees 
 no data loss in the compressed data.  It does this by compressing the 
 executable code and data and redirecting the executable's main entry 
 point to a pre-cooked decompression routine which decompresses all the 
 data into memory and then resumes execution at the normal entry point. 
 *phew*


Besides AFAIK some versions of UPX don't support the digitalmars 
.exe-format. Maybe this has been fixed by now. On Linux it's possible to 
compact dmd-generated files quite a lot with strip & upx. OTOH upx does 
some implicit stripping at least when used on djgpp .exes.
Nov 21 2005
parent Tiago Gasiba <tiago.gasiba gmail.com> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jari-Matti Mäkelä schrieb:

 
 Besides AFAIK some versions of UPX don't support the digitalmars
 .exe-format. Maybe this has been fixed by now. On Linux it's possible to
 compact dmd-generated files quite a lot with strip & upx. OTOH upx does
 some implicit stripping at least when used on djgpp .exes.


In Linux UPX works fine! Further, gdc also strips the code perfectly:

gdc -ffunction-sections -fdata-sections -c lib.d
gdc -ffunction-sections -fdata-sections -c test.d
gdc -ffunction-sections -fdata-sections -Wl,--gc-sections -o test test.o lib.o
ll
insgesamt 412
- -rw-------  1 gasiba users    140 2005-11-22 10:19 lib.d
- -rw-------  1 gasiba users   1400 2005-11-22 10:19 lib.o
- -rwx------  1 gasiba users 404962 2005-11-22 10:20 test
- -rw-------  1 gasiba users     62 2005-11-22 10:19 test.d
- -rw-------  1 gasiba users   1244 2005-11-22 10:19 test.o
nm test | grep func2  -> finds nothing!
strip test
ll test
- -rwx------  1 gasiba users 120092 2005-11-22 10:21 test
upx --best test
ll test
- -rwx------  1 gasiba users 53979 2005-11-22 10:21 test

Before UPX compression, the file is still very large! ca 120K !

IMHO the problem is that the linker might only be able to remove entire
sections and not only pieces of code.
The following was taken (long time back) from another post somewhere on the
internet (don't remember from where):

<snip>
The trick is to add the -ffunction-sections option to gcc (and maybe
-fdata-sections), and add the --gc-sections option to ld.

The -ffunction-sections option to gcc will tell it to put every function inits
own section, for example "void foo(void)" will end up in ".text.foo".
Likewise the -fdata-sections option will tell gcc to put every data/bss
variable in its own section by adding the dot-variable name as a suffix to the
default section.

The --gc-sections option to ld will tell it to remove all sections that are not
referenced.
<snip>

Maybe DMD is not putting every piece of code in its own section and GDC is
(because it uses GCC code!).
This would be an interesting feature to have (in DMD).
Although GDC does a great job with striping the code, it totally fails to
compile my libraries, with internal compiler errors (due to the high usage of
complex number arithmetic - where GDC is still a bit buggy).

Best,
Tiago

- -- 
Tiago Gasiba (M.Sc.) - http://www.gasiba.de
Everything should be made as simple as possible, but not simpler.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDguYtDiEXU+4zMkURAorAAJoDeLTJbLSsCRfwAEfliz9vynHw1wCfZSfU
ebyvSxKw5Z1eHpp9Q3hhe0E=
=Lvdg
-----END PGP SIGNATURE-----
Nov 22 2005
prev sibling parent reply MicroWizard <MicroWizard_member pathlink.com> writes:
Phobos is huge it is clear, but there are still problems with Ares.

Under win32 the library make does not work:
- references to \bin\dmd\ etc. which is hardcoded and not the "DM standard"
- namespace conflicts (maybe these are burden in DMD deeply AFAIK)

I have tried to link the precompiled ares library (phobos.lib)
to oe of my live D projects and some modules were missing.
Ex. The Error class, some ToString, ToInt, etc.

I know all of these small can be patched easily but not all of us
are "system programmer"/hacker.

Ares would be very nice. Some minor changes are only needed.
I am looking forward to see newer versions.

Tamás Nagy


Much of Phobos appears to be linked in whether you use it or not.  When 
I try this against Ares the resulting executable is 64,028 bytes.


 Question: How can I remove unused code, such that my executable does not grow
too much in size?
 (I'm almost sure that inside the executable there are still many internal and
non-used functions also)


Isn't there a version of strip for Win32?  I could have sworn I saw one 
at some point.

Sean
Nov 22 2005
parent Sean Kelly <sean f4.ca> writes:
MicroWizard wrote:

 Phobos is huge it is clear, but there are still problems with Ares.
 
 Under win32 the library make does not work:
 - references to \bin\dmd\ etc. which is hardcoded and not the "DM standard"


The Ares makefiles are styled after the Phobos makefiles (as I'm not a 
makefile expert) and they do contain hard path references, but these are 
at the top of each makefile.  Changing them should take all of 10 seconds.


 - namespace conflicts (maybe these are burden in DMD deeply AFAIK)


Please explain.


 I have tried to link the precompiled ares library (phobos.lib)
 to oe of my live D projects and some modules were missing.
 Ex. The Error class, some ToString, ToInt, etc.


Yup.  Ares is still in its infancy and it makes no attempt to duplicate 
what's in Phobos... even down to that level.  It's really just a minimal 
D runtime library at the moment, separated into three sub-libraries for 
ease of maintenance.


 I know all of these small can be patched easily but not all of us
 are "system programmer"/hacker.
 
 Ares would be very nice. Some minor changes are only needed.
 I am looking forward to see newer versions.


This has been an extremely busy fall for me, but I should have more time 
in a few weeks :-)


Sean
Nov 22 2005
prev sibling next sibling parent reply John Demme <me teqdruid.com> writes:
No, it's not possible to do this during compilation.  It is the compiler's
job to take all of the methods/functions and put them in the object file. 
The compiler doesn't necessarily know what symbols are going to be used and
what aren't.

This is a task for the linker- one that I'm surprised it doesn't do already
by default.  There's probably a reason for this, but I don't know what it
is... anyone?

~John Demme

Tiago Gasiba wrote:


 Hi all,
 
   Is it possible to strip unused code from an executable, during
   compilation? In gcc it was possible to include something like:
   -ffunction-sections -fdata-sections -Wl,--gc-sections Look at the
   following example:
 
 --- lib.d ---
 module lib;
 
 import std.c.stdio;
 
 void func1( int x ){
   printf("%d\n",x);
 }
 
 int func2( int x ){
   printf("%d\n",x);
   return x;
 }
 
 
 --- test.d ---
 import std.c.stdio;
 import lib;
 
 int main(){
   func1(2);
 }
 
 
 -----------------
 Compilation:
 
 dmd test.d lib.d   - generates a 292651 byte file!!! (why so big?)
 
 -> func2() is NOT used, but is included into the code:
 nm test |grep func2
 0804bb2c T _D3lib5func2FiZi
 
 After stripping the code, I still obtain a 157444 byte file!!! (still
 large...)
 
 Question: How can I remove unused code, such that my executable does not
 grow too much in size? (I'm almost sure that inside the executable there
 are still many internal and non-used functions also)
 
 Thanks!
 
 Best,
 Tiago Gasiba
Nov 21 2005
parent reply James Dunne <james.jdunne gmail.com> writes:
Perhaps when linking an object file with a static library, it might be 
more difficult to relink the static library and eliminate parts of it 
than to treat the static library as one big linking unit and link it in 
as a whole.

I'm no expert in linkers by any means, but I can't think of why this 
couldn't or shouldn't be done.

John Demme wrote:

 No, it's not possible to do this during compilation.  It is the compiler's
 job to take all of the methods/functions and put them in the object file. 
 The compiler doesn't necessarily know what symbols are going to be used and
 what aren't.
 
 This is a task for the linker- one that I'm surprised it doesn't do already
 by default.  There's probably a reason for this, but I don't know what it
 is... anyone?
 
 ~John Demme
 
 Tiago Gasiba wrote:
 
 

Hi all,

  Is it possible to strip unused code from an executable, during
  compilation? In gcc it was possible to include something like:
  -ffunction-sections -fdata-sections -Wl,--gc-sections Look at the
  following example:

--- lib.d ---
module lib;

import std.c.stdio;

void func1( int x ){
  printf("%d\n",x);
}

int func2( int x ){
  printf("%d\n",x);
  return x;
}


--- test.d ---
import std.c.stdio;
import lib;

int main(){
  func1(2);
}


-----------------
Compilation:

dmd test.d lib.d   - generates a 292651 byte file!!! (why so big?)

-> func2() is NOT used, but is included into the code:
nm test |grep func2
0804bb2c T _D3lib5func2FiZi

After stripping the code, I still obtain a 157444 byte file!!! (still
large...)

Question: How can I remove unused code, such that my executable does not
grow too much in size? (I'm almost sure that inside the executable there
are still many internal and non-used functions also)

Thanks!

Best,
Tiago Gasiba
Nov 21 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Hmm, now I know why some people hate top-posting. If I comment both 
James's and John's stuff here, my comments seem inconsistent because of 
the "wrong" order I have to write them too. (I'll try to shift my 
thoughts around some, to make it less obvious. But it's more work for 
me. ;-(

James Dunne wrote:

 Perhaps when linking an object file with a static library, it might
 be more difficult to relink the static library and eliminate parts of
 it than to treat the static library as one big linking unit and link
 it in as a whole.


The linker would then have to have knowledge of possible internal 
dependencies between functions in the library. And it would have to have 
knowledge of which functions will be called from the linked program.

It's not impossible, but I guess it would be much easier to write a 
linker if the library contained hints on which functions in the library 
call others.


 I'm no expert in linkers by any means, but I can't think of why this 
 couldn't or shouldn't be done.
 
 John Demme wrote:
 

 No, it's not possible to do this during compilation. It is the 
 compiler's job to take all of the methods/functions and put them in
 the object file. The compiler doesn't necessarily know what symbols
 are going to be used and what aren't.

 This is a task for the linker- one that I'm surprised it doesn't do
  already by default. There's probably a reason for this, but I
 don't know what it is... anyone?
 ~John Demme




See above.

If the linker had the knowledge I wrote above, then it would be easy, 
because the linker already knows which functions the main executable calls.


 Tiago Gasiba wrote:

  Is it possible to strip unused code from an executable, during
  compilation? In gcc it was possible to include something like:
  -ffunction-sections -fdata-sections -Wl,--gc-sections Look at the
  following example:






Old Turbo Pascal compilers (maybe newer too, but I haven't used them for 
some time) used to throw out unused code from the program. It analyzed 
what parts of code were unused, and skipped them before compilation.

So, if you had the equivalent of the following D code,

if(1==0)
{
     // lots of code
}
else
{
     // some other code
}

then the "lots of code" part would be entirely skipped. And 
interestingly those compilers were still the fastest Pascal compilers 
around!

I don't remember whether code in linked libraries was skipped too. But 
HelloWorld was quite small!!!

Oh, times change. In the Old Days, one used to respect a customer's disk 
space. And today it's not just executables, it's a lot of other crap. 
Acrobat Reader, Real Player, they're the worst. 90% of the crap hasn't 
even to do with what they're for -- it's there for marketing and other 
not-asked-for things.

Not that FSF is any better. Even a Linux distro where source is not 
specifically included, virtually every smallest file that they've ever 
laid their hands on, contains a kilobyte of their copyright 
declarations. That adds up to apalling numbers real quickly.


 --- lib.d ---
 module lib;

 import std.c.stdio;

 void func1( int x ){
  printf("%d\n",x);
 }

 int func2( int x ){
  printf("%d\n",x);
  return x;
 }


 --- test.d ---
 import std.c.stdio;
 import lib;

 int main(){
  func1(2);
 }
 -----------------
 Compilation:

 dmd test.d lib.d   - generates a 292651 byte file!!! 
 (why so big?)

 -> func2() is NOT used, but is included into the code:
 nm test |grep func2
 0804bb2c T _D3lib5func2FiZi

 After stripping the code, I still obtain a 157444 byte file!!! (still
 large...)






I just tried the following on (DMD .139) Linux:

-----libtest1.d:
import std.c.stdio;
void main(){}
-----libtest2.d:
void main(){}
-----libtest3.d:
int main() {return 0;}

And got the following sizes:
libtest1 291704
libtest2 291704
libtest3 291704

This is actually a lot more than I got about a year ago. Hmm.


 Question: How can I remove unused code, such that my executable
 does not grow too much in size? (I'm almost sure that inside the
 executable there are still many internal and non-used functions
 also)






Haven't tried it with D, but at least Turbo Pascal manuals contained 
explanations on what you should do if you know that there are library 
functions that you know you don't want to use. There was a nice 
Librarian with which you could very easily trim a library to your own 
needs. Or even make one with some of theirs and some of your own stuff.

On Linux, try "man strip". There are many options for discarding 
different things from the executable. And after that you could try the 
executable compression somebody mentioned on this thread.

But still, it would be cool to have a compiler + linker that 
aggressively skip everything useless!
Nov 22 2005
next sibling parent reply Tiago Gasiba <tiago.gasiba gmail.com> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Georg Wrede schrieb:

 
 Haven't tried it with D, but at least Turbo Pascal manuals contained
 explanations on what you should do if you know that there are library
 functions that you know you don't want to use. There was a nice
 Librarian with which you could very easily trim a library to your own
 needs. Or even make one with some of theirs and some of your own stuff.


Well, but that's a problem! For me, the concept of a library is something where
you can "throw" a lot of code and it gets stored as "in a library".
You just need to call it (import) by its name to get access to its functions.
Now, imagine you are using a single function from a huge library and, you
didn't even wrote that library.
Its extremely difficult to keep track of each individual function.
If you only use one function from that library you expect that all the other
"trash" evaporates after linkage!
Therefore, it is a must that the compiler and/or linker can throw away unused
code!
I can not imagine putting each function in a separated library and importing
each and every library individually, although this would certainly strip unused
code :)


 On Linux, try "man strip". There are many options for discarding
 different things from the executable. And after that you could try the
 executable compression somebody mentioned on this thread.


Yes, but there are two problems with this approach!
First, "strip" is used to discard symbols, not code (sections), i.e. stuff that
might be used by a debugger, another linker, etc...
Second, compression software solve make the file smaller but are "fooling" the
user, in the sense that uncompressed files still have all that trash inside!

There are many many of good reasons why to cut unused code and as to why we
should remove symbolic information, for example HD space, etc...



 But still, it would be cool to have a compiler + linker that aggressively skip
everything useless!


I would say that, not only cool but highly required/necessary!

Best,
Tiago

- -- 
Tiago Gasiba (M.Sc.) - http://www.gasiba.de
Everything should be made as simple as possible, but not simpler.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDgvNWDiEXU+4zMkURAu6bAKCE7qOucVh6Q2adzfnyf3Y0AGXZywCfesCp
iNsPOSgkCxYuft7JOYaonzY=
=N0mE
-----END PGP SIGNATURE-----
Nov 22 2005
parent reply Don Clugston <dac nospam.com.au> writes:
Tiago Gasiba wrote:

 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 Georg Wrede schrieb:
 

Haven't tried it with D, but at least Turbo Pascal manuals contained
explanations on what you should do if you know that there are library
functions that you know you don't want to use. There was a nice
Librarian with which you could very easily trim a library to your own
needs. Or even make one with some of theirs and some of your own stuff.


 
 Well, but that's a problem! For me, the concept of a library is something
where you can "throw" a lot of code and it gets stored as "in a library".
 You just need to call it (import) by its name to get access to its functions.
 Now, imagine you are using a single function from a huge library and, you
didn't even wrote that library.
 Its extremely difficult to keep track of each individual function.
 If you only use one function from that library you expect that all the other
"trash" evaporates after linkage!
 Therefore, it is a must that the compiler and/or linker can throw away unused
code!
 I can not imagine putting each function in a separated library and importing
each and every library individually, although this would certainly strip unused
code :)


I agree entirely. If everything gets linked in, IT IS NOT A LIBRARY.
It's just a massive .obj file which has a .lib extension!
It's like needing to bring a semitrailer with you when you want to 
borrow a library book, because all the books in your local library are 
stapled together...

The way it used to work, was every .cpp file put in the library went 
into its own section. Using one function from it pulled in the section 
that it was in (ie, pulled in the original .obj file). Now, it could be 
that all D modules end up in in a single section in the library. As a 
quick-n-dirty hack to get the language going, that's OK -- but in the 
longer term, it's something that needs to be fixed.
Imagine if Phobos grew to be as extensive as the .NET libraries. A 
'hello world' app could be 25Mb in size! Bingo, one of the selling 
points of D is gone.
Nov 23 2005
next sibling parent Tiago Gasiba <tiago.gasiba gmail.com> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Don Clugston schrieb:

 
 The way it used to work, was every .cpp file put in the library went
 into its own section. Using one function from it pulled in the section
 that it was in (ie, pulled in the original .obj file). Now, it could be
 that all D modules end up in in a single section in the library.


I'm even going one step further and telling that putting every function in a
individual section would be advantageous.
The example that I've first posted contained a single library with two
functions.
What happens (I think) is that DMD puts  both functions in the same section (we
only have one library/module).
In the main file, only function 1 is used, not function 2, but since they are
both in the same section, function 2 gets into the same executable.
The "-ffunction-sections -fdata-sections -Wl,--gc-sections" GCC compiler flags
tell the compiler to do exactly that - put every function in its own section.
The linker can, therefore, discard those sections (i.e. individual functions)
that are not used even if they are come from the same module.
Note that with GDC this feature is present, but not with DMD!
I would propose (in the future) adding support to DMD to allow separating every
function into its own section.

Tiago

- -- 
Tiago Gasiba (M.Sc.) - http://www.gasiba.de
Everything should be made as simple as possible, but not simpler.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDhDbwDiEXU+4zMkURAhBaAKCFGneoYDB3xEoTbSicl3l+nclziQCfWYz1
EQToDd6rjZkQmq9upUsTsns=
=TVPU
-----END PGP SIGNATURE-----
Nov 23 2005
prev sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Don Clugston wrote:

 Tiago Gasiba wrote:

 Georg Wrede schrieb:
 

 Haven't tried it with D, but at least Turbo Pascal manuals
 contained explanations on what you should do if you know that
 there are library functions that you know you don't want to use.
 There was a nice Librarian with which you could very easily trim
 a library to your own needs. Or even make one with some of theirs
 and some of your own stuff.


 
 Well, but that's a problem! For me, the concept of a library is 
 something where you can "throw" a lot of code and it gets stored as
  "in a library". You just need to call it (import) by its name to
 get access to its functions. Now, imagine you are using a single
 function from a huge library and, you didn't even wrote that
 library. Its extremely difficult to keep track of each individual
 function. If you only use one function from that library you expect
 that all the other "trash" evaporates after linkage! Therefore, it
 is a must that the compiler and/or linker can throw away unused
 code! I can not imagine putting each function in a separated
 library and importing each and every library individually, although
 this would certainly strip unused code :)


 
 I agree entirely. If everything gets linked in, IT IS NOT A LIBRARY. 
 It's just a massive .obj file which has a .lib extension! It's like
 needing to bring a semitrailer with you when you want to borrow a
 library book, because all the books in your local library are stapled
 together...
 
 The way it used to work, was every .cpp file put in the library went
  into its own section. Using one function from it pulled in the
 section that it was in (ie, pulled in the original .obj file). Now,
 it could be that all D modules end up in in a single section in the
 library. As a quick-n-dirty hack to get the language going, that's OK
 -- but in the longer term, it's something that needs to be fixed. 
 Imagine if Phobos grew to be as extensive as the .NET libraries. A 
 'hello world' app could be 25Mb in size! Bingo, one of the selling 
 points of D is gone.


I agree with you both! (I just offered a workaround for now.)

BTW, as another temporary workaround, somebody posted recently a shell 
script that I think could be modified into creating the smallest library 
containing the needed stuff for a specific program.

So the script would try to compile, then read the error messages, copy 
all the mentioned library routines into a temporary library which then 
would be linked in.

Granted, slow and kludgy, but a possibility.
And automatic. :-)
Nov 23 2005
prev sibling parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Georg Wrede wrote:

 Old Turbo Pascal compilers (maybe newer too, but I haven't used them for 
 some time) used to throw out unused code from the program. It analyzed 
 what parts of code were unused, and skipped them before compilation.
 
 So, if you had the equivalent of the following D code,
 
 if(1==0)
 {
     // lots of code
 }
 else
 {
     // some other code
 }
 
 then the "lots of code" part would be entirely skipped. And 
 interestingly those compilers were still the fastest Pascal compilers 
 around!


I agree. Some compiler black magic needed here ;)


 Oh, times change. In the Old Days, one used to respect a customer's disk 
 space. And today it's not just executables, it's a lot of other crap. 
 Acrobat Reader, Real Player, they're the worst. 90% of the crap hasn't 
 even to do with what they're for -- it's there for marketing and other 
 not-asked-for things.
 
 Not that FSF is any better. Even a Linux distro where source is not 
 specifically included, virtually every smallest file that they've ever 
 laid their hands on, contains a kilobyte of their copyright 
 declarations. That adds up to apalling numbers real quickly.


Quite a lot of FSF & other old code written in C are total bull***t. 
First there is the rcs header, then some copyright stuff, then some 
unnecessary includes and finally some undocumented ioccc stuff.


 I just tried the following on (DMD .139) Linux:
 
 -----libtest1.d:
 import std.c.stdio;
 void main(){}
 -----libtest2.d:
 void main(){}
 -----libtest3.d:
 int main() {return 0;}
 
 And got the following sizes:
 libtest1 291704
 libtest2 291704
 libtest3 291704


I got 295105 (DMD .139 + Linux) -> 157396 (strip -s) -> 56778 (upx)! 
Although this is not much, I'm afraid that bigger programs will get 
dangerously bloated. I've only done some small stuff with DUI and the 
resulting binary was already 2,5 MB in size!
Nov 22 2005
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Mon, 21 Nov 2005 17:26:50 +0100, Tiago Gasiba wrote:


 Hi all,
 
   Is it possible to strip unused code from an executable, during compilation?


If you are using DigitalMars linker, OptLink, as called by dmd, then you
might get some savings by using the /PACKFUNCTIONS switch on the linker.

e.g.

   dmd test.d -L/PACKFUNCTIONS
 
-- 
Derek Parnell
Melbourne, Australia
22/11/2005 9:39:57 PM
Nov 22 2005