"The std.stdio package imports most the standard library" etc.

[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) so they have better odds of just working without the 
> user
> needing to install other stuff that they prolly don't already 
> have.

Ah, yes.  I was wondering why large amount of code originating in 
something called a "standard library" was apparently being shoved 
into an executable.  I guess at this point in the life of Dlang, 
it is not yet realistic to expect users to have e.g. 
"libdlang.so" in their "/usr/lib".

It would be nice to have an option to use a systemwide library 
file and dynamically link it; that way, as a silly example, I 
could have 10 different D-based "hello world"-sized programs` 
executables and only one copy of the relevant library code [well, 
at least of _most_ of it].

BTW: I see what you meant about statically linked:

   > ls -lh /opt/Digital_Mars_D/lib
   -r--r--r--  1 Abe  staff    34M Aug 16 09:08 libphobos2.a

… only an "ar" archive, no ".dylib" file [basically the Mac OS X 
equivalent of an ".so" file].  :-(

Do you think DMD and Phobos2 could be massaged into giving us the 
dynamically-linked option with a small-enough amount of time & 
effort, at least for the first platform to get that option?  [I`m 
guessing that here, "first" effectively implies "easiest to 
implement".]

Do you know if GDC and/or LDC do this in a way that makes for 
small Hello Worlds?  I haven`t yet successfully installed either 
one of those, sorry, so I can`t test it myself yet.

Thanks again.

— Abe