Compiler: Size of generated executable file

Steven Schveighoffer schveiguy at yahoo.com
Tue Jan 12 22:50:45 PST 2010


On Tue, 12 Jan 2010 17:40:58 -0500, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> Steven Schveighoffer wrote:
>> I hope this is not a permanent situation.  Shared libraries (not  
>> necessarily DLLs) help reduce the memory usage of all the programs on  
>> the system that use the same libraries, and the footprint of the  
>> binaries.
>
> That would be reasonable once we can get libphobos installed on linux  
> distributions. Right now, it's easier for users to not have to deal with  
> version hell for shared libraries. Static linking of phobos does not  
> impair using D, so it is a lower priority.

As long as it's not viewed as a detriment for D to be shared-library based  
(or a "benefit" to be statically linked), I'm OK with it.  I agree that  
when shared libraries are available, the easiest distribution method would  
be an installer which put all the files in the right places.  But those  
are pretty easy to come by.

>> The "DLL hell" versioning problem AFAIK is only on Windows,
>
> My experience is different. There are two C shared libraries in common  
> use on Linux. If I link dmd to one, one group of dmd users gets annoyed,  
> if I link with the other, the other half gets annoyed. There's no decent  
> solution.

I call that distribution hell :)  You have to remember that releasing a  
binary on a Linux OS does not make that binary compatible with all other  
types of Linux OSes.  However, compiling a binary on a specific linux OS  
should make that library runnable on all later versions of that OS  
(sometimes requires installing "legacy" libs)

The solution is pretty simple however, and most companies just live with  
it -- support 3 or 4 different flavors of Linux by building a package for  
each one.  Usually it's RedHat, SuSE, Ubuntu, and Debian.  The effort it  
takes to build under 2 or 3 different environments is not that much.

The advent of full dmd source being available should relieve that problem  
anyways...

>
>> On all your other points, I agree that installs these days are bigger  
>> more because of media than binaries.  I do have a problem with that in  
>> some cases.  I don't want my scanner driver software to install 500MB  
>> of crap that I will never use when all I want to do is scan documents  
>> with a simple interface.  I don't need "skins" for my word processor or  
>> help videos on how to use my mouse.  Just install the shit that does  
>> the work, and leave the rest of my hard drive alone :)
>
> Heh, dlls won't solve that problem. I upgraded Nero to support a new dvd  
> drive, and what the heck, a 20Mb install turned into - 360Mb !!

The only thing I've found that solves this problem is -- not using  
Windows.  For some reason Linux developers still put value on small exe  
size and actual features instead of needlessly snazzy UI and exploding  
media bloat.

-Steve



More information about the Digitalmars-d mailing list