> Short term and long term suggestions ? Anything we can do ?

I'm using UniLink.

> import std.stdio;
> int main(){
> writefln("Hello Bloat!");
> return 0;
> }

On Windows:
DMD v2.056
UniLink 1.07 build 3.21

---
import std.stdio;
int main()
{
   writefln("Hello World!");
   return 0;
}
---
dmd.exe -I"C:\DMD2\src\phobos" -c helloworld.d -of"helloworld.obj" ulink.exe -ap -zsnn.lib -L"C:\DMD2\windows\lib" -L"C:\DMC\lib" -Go "helloworld.obj", "helloworld.exe", , phobos.lib, , ---

helloworld.exe = 276 Kb

"Trass3r" <un@known.com> wrote in message news:op.v6ai1yjc3ncmek@enigma...
>> Right, but my point is, I could work around (I've gotten within inches of it!) it if simply Walter released a TINY part of snn.lib -- just a handful of tiny source files regarding the TLS-related stuff, EXE segment markers, and whatnot. (I've already raised this issue before, and precisely what we would need, but it seemed to go completely ignored.)
>
> Nag again and again :)

That's how we got "-wi" ;)

On 2011-12-10 16:39, Bane wrote:
> Short term and long term suggestions ? Anything we can do ? I heard it
> is some problem with linking dead code?
>
>
>
> import std.stdio;
> int main(){
> writefln("Hello Bloat!");
> return 0;
> }
>
> dmd -release -O hello.d
>
> On Windows:
> v1.071 = 339 Kb
> v2.056 = 1017 Kb
>
> It looks very ugly and might distract some people.

As long as the runtime and standard library is statically linked the executables will be bigger than the corresponding C/C++ executable.

-- 
/Jacob Carlborg

Jacob Carlborg Wrote:
> As long as the runtime and standard library is statically linked the executables will be bigger than the corresponding C/C++ executable.

I just want to say it's very important to me that static linking
still just works very easily even if we start to offer dynamic linking.

On Sunday, December 11, 2011 17:28:58 Adam Ruppe wrote:
> Jacob Carlborg Wrote:
> > As long as the runtime and standard library is statically linked the executables will be bigger than the corresponding C/C++ executable.
> 
> I just want to say it's very important to me that static linking
> still just works very easily even if we start to offer dynamic linking.

Most definitely. I consider dynamic linking to be a necessary evil which should not be used unless you have to. I _much_ prefer having my programs completely self-contained. The less that they rely on in terms of external libraries the better. Sure, there are plenty of cases where dynamic libraries are necessary (e.g. plugins), and the fact that they generally reduce disk space consumption is useful, but it's _so_ nice to not have to worry about the exact versions of everything else installed on the system.

- Jonathan M Davis

> Most definitely. I consider dynamic linking to be a necessary evil which should
> not be used unless you have to. I _much_ prefer having my programs completely
> self-contained. The less that they rely on in terms of external libraries the
> better. Sure, there are plenty of cases where dynamic libraries are necessary
> (e.g. plugins), and the fact that they generally reduce disk space consumption
> is useful, but it's _so_ nice to not have to worry about the exact versions of
> everything else installed on the system.
>
> - Jonathan M Davis

Nobody cares about disk space this time. Imagine x00 applications run in memory with
exact copy of libc.

Oleg. 

On 2011-12-11 23:55, Jonathan M Davis wrote:
> On Sunday, December 11, 2011 17:28:58 Adam Ruppe wrote:
>> Jacob Carlborg Wrote:
>>> As long as the runtime and standard library is statically linked the
>>> executables will be bigger than the corresponding C/C++ executable.
>>
>> I just want to say it's very important to me that static linking
>> still just works very easily even if we start to offer dynamic linking.
>
> Most definitely. I consider dynamic linking to be a necessary evil which should
> not be used unless you have to. I _much_ prefer having my programs completely
> self-contained. The less that they rely on in terms of external libraries the
> better. Sure, there are plenty of cases where dynamic libraries are necessary
> (e.g. plugins), and the fact that they generally reduce disk space consumption
> is useful, but it's _so_ nice to not have to worry about the exact versions of
> everything else installed on the system.
>
> - Jonathan M Davis

It is very nice to not have to think about external dependencies when installing a tool or library, but as you say for plugins it is important. I would hope that it is possible to have the application completely statically linked but at the same time provide plugins for the application.

-- 
/Jacob Carlborg

You can try with upx :)

Il giorno lun, 12/12/2011 alle 14.42 +0100, Jacob Carlborg ha scritto:

> On 2011-12-11 23:55, Jonathan M Davis wrote:
> > On Sunday, December 11, 2011 17:28:58 Adam Ruppe wrote:
> >> Jacob Carlborg Wrote:
> >>> As long as the runtime and standard library is statically linked the executables will be bigger than the corresponding C/C++ executable.
> >>
> >> I just want to say it's very important to me that static linking
> >> still just works very easily even if we start to offer dynamic linking.
> >
> > Most definitely. I consider dynamic linking to be a necessary evil which should not be used unless you have to. I _much_ prefer having my programs completely self-contained. The less that they rely on in terms of external libraries the better. Sure, there are plenty of cases where dynamic libraries are necessary (e.g. plugins), and the fact that they generally reduce disk space consumption is useful, but it's _so_ nice to not have to worry about the exact versions of everything else installed on the system.
> >
> > - Jonathan M Davis
> 
> It is very nice to not have to think about external dependencies when installing a tool or library, but as you say for plugins it is important. I would hope that it is possible to have the application completely statically linked but at the same time provide plugins for the application.
> 

The symbol table.
Probably you also had debug infos for phobos?
By the way if I strip this, my executable is only 292K.

On Sat, 10 Dec 2011 20:16:54 +0100, Trass3r <un@known.com> wrote:

>> import std.stdio;
>> int main(){
>>    writefln("Hello Bloat!");
>>    return 0;
>> }
>>
>> dmd -release -O hello.d
>>
>> On Windows:
>> v1.071 = 339 Kb
>> v2.056 = 1017 Kb
>
> $ dmd -release -O test.d
> 867K
> $ strip -s test
> 572K
>
> I don't know where the 300KB come from.
> The map files are equal:
> dmd -release -O -map test.d
> dmd -release -O -L-s -map test.d
>
>
> This is what Hello World looks like on x64 Linux:
> http://thecybershadow.net/d/mapview/view.php?id=4ee3af86c32f2

Am 12.12.2011, 20:33 Uhr, schrieb Martin Nowak <dawg@dawgfoto.de>:

> The symbol table.
> Probably you also had debug infos for phobos?
Possible.

> By the way if I strip this, my executable is only 292K.

32bits?