kicad-developers team mailing list archive

["daystar1013" <daystar@...>]

--- In kicad-devel@xxxxxxxxxxxxxxx, Dick Hollenbeck <dick@...> wrote:
>
> 
> > Hi,
> >
> > I have successfully compiled the last two releases of Kicad using 
> > Microsoft compilers. There are a number of things I have to do to 
> > make it work. My goal here is to make a minimal impact on the 
source 
> > code.
> > You may ask "what is my motivation for doing this?", the 
following 
> > directory listings demonstate the answer clearly.
> >
> > mingw
> > 11/29/2007 11:51 AM 6,303,776 cvpcb.exe
> > 11/29/2007 11:51 AM 6,274,696 gerbview.exe
> > 11/29/2007 11:51 AM 7,471,808 eeschema.exe
> > 11/30/2007 08:16 AM 5,825,800 kicad.exe
> > 11/29/2007 11:51 AM 7,974,909 pcbnew.exe
> > msvc 7.1
> > 12/10/2007 01:02 PM 2,383,872 cvpcb.exe
> > 12/10/2007 11:33 AM 2,359,296 gerbview.exe
> > 12/10/2007 10:31 AM 2,928,640 eeschema.exe
> > 12/10/2007 02:45 PM 2,199,552 kicad.exe
> > 12/10/2007 11:53 AM 3,141,632 pcbnew.exe
> >   
> 
> This seems unlikely to be an apples to apples comparison. I know 
that:
> 
> 1) the mingw build is a static linking of the wxWidgets library to 
the 
> executable. Is the msvc a static or dynamic linking? I'll assume 
> dynamic. Therefore, you would have to add the size of the 
wxWidgets.DLL 
> to each exe file to get an apples to apples comparison.
> 
> 2) the mingw build seems to have debugging symbols in the *.exe 
files.  
> Run the mingw strip.exe program on your windows binaries *.exe to 
remove 
> another ~3 mbytes per binary.
> 
> > When running kicad on a Terminal Server, size does matter.
> >   
> 
> I thought a terminal server ran the app on the server, so the app 
does 
> not need to travel accross the wire? Are you saying the RAM 
footprint 
> within the terminal server is an issue? Realize that the 3 mbytes 
per 
> *.exe of symbols may not be loaded into process space under 
windows. I 
> don't know why it should be.
> 
> Also, it is likely that the sum of the dynamic wxWidgets.DLL and 
msvc 
> EXE is larger than the size of the statically linked g++ exe simply 
> because the static linking builds in only code that is actually 
used.  
> Whereas the DLL has to be built as a worse case binary, 
incorporating 
> everything.
> 
> 
> If this still does not persuade you, maybe you can:
> 
> 1) file a bug report with Microsoft, saying their free compiler is 
less 
> than free (negative free = expensive), in that it won't compile a 
> program that g++ does and it is costing people time. They have 
more 
> man-hours available to support their compiler than I do.
> 
> 2) maintain your own patches and apply them each time you need to 
build.
> 
> 3) get SVN write permission from Igor and apply them yourself.
> 
> 4) Pray that someone else who does have write access and has time 
to 
> spend on a Microsoft problem will do this for you.
> 
> 
> Dick
>
Dick,
You were correct, the linker -s option is not working. After running 
stip I see the following reduction in file sizes. Still not enough 
for me to stop compiling on VC++ since VC++ executables are still 47% 
the size of the stripped Mingw files.

Mingw 
11/29/2007 11:51 AM 6,303,776 cvpcb.exe
11/29/2007 11:51 AM 7,471,808 eeschema.exe
11/29/2007 11:51 AM 6,274,696 gerbview.exe
11/30/2007 08:16 AM 5,825,800 kicad.exe
11/29/2007 11:51 AM 7,974,909 pcbnew.exe

Mingw after running strip.exe
01/08/2008 11:45 AM 4,506,624 cvpcb.exe
01/08/2008 11:47 AM 5,476,352 eeschema.exe
01/08/2008 11:47 AM 4,493,312 gerbview.exe
01/08/2008 11:47 AM 4,185,088 kicad.exe
01/08/2008 11:48 AM 5,893,632 pcbnew.exe

MSVC 7
12/10/2007 01:02 PM 2,383,872 cvpcb.exe
12/10/2007 10:31 AM 2,928,640 eeschema.exe
12/10/2007 11:33 AM 2,359,296 gerbview.exe
12/10/2007 02:45 PM 2,199,552 Kicad.exe
12/10/2007 11:53 AM 3,141,632 pcbnew.exe