www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Bloat in Executable

reply codephantom <me noyb.com> writes:
// -----------------------------------
module test;

import core.stdc.stdio;

extern (C) int main()
{
     printf("hello world\n");
     return 0;
}
// -----------------------------------


compiled with dmd v2.077.0, using the -betterC option, I get:

.. on windows ..
23k executable if 32bit (i.e. -m32 )
112k executable if 64bit (i.e. -m64 )

.. on freebsd ..
5.6k executable if 32bit (i.e. -m32 )
7.5k executable if 64bit (i.e. -m64 )

This is not meant to be an anti-windows thing...so let me stop 
those responses right here.

I am genuinely interested in understanding why the 'order of 
magnitude' increase for the 64bit executable on Windows?
Nov 15
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 16 November 2017 at 03:32:26 UTC, codephantom wrote:
 23k executable if 32bit (i.e. -m32 )
It is the statically linked C library. Note that if you remove the call to printf, the size is slashed in half. Windows traditionally didn't do a system-wide C lib, but rather the various compiler vendors would do their own. To keep this from being a big pain for the end user, static linking can be employed as it apparently is with Digital Mars.
 112k executable if 64bit (i.e. -m64 )
I'm not 100% sure this is the same, but I suspect it probably is.
 .. on freebsd ..
 5.6k executable if 32bit (i.e. -m32 )
If you ldd that, you'll see it dynamically links the C library. The downside of this is there's less binary compatibility across major versions; you are liable to need to recompile from source to deal with different libc versions on the system, whereas the Windows builds are more likely to just work.
Nov 15
next sibling parent codephantom <me noyb.com> writes:
On Thursday, 16 November 2017 at 03:58:38 UTC, Adam D. Ruppe 
wrote:
 It is the statically linked C library. Note that if you remove 
 the call to printf, the size is slashed in half.

 Windows traditionally didn't do a system-wide C lib, but rather 
 the various compiler vendors would do their own. To keep this 
 from being a big pain for the end user, static linking can be 
 employed as it apparently is with Digital Mars.
Thanks Adam. I understand better now.
Nov 15
prev sibling parent reply Temtaime <temtaime gmail.com> writes:
On Thursday, 16 November 2017 at 03:58:38 UTC, Adam D. Ruppe 
wrote:
 On Thursday, 16 November 2017 at 03:32:26 UTC, codephantom 
 wrote:
 23k executable if 32bit (i.e. -m32 )
It is the statically linked C library. Note that if you remove the call to printf, the size is slashed in half. Windows traditionally didn't do a system-wide C lib, but rather the various compiler vendors would do their own. To keep this from being a big pain for the end user, static linking can be employed as it apparently is with Digital Mars.
 112k executable if 64bit (i.e. -m64 )
I'm not 100% sure this is the same, but I suspect it probably is.
 .. on freebsd ..
 5.6k executable if 32bit (i.e. -m32 )
If you ldd that, you'll see it dynamically links the C library. The downside of this is there's less binary compatibility across major versions; you are liable to need to recompile from source to deal with different libc versions on the system, whereas the Windows builds are more likely to just work.
There is system-wide C library. It is named msvc.dll. TCC uses it producing very small executables.
Nov 17
parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Friday, 17 November 2017 at 18:53:57 UTC, Temtaime wrote:
 On Thursday, 16 November 2017 at 03:58:38 UTC, Adam D. Ruppe 
 wrote:
 [...]
There is system-wide C library. It is named msvc.dll. TCC uses it producing very small executables.
https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273
Nov 18
prev sibling parent Joakim <dlang joakim.fea.st> writes:
On Thursday, 16 November 2017 at 03:32:26 UTC, codephantom wrote:
 // -----------------------------------
 module test;

 import core.stdc.stdio;

 extern (C) int main()
 {
     printf("hello world\n");
     return 0;
 }
 // -----------------------------------


 compiled with dmd v2.077.0, using the -betterC option, I get:

 .. on windows ..
 23k executable if 32bit (i.e. -m32 )
 112k executable if 64bit (i.e. -m64 )

 .. on freebsd ..
 5.6k executable if 32bit (i.e. -m32 )
 7.5k executable if 64bit (i.e. -m64 )

 This is not meant to be an anti-windows thing...so let me stop 
 those responses right here.

 I am genuinely interested in understanding why the 'order of 
 magnitude' increase for the 64bit executable on Windows?
If you're worried about executable size, you're probably better off using ldc on non-Windows platforms, because David made ldc work with the linker's --gc-sections. I don't think that work was ever done for dmd, which is why ldc invokes --gc-sections by default for non-MSVC targets but dmd doesn't.
Nov 16