From: Mauro S. <mau...@sm...> - 2013-11-06 10:39:29
|
Hi to all, I have a question regarding size of generated executables. Until today I compile a small console executable with MinGW C++ compiler under Windows (using NetBeans IDE, but it does not matters I think). Generated executable size is 233 Kb. Mingw g++ version is 4.7.2. Now I'm trying MinGW C++ compiler under Linux (real Linux, not Wine) to compile same code, and with the same compilation and linking flags (Netbeans project under Windows imported in Netbeans under Linux) I have a working executable sized 158 Kb. Mingw g++ version is 4.2.1. I use also "-static-libgcc" and "-static-libstdc++" options . The only difference that I see during compilation is that the latter option was rejected on Linux compiler (browsing the web I found that this option was added in a later release, but seems that "-static-libgcc" forces also statically linking of libstdc++ ). So I suspected that libstdc++ was linked dynamic, but Process Explorer shows that loaded dlls are the same for both executables. This behaviour sounds me strange: a recent compiler produces a bigger code than an old one. So my question: is it normal or I'm loosing something? Thanks in advance, regards Mauro |
From: Eli Z. <el...@gn...> - 2013-11-06 10:50:40
|
> Date: Wed, 06 Nov 2013 11:19:42 +0100 (CET) > From: Mauro Salvini <mau...@sm...> > > Until today I compile a small console executable with MinGW C++ compiler under Windows (using NetBeans IDE, but it does not matters I think). Generated executable size is 233 Kb. Mingw g++ version is 4.7.2. > Now I'm trying MinGW C++ compiler under Linux (real Linux, not Wine) to compile same code, and with the same compilation and linking flags (Netbeans project under Windows imported in Netbeans under Linux) I have a working executable sized 158 Kb. Mingw g++ version is 4.2.1. Are the sizes after stripping the executables? If not run 'strip' on them, and then compare. Otherwise, you are likely comparing the size of debug info, where the more, the better. |
From: Mauro S. <mau...@sm...> - 2013-11-06 12:40:38
|
>> Until today I compile a small console executable with MinGW C++ compiler under Windows (using NetBeans IDE, but it does not matters I think). Generated executable size is 233 Kb. Mingw g++ version is 4.7.2. >> Now I'm trying MinGW C++ compiler under Linux (real Linux, not Wine) to compile same code, and with the same compilation and linking flags (Netbeans project under Windows imported in Netbeans under Linux) I have a working executable sized 158 Kb. Mingw g++ version is 4.2.1. > Are the sizes after stripping the executables? If not run 'strip' on > them, and then compare. Otherwise, you are likely comparing the size > of debug info, where the more, the better. No, I didn't any strip. But after stripping I got a 93Kb executable with MinGW on Linux and a 166Kb executable with MinGW on Windows. Thank you |
From: Eli Z. <el...@gn...> - 2013-11-06 17:06:40
|
> Date: Wed, 06 Nov 2013 13:40:29 +0100 (CET) > From: Mauro Salvini <mau...@sm...> > > No, I didn't any strip. But after stripping I got a 93Kb executable with MinGW on Linux and a 166Kb executable with MinGW on Windows. It's possible that on Windows, GCC pulls much more code from libgcc. Also, the object formats are different (pe-coff vs elf), so this comparison might not be meaningful even after stripping. |
From: Peter R. <p.r...@sh...> - 2013-11-06 17:41:38
|
On 06/11/13 17:06, Eli Zaretskii wrote: >> Date: Wed, 06 Nov 2013 13:40:29 +0100 (CET) >> From: Mauro Salvini <mau...@sm...> >> >> No, I didn't any strip. But after stripping I got a 93Kb executable with MinGW on Linux and a 166Kb executable with MinGW on Windows. > It's possible that on Windows, GCC pulls much more code from libgcc. > > Also, the object formats are different (pe-coff vs elf), so this > comparison might not be meaningful even after stripping. > Can the OP clarify here: Does "MinGW on Linux" mean a cross-compiler, or the Linux-native compiler that Eli's comment about PE-COFF vs. ELF above implies? (I took it to mean a cross-compiler.) P. |
From: Mauro S. <mau...@sm...> - 2013-11-07 07:10:39
|
>>> No, I didn't any strip. But after stripping I got a 93Kb executable with MinGW on Linux and a 166Kb executable with MinGW on Windows. >> It's possible that on Windows, GCC pulls much more code from libgcc. >> >> Also, the object formats are different (pe-coff vs elf), so this >> comparison might not be meaningful even after stripping. >> > Can the OP clarify here: Does "MinGW on Linux" mean a cross-compiler, or > the Linux-native compiler that Eli's comment about PE-COFF vs. ELF above > implies? (I took it to mean a cross-compiler.) Yes, " MinGW on Linux" means a cross-compiler, sorry for misunderstanding. |
From: Eli Z. <el...@gn...> - 2013-11-07 15:58:59
|
> Date: Thu, 07 Nov 2013 08:10:30 +0100 (CET) > From: Mauro Salvini <mau...@sm...> > > >>> No, I didn't any strip. But after stripping I got a 93Kb executable with MinGW on Linux and a 166Kb executable with MinGW on Windows. > >> It's possible that on Windows, GCC pulls much more code from libgcc. > >> > >> Also, the object formats are different (pe-coff vs elf), so this > >> comparison might not be meaningful even after stripping. > >> > > Can the OP clarify here: Does "MinGW on Linux" mean a cross-compiler, or > > the Linux-native compiler that Eli's comment about PE-COFF vs. ELF above > > implies? (I took it to mean a cross-compiler.) > > > Yes, " MinGW on Linux" means a cross-compiler, sorry for misunderstanding. Then it's my misunderstanding, sorry. In that case, you may wish comparing the output of objdump, and perhaps doing that also on individual *.o files (to see if the difference is due to different code that was generated from your sources, or something else). |
From: Mauro S. <mau...@sm...> - 2013-11-11 10:23:04
|
> In that case, you may wish comparing the output of objdump, and > perhaps doing that also on individual *.o files (to see if the > difference is due to different code that was generated from your > sources, or something else). Comparing final executables evidences that there are some different function references in mscvrt.dll section, but the major difference is that on Linux side executable haven't .eh_fram, .CRT and .tls sections. Furthermore, I'm not familiar with these things, could you point me where I can learn about? Thanks, regards. |
From: Peter R. <p.r...@sh...> - 2013-11-11 10:49:43
|
On 11/11/13 10:22, Mauro Salvini wrote: > > In that case, you may wish comparing the output of objdump, and > > perhaps doing that also on individual *.o files (to see if the > > difference is due to different code that was generated from your > > sources, or something else). > > Comparing final executables evidences that there are some different > function references in mscvrt.dll section, but the major difference is > that on Linux side executable haven't .eh_fram, .CRT and .tls sections. > > Furthermore, I'm not familiar with these things, could you point me > where I can learn about? > > > MSDN is the obvious source - see msdn.*microsoft*.com/en-us/library/windows/hardware/gg463119.aspx? .tls is thread local storage. I can find no mention of the other sections although you could guess at 'C run time' and 'exception handling' although why the former section is missing from the cross-built executable is a bit surprising. Do these extra sections actually account for most of the size difference? Obvious question: Are the two compilers setup to specify the same default libraries? Others best placed to tell you how to check that - is it in the specs file? P. |
From: Eli Z. <el...@gn...> - 2013-11-11 16:33:07
|
> Date: Mon, 11 Nov 2013 11:22:41 +0100 (CET) > From: Mauro Salvini <mau...@sm...> > > Comparing final executables evidences that there are some different function references in mscvrt.dll section, but the major difference is that on Linux side executable haven't .eh_fram, .CRT and .tls sections. Are you sure you are using on Windows a toolchain from mingw.org and not from some other MinGW distribution? AFAI, mingw.org GCC does not generate .eh_fram sections. |
From: Mauro S. <mau...@sm...> - 2013-11-12 07:44:08
|
> Are you sure you are using on Windows a toolchain from mingw.org and > not from some other MinGW distribution? AFAI, mingw.org GCC does not > generate .eh_fram sections. Yes. I also tried to upgrade MinGW via MinGW-get in MSYS (now gcc is 4.8.1), but result is the same. I'll try a fresh install. maybe -mconsole linker flag adds this section to executable? |
From: Eli Z. <el...@gn...> - 2013-11-12 16:11:29
|
> Date: Tue, 12 Nov 2013 08:43:58 +0100 (CET) > From: Mauro Salvini <mau...@sm...> > Cc: min...@li... > > maybe -mconsole linker flag adds this section to executable? Not on my systems. |
From: Óscar F. <of...@wa...> - 2013-11-12 14:17:54
|
Mauro Salvini <mau...@sm...> writes: >> Are you sure you are using on Windows a toolchain from mingw.org and >> not from some other MinGW distribution? AFAI, mingw.org GCC does not >> generate .eh_fram sections. > > Yes. I also tried to upgrade MinGW via MinGW-get in MSYS (now gcc is 4.8.1), but result is the same. > I'll try a fresh install. maybe -mconsole linker flag adds this section to executable? On your original message you are comparing MinGW's gcc 4.7.2 with MinGW's gcc 4.2.1. I guess that those are using the runtime libraries available at their respective release date. I'll say that since 4.2.1 the runtime libraries and other stuff that is included by default in your executable has changed a lot on their contents. For "a small console application" it might be the bulk of the difference on size. |