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:

  import core.stdc.stdio;
  void main() {
    printf("hello world!\n");
  }


… the size is now down to 334744 bytes [w/o any stripping], i.e. 326.8984375 kbytes for those so inclined.  The length of the output from "nm" for _this_ executable is 1552 lines [again, w/o any stripping].

— Abe

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

> 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'
[nothing found]
  > find . -iname '*dylib*'  #  please note the extra '*' at the end
  ./src/druntime/src/rt/dylib_fixes.c


Reading "./src/druntime/src/rt/dylib_fixes.c" seems to indicate that DMD has at least _some_ support for Mac OS X dynamic libraries, but IDK how much and under which circumstances.


If anybody with a Windows installation of DMD would care to chime in, I`d be interested to read what that side of the triangle looks like vis-a-vis the linking and size-of-executable issue/issues.

My thanks again to Adam.

— Abe

On Monday, 1 September 2014 at 01:20:02 UTC, Abe wrote:
> If anybody with a Windows installation of DMD would care to chime in, I`d be interested to read what that side of the triangle looks like vis-a-vis the linking and size-of-executable issue/issues.

The Windows version of dmd 2.067 seems to do a better job, with the executable coming in at 144 KB for the 32-bit version linked with optlink and 270 KB for the 64-bit version linked with the MS linker.

I believe the blocker on shared libraries for OS X is getting TLS working across multiple D shared libraries.

On 01/09/14 01:51, Abe wrote:

> The question: why is Hello World so frickin` huge?!?

The runtime and standard library is statically linked, compared to C where it's dynamically linked. Also unnecessary symbols are not stripped. DMD on OS X doesn't currently support dynamic libraries. LDC has the --gc-sections flag, enabled by default. This will significantly reduce the since of the binary.

-- 
/Jacob Carlborg

On 01/09/14 01:57, Abe wrote:
> … that is, the problem whereby DMD produces _huge_ executables for tiny
> programs.

Yes, dynamic libraries are currently only properly supported on Linux.

-- 
/Jacob Carlborg

On 01/09/14 02:10, Abe wrote:
> 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 those library files is not being used in the
> currently-being-linked object file.

It's not just a problem with the linker on OS X. The same problem exists on Linux and Windows as well. On Linux with LDC the --gc-sections flag is used which will reduce the binary size.

-- 
/Jacob Carlborg

On 01/09/14 03:20, Abe wrote:

> Reading "./src/druntime/src/rt/dylib_fixes.c" seems to indicate that DMD
> has at least _some_ support for Mac OS X dynamic libraries, but IDK how
> much and under which circumstances.

Dynamic libraries are not yet properly supported.

> If anybody with a Windows installation of DMD would care to chime in,
> I`d be interested to read what that side of the triangle looks like
> vis-a-vis the linking and size-of-executable issue/issues.

The size is just as bad there.

-- 
/Jacob Carlborg

On Monday, 1 September 2014 at 06:07:39 UTC, Joakim wrote:
> The Windows version of dmd 2.067 seems to do a better job, with the executable coming in at 144 KB for the 32-bit version linked with optlink and 270 KB for the 64-bit version linked with the MS linker.

Sorry, I measured with the official release of dmd 2.066.0 on Windows 7 x64 and miswrote the version as 2.067.

On Monday, 1 September 2014 at 07:36:44 UTC, Joakim wrote:
> On Monday, 1 September 2014 at 06:07:39 UTC, Joakim wrote:
>> The Windows version of dmd 2.067 seems to do a better job, with the executable coming in at 144 KB for the 32-bit version linked with optlink and 270 KB for the 64-bit version linked with the MS linker.
>
> Sorry, I measured with the official release of dmd 2.066.0 on Windows 7 x64 and miswrote the version as 2.067.

Oh, I also wanted to say that in this day and age of fast internet connections and large disk drives, a basic runtime size cost of less than half a MB is nothing and not worth worrying about.  My smartphone model that came out two years ago has 64 GB of space, I have trouble finding HD videos to fill it up with. :)

We should try to minimize binary size, simply because all optimizations are helpful, but it's not a high priority.  If you're trying to use D in the embedded space, as Adam and others have, presumably you know what you're doing and can hack it down yourself.