Why does GCC run in Docker produce around 30% smaller statically linked C++ executables than GCC run on Linux? AECforWebAssembly is 1.08 MB large if compiled using GCC 13.1 in Docker, but it is 1.59 MB if compiled using GCC 13.1 on Debian.

Question

Anonymous · Accepted Answer

Most likely is that different static libraries are being linked in each case. Note that, if one environment is being used o test and debug a program for the other, this can be the source of highly elusive bugs. This one reason why I prefer a VM over a mess like Docker.

Chris Reid · Answer

I imagine two things — the Docker compiler is a different version, and the default settings for the docker version is for a stripped binary. A stripped binary has the symbol table removed from the executable. This makes it leaner, but harder to debug. Docker containers are very aware of limited space and memory, so it makes sense to try to slim down programs where they can be.

30% is a lot.

Mats Petersson · Answer

There are several answers here already, making some very good points, however, I’m going to suggest a few very basic things:

1. Run [code]file myexecutable[/code] and compare the output from the two executable files.

Particularly, you may have differences in what debug info is included in the files.

Could also be that one of your builds is 32-bit, the other 64-bit, for example.
2. Run [code]size myexecutable[/code].

This will show the size of the actual executable code (called text), data and bss. If these are the same, you are good - it’s “some other stuff” in the executable file.

If the sizes are different, then you will, hopefully, know at least roughly where to look.
Neither of these commands will give you a direct answer to what the difference is, but it may well give you a start to look for what.

For actually solving it, yes, you will need to figure out exactly what options your compiler is using - which may include configurations in the “make” setup, environment variables, build configuration when you set up the project. And probably several other things that escapes me right now. It may also depend on precisely “what else” and “which version” is installed on the respective environments.

Petr Skocik · Answer

I’d look at [code ]gcc -v[/code] outputs in those two respective environments to see how the default settings of the compiler differ in them. One or more of the differing default settings should be behind the size difference.

Vishal Oza · Answer

I would first look what are your build/compiler settings between your Docker instance versus your Debian install. This might include make/cmake files. They might hint the build is set to create smaller binaries or faster binaries. If there is nothing that says the build was different, the it is possible gcc is different between Docker and Debian. The Docker version builds smaller binaries because it assumes space is limited but Debian version might build bigger to run faster

Joseph Newcomer · Answer

Which version of the compiler, with what options selected, for what target machine? You may naively think you are comparing two compilers, and if you did not compare the same version of the compiler with the same options compiling for the same architecture , you have no idea what you are comparing. It you can’t show us the command lines for each tool in each step of the toolchain, we can’t, either. The only way you can prove they are the same compiler is if you can show they are bitwise identical images. And that their libraries are bitwise identical. You have to show the command lines for each tool, and they must be absolutely identical, and you have to show the link maps. Without the link maps, you have zero evidence of difference, because file size has nothing to do with memory footprint.

Emilio Garavaglia · Answer

After reading a few answer let me give you two suggestion:

* OP: plese change GCC to gcc (and clarify you are talking about the command, not the entire compiler suite) [Thank you for the update]
 * To the authors: please before answering consult UP TO DATE documentation, and don’t report your child’s memories. Saying “g++ is equivalent to [code ]gcc -x c++[/code]" is false (there are many important missing part!) so let me debunk what's going on
