Re: LDC has the --gc-sections flag, etc.

2014-09-01 Thread Abe via Digitalmars-d
First: thanks to Joakim and yourself for all the recent replies. unnecessary symbols are not stripped. I think that`s the most essential part of why Hello world came out so big for me. LDC has the --gc-sections flag, enabled by default. This will significantly reduce the since of the

why does DMD compile hello world to about 500 _kilobytes_ on Mac OS X [x86_64]?!?

2014-08-31 Thread Abe via Digitalmars-d
Dear all, Me: a very experienced computer programmer, a newbie to D. The test program: import std.stdio; void main() { writeln(hello world!); } The result: ls -l foo -rwxr-xr-x 1 Abe wheel 502064 Aug 31 18:47 foo file foo foo: Mach-O 64-bit executable

Oh, and I almost forgot: does this problem exist on any other platforms too? …

2014-08-31 Thread Abe via Digitalmars-d
… that is, the problem whereby DMD produces _huge_ executables for tiny programs.

line counts of outputs of nm from the object and executable from the above source code

2014-08-31 Thread Abe via Digitalmars-d
nm foo.o | wc -l 176 nm foo | wc -l 2162

Re: The std.stdio package imports most the standard library etc.

2014-08-31 Thread Abe via Digitalmars-d
Thanks, Adam. Is this roughly the same on all relevant platforms for DMD? I was thinking [hoping?] that maybe this was a problem vis-a-vis the Mac OS X linker, i.e. a situation such that the linker isn`t dropping anything from the referenced libraries, even when the majority of the stuff in

Re: The std.stdio package imports most the standard library etc.

2014-08-31 Thread Abe via Digitalmars-d
Compared to them, D programs are small. The big difference is Java, .net, ruby, python, etc. are already popular enough to have their libraries/support code pre-installed on the user's computer. D programs, on the other hand, carry all their support code with them in each executable (they're

statically linked vs. Mac OS X

2014-08-31 Thread Abe via Digitalmars-d
BTW: FYI: at least on recent-enough versions of Mac OS X, from what I have read, Apple has effectively forbidden _true_ static linking, i.e. executables with no dynamic-library dependencies whatsoever. Here`s the relevant result from the D-based hello world executable: otool -L foo

Re: If you used printf instead of writeln

2014-08-31 Thread Abe via Digitalmars-d
On Monday, 1 September 2014 at 01:02:27 UTC, Abe wrote: BTW: FYI: at least on recent-enough versions of Mac OS X, from what I have read, Apple has effectively forbidden _true_ static linking, i.e. executables with no dynamic-library dependencies whatsoever. Here`s the relevant result from

Re: If you used printf instead of writeln […] [ignore previous post]

2014-08-31 Thread Abe via Digitalmars-d
Sorry: accidentally hit something on the keyboard that the Mac and/or Chromium interpreted as post it right now. :-( This msg. is to confirm that If you used printf instead of writeln […], from an above msg. from Adam, is also correct on Mac OS X [64-bit Intel]. Given this source code:

Re: -defaultlib=libphobos2

2014-08-31 Thread Abe via Digitalmars-d
You can do it on Linux with dmd right now (use dmd -defaultlib=libphobos2.so when building), but I don't know about the Mac, and not sure about Windows either. Well, it doesn`t look feasible with the current DMD for Mac OS X: cd /opt/Digital_Mars_D_2.066.0 find . -iname '*dylib'

Re: printf-based D code

2014-08-31 Thread Abe via Digitalmars-d
Also: the same printf-based D code as I gave in my previous post results in the following [still Mac OS X 64-bit Intel]. nm bar.o | wc -l 22 strip bar nm bar | wc -l 915 — Abe