Re: Bloat in Executable

2017-11-18 Thread Petar via Digitalmars-d

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


Re: Bloat in Executable

2017-11-17 Thread Temtaime via Digitalmars-d
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.


Re: Bloat in Executable

2017-11-16 Thread Joakim via Digitalmars-d

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.


Re: Bloat in Executable

2017-11-15 Thread codephantom via Digitalmars-d
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.



Re: Bloat in Executable

2017-11-15 Thread Adam D. Ruppe via Digitalmars-d

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.


Bloat in Executable

2017-11-15 Thread codephantom via Digitalmars-d

// ---
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?