1. GCC (all capitals) means GNU Compile Collection. It’s comprehensive of various compilers, libraries and -last but not least- a LINKER. Without it no program can be produced.
2. [code ]gcc[/code] (small letters) is a command-line program that -when given a set of file- try to guess the corresponding language, invoke the corresponding compilers, and -finally LINKS all the produced object by invoking a linker.
To produce a program, the linker must link not just the produced objects, but also all the libraries they may refer to. Unless of specific language standard or proprietary constructs (like [code ]module[/code] or [code ]#pragma link[/code]) the linker has NO WAY TO KNOW what are the archive containing such libraries. The only library that is always linked by default is the CRT_Startup code (or whatever is called by different compiler manufacturer) that contains only the entry and exit functions plus the minimal necessary to print error messages that is the thing that calls [code ]main [/code]after breaking up the command line words.

Now consider this program

[code]#include%3Ccstdio%3E
int main()
{ printf(“hello
”); return 0; }
[/code]save it as a main.cpp and compile it as

[code]gcc main.cpp
[/code]It compiles and run.

Now consider this

[code]#include%3Ccstdio%3E
int main()
{ 
	auto ptr = new int;
	printf(“hello
”); 
	return 0; 
}
[/code]And invoke it the same.

You will get

[code]undefined reference to `operator new(unsigned long)'
[/code]This is not a compiler error: it is a LINKER ERROR.

So what’s the fuss here?

The compiler correctly recognized the language to be C++ and did it’s job properly: it translated [code ]new int[/code] into [code ]operator new(sizeof(int))[/code].

The problem is that while the first program use no more than a [code ]printf[/code] (most likely optimized in a [code ]puts[/code], that is used bu the startup code itself to print his own startup failure message, and hence it is part of the C-support library) the second also use a fu**ing [code ]operator new(size_t)[/code] that’s NOT PART of the C standard library.

Consider this program

[code]#include%3Ccstdio%3E

struct boot
{
	boot() { printf("Boot
"); }
	~boot() { printf("Unboot
"); }
};

boot instance = {};

int main()
{}
[/code]How many of you think it does noting?

Let me give you an F.

That program (according to the ISO C++ standard) must print

[code]Boot
Unboot
[/code]But to do that, it needs a startup code that calls [code ]boot::boot()[/code] before calling [code ]main[/code] and calls [code ]boot::~boot()[/code] after returning from it.

But if the linked startup code will not contain the part that iterate the function pointer vector resulting from the instantiation of the global static variables… your program can’t work correctly. And it should normally produce a linker error

[code]%3E gcc main.cpp
C:\Temp\ccgbBujR.o:main.cpp:(.xdata$_ZN4bootD1Ev+0xc): undefined reference to `__gxx_personality_seh0'
collect2.exe: error: ld returned 1 exit status

%3E gcc -xc++ main.cpp
C:\Temp\ccYyt7H3.o:main.cpp:(.xdata$_ZN4bootD1Ev+0xc): undefined reference to `__gxx_personality_seh0'
collect2.exe: error: ld returned 1 exit status

%3E g++ main.cpp

%3E a
Boot
Unboot
[/code]And this is the proof that saying “g++ is just gcc -xc++” is false!

As it is false also saying “I can compile C++ with gcc”: it succeeds only if no C++ specific features requiring library implementation are used. g++ ensure that the proper library modules are linked, whatever the specific invocation option may be in this or that release.

Anonymous · Answer

Size of an executable does not mean much. Especially for Java code which requires very big JVM to run!
Similar is for Python code where py file also needs complete Python executable, python.exe.

If we look at some simple example, eg for loop:

[code]for(int a = 0; a %3C 100; a++)
{
}
[/code]C/C++ compiler generated code will be three to four instructions depending on CPU.
Java generated byte code will be similar. But byte code cannot be executed and must have complete JVM launched taking lot of MBs.

If we look at C/C++ code, then two possibilities exist:

* Statically linked libraries
 * Dynamically linked libraries
Statically linked library means that library code (lib file) is added to the executable increasing its size. Depending how library was built, whole library might end up in the executable.
Dynamically linked means that executable uses a DLL (Windows) and only very tiny proxy layer is inside executable. Such executables are way smaller but also take longer to load. Memory wise it could be similar (depends).

Windows executables have multiple sections as well as resources, eg images. This all increases size a lot.

So, it is not possible to compare executables sizes. It is not accurate measure. But look at memory usage of a Java app and picture is different.

Chris Reid · Answer

Simple. tcc can run source code.

[code]/*demo.c */
#include %3Cstdio.h%3E
#include %3Cstdlib.h%3E

int main ( int argc, char** argv)
{
  int*p = (int*)calloc(100, sizeof(int) );

p[0]=1;

for(int i = 1; i %3C 100; i++) { p[i] = i + (p[i-1]) ;}

for(int j = 0; j %3C 100; j++) { printf("%d	" , p[j]);}
  printf("
");

free(p);
return 0;
}

tcc -run demo.c

1	2	4	7	11	16	22	29	37	46 
56	67	79	92	106	121	137	154	172	191
11	232	254	277	301	326	352	379	407	436
466	497	529	562	596	631	667	704	742	781
821	862	904	947	991	1036 1082	1129	1177	1226
1276	1327	1379	1432	1486	1541	1597	1654	1712	1771
1831	1892	1954	2017	2081	2146	2212	2279	2347	2416
2486	2557	2629	2702	2776	2851	2927	3004	3082	3161
3241	3322	3404	3487	3571	3656	3742	3829	3917	4006
4096	4187	4279	4372	4466	4561	4657	4754	4852	4951
[/code]The author says it on his website: TCC : Tiny C Compiler [ https://bellard.org/tcc/ ]

* SMALL! You can compile and execute C code everywhere, for example on rescue disks (about 100KB for x86 TCC executable, including C preprocessor, C compiler, assembler and linker).
 * FAST! tcc generates x86 code. No byte code overhead. Compile, assemble and link several times faster [ https://bellard.org/tcc/#speed ] than GCC.
 * UNLIMITED! Any C dynamic library can be used directly. TCC is heading torward full ISOC99 compliance. TCC can of course compile itself.
 * SAFE! tcc includes an optional memory and bound checker. Bound checked code can be mixed freely with standard code.
 * Compile and execute C source directly. No linking or assembly necessary. Full C preprocessor and GNU-like assembler included.
 * C script supported : just add '#!/usr/local/bin/tcc -run' at the first line of your C source, and execute it directly from the command line.
 * With [code ]libtcc[/code], you can use TCC as a backend for dynamic code generation.

Grzegorz Antoniak · Answer

New version of GCC is compiled in older version of GCC.

Older version of GCC was compiled by using even older version of GCC.

First version of GCC could be compiled by using a different C compiler.

The first C compiler was written in a different language: BCPL, so it used BCPL compiler.

The BCPL compiler was written in BCPL itself, so new versions of BCPL needed older versions of BCPL to be compiled, similarly to GCC.

The first version of BCPL was written in AED, or Algol.

The first Algol compiler was *possibly* written in machine code by using punch cards.

Kartik Ayyar · Answer

Here is my mindset for comparing compilers:

Even when upgrading  what seems like relatively minor version bumps of existing compilers I've seen all sorts of bugs crop up - ranging from code not compiling, to the compiler getting stuck in an infinite loop, to code that sometimes crashes, to some flags not working in the exact same way despite compatibility being advertised. These issues are a pain to debug, and sometimes the turnaround from your compiler vendor can be suboptimal ( and sometimes, even getting them a reproduce able test case to hit the problem isn't easy if you had a complicated binary which has dependences on custom tools and build scripts ). That is if you even have a compiler vendor supporting you.

At times the problems that have come up have been in code that was actually buggy but somehow worked in a previous compiler, but at the end of the day it did work and that was what was important.

While clangs's list of advantages over gcc looks interesting, the actual feature list for picking a compiler needs to prioritize reliability above everything else.

For example, the website for clang mentions that "Qt doesn't compile due to a problem in Qt." It isn't uncommon for there to be some quirks somewhere in large codebases, but if it compiles and works on gcc, this isn't Qt's problem, its clangs. 3rd party vendors will test with the defacto standard rather than an esoteric compiler

Given how fundamental a compiler is, err on the side of being absolutely conservative and paranoid when it comes to selecting compilers.

With that massive disclaimer out of the way, looking at the documentation for clang, it does seem to have some rather interesting features over gcc.

Better diagnostics:
It seems clang has far better error diagnostics than gcc, in particular it seems to be far better than gcc in terms of pinpointing where exactly parsing failed.

http://clang.llvm.org/diagnostics.html

Fast compiles:

While nice, for one file incremental builds it doesn't make too much of a difference, on the other hand for large builds while it can be quite  handy, it doesn't come across as tempting enough to switch.

http://clang.llvm.org/features.html#performance

Better code analysis tool support

The article points out that the AST produced by gcc isn't as friendly towards some tools since if you have an expression in gcc which evaluates to a constant, it is replaced by a constant - this can make renaming variables hard.

If you do want to use a tool to do do this rename that is based off of clang and actually works, my advice would be to use it in a one off manner - though again, nothing worth jumping ship for.

Better IDE support

I don't see examples or specifics, so I can't comment. Personally, I consider gdb is significantly more powerful than any graphical debugger I've used by a long shot, so again, nothing interesting.

http://clang.llvm.org/features.html#ideintegration

Miscellany:

Pretty much everything else on its long list of features is an implementation detail - it doesn't affect the bottom line for developer productivity. In theory it might have cleaner internals, in practice gcc has been battle tested.

Assuming you have sane, clean makefiles such that you can make a compiler switch across your entire codebase in one place, it won't hurt to toy with it or use it for compiling your initial builds and experiment while incrementally developing, especially if its primary features are faster build times and more helpful errors.

However, out of sheer paranoia, I'd say don't use it for any shipping code.

Wait for your 3rd party libraries start coming with documentation that says they have been tested against clang . Wait for other organizations to make announcements saying they have been using clang for a while and it is working fine for them to the point you can't ignore clang.

Let someone else incur the learning cost for this activity given the risks.

Valdis Klētnieks · Answer

Why does GCC generate 15-20% faster code if I optimize for size instead of speed?

First off, I’d be surprised if *all* code is 15–20% faster, though there’s some reasons why *some* code might be….

Most likely, your CPU has a smallish instruction or merged L1/L2 cache, and the code didn’t fit in the cache when optimized for speed. This results in cache line misses, which slow things down.

Compiling for size makes the code fit better in cache, reducing cache misses.

Of course, this effect will depend on your exact code.

You probably want to take a really close look at the -march and -mcpu flags.

Lorenzo Snow · Answer

TCC is “tiny”, it’s really tiny compiler which is not a toy, it fully support many corner cases in C, it produces a small executables, if you’re learning decompilation for example, it’s easy to use TCC when you need a small build-system-environment, for education purposes, also TCC uses in other languages and compilers (Nim for example) which translates their source code into C, also some OS uses TCC as a main compiler (DeforaOS, a nice little project, if I not wrong), TCC is a good example if you want to learn bitwise operations in their hard way, TCC is FAST as a compiler I mean, it one pass compiler without deep optimizations stages, TCC sources is a good example how someone thinks like a genius, it has an embedded preprocessor written from scratch, and LINKER with output formats pe32 and pe64 for windows, it has a bunch of std-headers from the box and a bunch of headers for win-api, it can interpret C-files, it has builtin ASM inside (unbelivable), it injects debug markers in output exe-file, it's easy to use it, and it’s a compiler with charisma.

PS. It’s a good example, how may be written preprocessor+compiler+optimizer+linker+interpreter+assembler, and all of them in 25000 SLOC.

Anonymous · Answer

Windows version does not matter cause Windows is accessed via APIs which are part of H files (and lib files to preload DLLs).

What matters is code generation for CPU used. If still running Win 98 I will suppose it uses older CPU, like Pentium 1, 2. In those CPUs lot of extensions, instructions, are unavailable, eg AVX.
CPU affects compiler code generation as well as compiler libraries used, eg string copy. Eg in Visual Studio usually default CPU is “generic type” which is x86 compatible.
Some code generated using GCC (latest versions) when AVX is enabled use AVX for memory copy and even optimizes for loops which set it.

Petr Skocik · Answer

I’d look for the culprit inside your source file (maybe you’re statically allocating a big array?).

Translating and linking a simple raw-systemcall hello world on x86–64 Linux gets me a static executable of about 8KiB (2 segments (rodata + text), 1 page each).

A C hello world using libc yields a twice as largge (about 16KiB) dynamically-linked executable.

Anonymous · Answer

I fear you misunderstand all of the above.

C, and C++ are two sets of human-readable languages. In order for a human to tell a computer how to create a program to run on a computer.

A Docker image is a set of programs to run on a computer. Just in a preloaded set of collaborative programs. Be they made using C, or C++ or Python, or whatever else, is immaterial. In fact, nearly all those programs are very likely created using either C or C++.

It would definitely not preclude a data centre using programs created in those languages. Docker just gives an alternative method for running the programs after they’re already created using any language, just like running them bare metal or inside a full VM would. Makes no difference.

The concepts are perpendicular, compatible, not competitors of one another. Both can happen at the same time. Both can be changed independent of one another. They don’t have an effect on each other.

Reini Urban · Answer

* gcc produces better code, whilst icc produces the best code.
 * clang produces better diagnostics, which can lead to much better code in the end, by fixing more bugs and adding more missed optimizations. But both are playing the catch-up game there.
 * newer clang-5+ has better compile-time check support, which can lead with object_size checks to much better code with most constexpr’s, even with C. In certain projects (e.g. a libc rurban/safeclib [ https://github.com/rurban/safeclib/blob/master/tests/perf_memcpy_s.c ]) clang can be then at least 2x faster than gcc.
 * clang has better tooling support, e.g to integrate C++ into emacs or vi.
 * gcc has stable JIT support. clang’s JIT support changed 3x in the past, but is still in the lead. icc has no jit support.
 * gcc supports much more older platforms, whilst only clang support the new GPU and APU platforms.
 * clang compiles faster. fastest would be zapcc, a commercial clang derivate. And of course tinycc

Jack Miller · Answer

Yes, you can use either. Muddle through a chroot tutorial to create a skeleton directory containing the new glibc, then start up your exec inside the chroot. Alternatively, it's quicker to create a container, but you end up with a new IP / what is essentially a new box. If it's a pain to factor that into your inventory system or documentation, it might be the deciding factor. Also you might run into this "somehow can't be upgraded" problem again.

You can also use the environment variable LD_LIBRARY_PATH with your binary and point it where the newer glibc is, but that's kinda hokey unless it's a

You can also use the environment variable LD_LIBRARY_PATH with your binary and point it where the newer glibc is, but that's kinda hokey unless it's a one-off

David Brower · Answer

1. You’re on a system that doesn’t have enough memory to run current versions of GCC.
2. You run things through multiple compilers to see what warnings and errors come out.
3. You like insanely fast compilation.
4. You’re embedded in something else and don’t want to drag a GCC around with you.

Michael Veksler · Answer

Like Quora User I am getting   5032 bytes with gcc-5.0 on a x86_64 linux, but when I link statically:
[code]g++5.0 -static -Os -s  t.cpp[/code] 
I am starting to get a 1.3MiB executable.

I suspect that you are getting 0.5MiB on Windows because your compliers are linking statically or they bring some extra baggage. To test this hypothesis I have tried it on Cygwin-x86_64 GCC-4.9 on which the executable is only slightly larger: 8704 bytes. So it does not look like the default compiler config does this.

Next, I tried to link statically on cygwin using the [code]-static[/code] flag. The result is surprisingly similar to yours: 576KiB. Static linking brings in a lot of things you don't really need.

Next, I check mingw for x86_64, and that takes 16KiB with default parameters. This is pretty bad but not as bad as you see. And with [code]-static[/code] it also takes 585KiB.

So I guess that in your case, your setup is somehow linking in static libraries instead of using DLLs. I think that the size you see is a constant value added to all executables. What I am trying to say that increasing your trivial program to a 1000 lines program, the source code increase will not have a dramatic impact on your 500KiB executables since most of it is a C++ library stuff.